Subject: Rare project developers
List archive
- From: mc36 <>
- To: "" <>
- Subject: [rare-dev] Fwd: Ping me Csaba if that's your current email ...
- Date: Wed, 24 Aug 2022 23:13:23 +0200
-------- Forwarded Message --------
Subject: Re: Ping me Csaba if that's your current email ...
Date: Wed, 24 Aug 2022 16:39:03 +0000
From: Kaliraj Vairavakkalai <>
To: mc36 <>, Tamas Mondal <>, Krzysztof Szarkowicz
<>
CC: Antoni Przygienda <>, Natrajan Venkataraman <>,
Reshma Das <>
and tbh this way seems easier than the rd hacks.... :)
Ack! Csaba. :) fully agree.
> and finally, the vrfs and bridges also will get a new knob to set vrf used
for resolution...
Correct. That gives per-rib (vrf and bridges) scoped control, to say which
transport layer color-vrf used for resolution (aka resolution-scheme).
And that is one step closer to the final required state where the resolution-scheme(color-vrf used for resolution) is decided based on the mapping-community/color that arrives on the received bgp-route. i.e. gives per route scoped control to pick the resolution-scheme.
And the reason I talk about resolution-scheme construct as an
indirection:
Mapping-community --1:1--> resolution-scheme --1:n--> {color-vrf}.
Initial implementation in freertr, n=1. But If/When you provide fallback
option for the configured resolution-scheme, then n becomes 2.
That will be a complete CT implementation. :)
Thanks
Kaliraj
*From: *mc36 <>
*Date: *Wednesday, August 24, 2022 at 4:11 AM
*To: *Kaliraj Vairavakkalai <>, Tamas Mondal
<>, Krzysztof Szarkowicz <>
*Cc: *Antoni Przygienda <>, Natrajan Venkataraman
<>, Reshma Das <>
*Subject: *Re: Ping me Csaba if that's your current email ...
[External Email. Be cautious of content]
and tbh this way seems easier than the rd hacks.... :)
On 8/24/22 13:10, mc36 wrote:
and finally, the vrfs and bridges also will get a new knob to set vrf used<https://urldefense.com/v3/__https:/github.com/rare-freertr/freeRtr/blob/master/src/net/freertr/tab/tabRouteUtil.java*L34__;Iw!!NEt6yMaO-gk!G-_Xz7nJBYAGPp2dQeyhTCFyi-jd7I1md7Eh9ORHBr2Nf9g0P5vjtRgg8N1Q6-5inQd8nqK0$>
for resolution...
On 8/24/22 12:38, mc36 wrote:
hi,
after a quick lunch i must acknowledge that you know the topic better so my
apologies! :)
plan b:
the user must configure separate vrfs for the colors
nothing special, just the regular rib
the user must configure them and bind to a global vrf
that binding will populate the connected routes from the global (needed here
at various points)
the user must configure the igps to pick the algos and place the routes to a
colored vrfs
the bgp will reuse the regular vpnv4 l3vpn import/export mechnaisms but from
the ct afi and not from the vpnv4 afi
does it sound better?
ps: if we agree, i must charge cisco for doing his homework.... :)
thanks,
cs
On 8/24/22 10:16, mc36 wrote:
expressions --> programs... no limit here, it's a full tcl interpreter ran
over the attribs if configured...
On 8/24/22 10:14, mc36 wrote:
not that ugly, i have tcl in the rpls: one can write _arbitrary_ expressions
on the routeEntry attribs
https://urldefense.com/v3/__https://github.com/rare-freertr/freeRtr/blob/master/src/net/freertr/tab/tabRouteUtil.java*L34__;Iw!!NEt6yMaO-gk!G-_Xz7nJBYAGPp2dQeyhTCFyi-jd7I1md7Eh9ORHBr2Nf9g0P5vjtRgg8N1Q6-5inQd8nqK0$
<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-classful-transport-planes-01*section-10.3__;Iw!!NEt6yMaO-gk!G-_Xz7nJBYAGPp2dQeyhTCFyi-jd7I1md7Eh9ORHBr2Nf9g0P5vjtRgg8N1Q6-5ine-_xxjr$>
On 8/24/22 09:26, mc36 wrote:
yeahhh, got it...
so if i go with the current idea then, for the anycast case, i'll need to
list all the participants...
ugly but still don't see why would not work...
On 8/24/22 08:54, Kaliraj Vairavakkalai wrote:
what about your implementation?
Junos ingress does not use the RD for nexthop-resolution. it segregates the
tunnel-routes (bgp, rsvp-te, srte, flex) based on their RT (color). And then
performs the lookup
for a ibgp-nexthop (plain ip-prefix) in the right color db.
do you use the same rd for the same color on announcing?
Today Junos originates unique auto-RDs (configured-rd-seed-ipaddr : <id>).
I still need to implement allowing explicitly configuring an RD value.
So two different Junos-PEs may originate unique RD bgp-ct routes, but with
same color route-target, for an anycast-nexthop-address for e.g.
If it is an unicast-nexthop-address, then you re right - there could be a
1:1 mapping between RD to Color (or it could be N:1 also). If
anycast-nexthop, that is not true
anymore.
Also, even for unicast-nexthop-address, let us say, we are resolving
ibgp-route and looking for RD1:PE11
* The route providing this reachability will typically be an isis-flex
or rsvp-te route. That route will not have any RD for PE11, PE12
tunnel-routes.
* So when you lookup for RD:PE11, how do you get to the rsvp-te route?
Unless you add RD config to the rsvp-te/flex config on a per egress-PE basis.
* I think it may not be practical for the ingress PE/ASBR to know and
maintain such per-egress-PE RD config. Too many touch points when a new PE is
added to network.
So in the draft as-well, we suggest doing a lookup for the plain ip-nexthop
in the transport route database (per color tunnel db)
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-classful-transport-planes-01*section-10.3__;Iw!!NEt6yMaO-gk!G-_Xz7nJBYAGPp2dQeyhTCFyi-jd7I1md7Eh9ORHBr2Nf9g0P5vjtRgg8N1Q6-5ine-_xxjr$
<https://urldefense.com/v3/__https:/www.nanog.org/events/nanog-86/__;!!NEt6yMaO-gk!BJz5jt_0-bIdAPBR6nEtpcL-6YAqNQIteU237OixFzXbQxVpkwlsV9J5n2rHaGyn4pLYrLAP$><https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-classful-transport-planes-01*section-10.3__;Iw!!NEt6yMaO-gk!G-_Xz7nJBYAGPp2dQeyhTCFyi-jd7I1md7Eh9ORHBr2Nf9g0P5vjtRgg8N1Q6-5ine-_xxjr$
>
again, i havent seen a junos originated bgp-ct route yet, i just travrse the
vsrx...
Ok. Fyi: Following is the config that will make an egress-PE junos node
originate bgp-ct route:
set routing-options route-distinguisher-id 1.1.1.1
set routing-options transport-class name gold color 100
tunnel-egress end-point 1.1.1.1
set protocols bgp <ibgp-peer> export-policy export-bgp
set policy-options policy-statement export-policy term
1 from bgp.transport.3
set policy-options policy-statement export-policy term
1 from protocol direct
set policy-options policy-statement export-policy term
1 then accept
set policy-options policy-statement export-policy
term def then reject
thanks
kaliraj
*From: *mc36 <>
*Date: *Tuesday, August 23, 2022 at 10:31 PM
*To: *Kaliraj Vairavakkalai <>, Tamas Mondal
<>, Krzysztof Szarkowicz <>
*Cc: *Antoni Przygienda <>, Natrajan Venkataraman
<>, Reshma Das <>
*Subject: *Re: Ping me Csaba if that's your current email ...
[External Email. Be cautious of content]
bsaically one can set it already as an import policy to the peer....
On 8/24/22 07:30, mc36 wrote:
noti(cfg-rouplc)#show running-config this
info userReader.cmdEnter:userReader.java:1087 command noti(cfg-rouplc)#show
running-config this from local:telnet <loop> 23 -> 127.0.0.1 58682
2022-08-24 07:30:12
route-policy asdf
sequence 10 if extcomm 1:1:1234
sequence 20 set rd 1955:1234
sequence 30 elsif extcomm 1:1:4321
sequence 40 set rd 1955:4321
sequence 50 enif
sequence 60 pass
exit
!
noti(cfg-rouplc)#
so this is already there...
On 8/24/22 07:16, mc36 wrote:
heayyy, excellent question, thanks... :)
my opinion is, that for me, the rd is enough, and i'll do an 1:1 mapping with
the rd and the color
the rpl will allow one to do the rt and color mapping, but my preference here
is clearly the rd:
qucker becasue no list lookup in the extcomm attrib...
what about your implementation?
do you use the same rd for the same color on announcing?
again, i havent seen a junos originated bgp-ct route yet, i just travrse the
vsrx...
On 8/24/22 07:10, Kaliraj Vairavakkalai wrote:
Yes, I was talking about the third one.
it must check the outer-rd [optionally rpl] to pick the properibgp nexthop when resolving the customer routes: right now, the
0:0:ibgp-nexthop
is what freerouter looks for, and, that's what i need to make configurable
This is where I have a disconnect. It looks like you are using RD to
pick the colored-nexthop. It should instead be the RT, because the RD does not
signify the color, only RT does.
i.e. we should segregate the tunnels in separate color buckets. And then look
for the ibgp-nexthop in right color bucket. Instead of looking for
RD:ibgp-nexthop.
Did I misunderstand something?
Thanks
Kaliraj
*From: *mc36 <>
*Date: *Tuesday, August 23, 2022 at 9:25 PM
*To: *Kaliraj Vairavakkalai <>, Tamas Mondal
<>, Krzysztof Szarkowicz <>
*Cc: *Antoni Przygienda <>, Natrajan Venkataraman
<>, Reshma Das <>
*Subject: *Re: Ping me Csaba if that's your current email ...
[External Email. Be cautious of content]
hi,
so such a thing could be traversed several ways, as usual... :)
what initially will be there is the inter-as-option-c way: that is,
asbr21 and asbr22 will map between isis and ebgp-ct back and forth,
and there will not be ibgp-ct in between them...
the p will see all the colorful /32 transport routes in ospf/isis from
all the 3 ases... that's what geant does... here, as2 can easily provision
a vpn existing in all the 3 ases at once without any trick...
for it, i just need to code the flexalgo reader/writer to the igps...
it'll arrive first, and it'll be called the ospf/isis + flexalgo feature...
in the next stop when i'll add the outer-rd knob under vrf and bridge
definitions,
one will be able to do a colorful csc mpls vpn, that is, as1 and as3 will be
just
customers of as2, so p will not see nor as1 nor as3 /32s at all because
they'll be
in a vrf in as2. here if as2 adds a pe then he'll be able to announce to the
global
vrf of as1 and as3 but not into a service vrf in as1 and as3, without doing
tricks...
here the color preservation will happen at asbr21, when it learns an vpnv4
route
from asbr22, it must check the outer-rd [optionally rpl] to pick the proper
ibgp nexthop when resolving the customer routes: right now, the
0:0:ibgp-nexthop
is what freerouter looks for, and, that's what i need to make configurable...
and finally the seamless mpls case, when the p again wont see the /32s from
as1 nor as3.
the two asbr will have the ibgp-ct, and it'll also use the same outer-rd
config knob,
but here, from the global vrf... i have the feeling that it'll arrive
automatically
after doing the second step properly, if not, i'll just find out that what
did i wrong
during the first two steps... it stands because freerouter dont have global
at all...
and imho you're referring to the third one, right?
thanks,
cs
On 8/24/22 01:26, Kaliraj Vairavakkalai wrote:
Agree with redistribution config semantics.
But one thing I should clarify..
I think for the current use-case we are talking about,
as1
as2
as3
(junos)
(freertr)
(junos)
pe11---p----asbr11
asbr31----p-----pe31
|
|
| \
/
| |
|
|
|
| asbr21---p---asbr22
|
|
|
|
|
| /
\
| |
|
pe12---p----asbr12
asbr32----p-----pe32
asbr21 and asbr22 in as2 don t need to do any isis->bgp
redistribution into bgp-ct.
as2 will just readvertise the received bgp-ct routes with nexthop-self.
But when asbr21 receives those bgp-ct routes from asbr22, it will just need
to ensure it
resolves the nexthop over the right color tunnel, based on the mapping-community
(transport-target:0:<color>)
on the bgp-ct route. To show an end-to-end colored domain (that is what you
were intending to achieve by
implementing the Redistribution part, if I understood you right?), this is
the piece that will need to be
implemented in freertr. Implementing the redistribution part at asbr21,22 may
not help this cause.
> cool! then which nanog is your target?
It is nanog-86. https://urldefense.com/v3/__https://www.nanog.org/events/nanog-86/__;!!NEt6yMaO-gk!BJz5jt_0-bIdAPBR6nEtpcL-6YAqNQIteU237OixFzXbQxVpkwlsV9J5n2rHaGyn4pLYrLAP$
<https://urldefense.com/v3/__https:/www.nanog.org/events/nanog-86/__;!!NEt6yMaO-gk!BJz5jt_0-bIdAPBR6nEtpcL-6YAqNQIteU237OixFzXbQxVpkwlsV9J5n2rHaGyn4pLYrLAP$>><https://urldefense.com/v3/__https:/www.nanog.org/events/nanog-86/__;!!NEt6yMaO-gk!BJz5jt_0-bIdAPBR6nEtpcL-6YAqNQIteU237OixFzXbQxVpkwlsV9J5n2rHaGyn4pLYrLAP$
<https://urldefense.com/v3/__https:/www.nanog.org/events/nanog-86/__;!!NEt6yMaO-gk!BJz5jt_0-bIdAPBR6nEtpcL-6YAqNQIteU237OixFzXbQxVpkwlsV9J5n2rHaGyn4pLYrLAP$>>><https://urldefense.com/v3/__https:/www.nanog.org/events/nanog-86/__;!!NEt6yMaO-gk!BJz5jt_0-bIdAPBR6nEtpcL-6YAqNQIteU237OixFzXbQxVpkwlsV9J5n2rHaGyn4pLYrLAP$<https://urldefense.com/v3/__https:/www.nanog.org/events/nanog-86/__;!!NEt6yMaO-gk!BJz5jt_0-bIdAPBR6nEtpcL-6YAqNQIteU237OixFzXbQxVpkwlsV9J5n2rHaGyn4pLYrLAP$
<https://urldefense.com/v3/__https://www.nanog.org/events/nanog-86/__;!!NEt6yMaO-gk!BJz5jt_0-bIdAPBR6nEtpcL-6YAqNQIteU237OixFzXbQxVpkwlsV9J5n2rHaGyn4pLYrLAP$
>
Thanks
Kaliraj
*From: *mc36 <>
*Date: *Tuesday, August 23, 2022 at 2:58 PM
*To: *Kaliraj Vairavakkalai <>, Tamas Mondal
<>, Krzysztof Szarkowicz <>
*Cc: *Antoni Przygienda <>, Natrajan Venkataraman
<>, Reshma Das <>
*Subject: *Re: Ping me Csaba if that's your current email ...
[External Email. Be cautious of content]
well, so the rpl would be this to be precise:
route-policy isis2bgp
sequence 10 if network 0.0.0.0/0 ge 32
le 32
sequence 20
if rd 0:100
sequence 30
set rd 1955:100
sequence 40
set extcomm 1234:1234:1234
sequence 50
elsif rd 0:200
sequence 60
set rd 1955:100
sequence 70
set extcomm 1234:1234:1234
sequence 80
pass
sequence 90
enif
exit
but okk... so thanks for the confirmation, i'll start implementing that
tomorrow!
i'll let you know when i have something... hopefully you won't have to wait
too much...:)
thanks,
cs
On 8/23/22 23:41, mc36 wrote:
> hi,
>
> On 8/23/22 22:43, Kaliraj Vairavakkalai wrote:
>>
>>> routes, but, they'll use the rd=0:algo-id format when
generating the routes to the rib... then, one can
>>> map easily back and forth at the asbrs in between the igp
and the bgp-ct... imho that's all what i need...
>>
>> I think that model works too. RD is just a disambiguator.
Just that the flexalgo route should also know it s
color value, that gets encoded as transport
route-target
in the
>> bgp-ct route.
>>
>
> so as it's just a redistribution, and as such, it can have an
rpl so one can do whatever needed with the resulting routes:
>
> !
> route-policy isis2bgp
> sequence 10
if rd 0:100
> sequence 20
set rd 1955:100
> sequence 30
set extcomm
1234:1234:1234
> sequence 40
elsif rd 0:200
> sequence 50
set rd 1955:100
> sequence 60
set extcomm
1234:1234:1234
> sequence 70
enif
> exit
> !
> router bgp4 1
> vrf inet
> local-as 1
> router-id
1.1.1.1
>
address-family ctp
> redistribute
isis4 1 route-policy isis2bgp
> neighbor ....
> exit
> !
>
> and the same at the reverse direction...
>
>
>
>> When I look deeper into freertr code, I may be able to
imagine and opine better. Pls bear with me until then, and take any input with
pinch of salt.
>>
> sure thing, and thanks a lot for your effort doing so!
>
>> You know what works best for freertr code/design. I
m open to doing virtual whiteboarding explaining more of
junos design, if required.
>>
> thanks again, but for now, imho i got the idea!
>
>> And, for the NANOG demo
sure I think doing it remotely works just fine.
>>
> cool! then which nanog is your target?
>
> thanks,
> cs
>
>
>> Thanks
>>
>> Kaliraj
>>
>> *From: *mc36 <>
>> *Date: *Tuesday, August 23, 2022 at 12:51 PM
>> *To: *Kaliraj Vairavakkalai <>, Tamas Mondal
<>, Krzysztof Szarkowicz <>
>> *Cc: *Antoni Przygienda <>, Natrajan Venkataraman
<>, Reshma Das <>
>> *Subject: *Re: Ping me Csaba if that's your current email ...
>>
>> [External Email. Be cautious of content]
>>
>>
>> hi,
>>
>> On 8/23/22 20:57, mc36 wrote:
>>> o for now, the bgp-ct routes are part of the rib, much like
the vpnv4 routes... that's what works...
>>> and my plan is to add the flex-algos real quick to the
igps, and they'll also create just these rd:prefix
>>> routes, but, they'll use the rd=0:algo-id format when
generating the routes to the rib... then, one can
>>> map easily back and forth at the asbrs in between the igp
and the bgp-ct... imho that's all what i need...
>>
>> after a quick googling, imho junos dont use this trick as
much as cisco does:
>>
>> map --> mutual redistribution...
>>
>> imho as2 will be color aware this way internally and
externally in a consistent way...
>>
>> what's your opinion?
>>
>> thanks,
>> cs
>>
>>
>> Juniper Business Use Only
>>
Juniper Business Use Only
Juniper Business Use Only
Juniper Business Use Only
Juniper Business Use Only
- [rare-dev] Fwd: Ping me Csaba if that's your current email ..., mc36, 08/24/2022
- <Possible follow-up(s)>
- [rare-dev] Fwd: Ping me Csaba if that's your current email ..., mc36, 08/24/2022
- [rare-dev] Fwd: Ping me Csaba if that's your current email ..., mc36, 08/24/2022
- [rare-dev] Fwd: Ping me Csaba if that's your current email ..., mc36, 08/24/2022
- [rare-dev] Fwd: Ping me Csaba if that's your current email ..., mc36, 08/24/2022
Archive powered by MHonArc 2.6.19.