Subject: Rare project developers
List archive
- From: mc36 <>
- To: Kaliraj Vairavakkalai <>, Tamas Mondal <>, Krzysztof Szarkowicz <>
- Cc: Antoni Przygienda <>, Natrajan Venkataraman <>, Reshma Das <>, "" <>
- Subject: Re: [rare-dev] Ping me Csaba if that's your current email ...
- Date: Wed, 24 Aug 2022 23:05:23 +0200
you guys are unbelievable! :)
i've just added you to the bottom of http://www.freertr.org/greet.html
if you dont like it, just let me know! regarding the lists,
you're right again, i'll also switch to the digest mode too.... :)
regarding the bgp-ct, i would love to take care of it,
and as you already pushed me to the right way, it should not be that bad...
but, heyyy, if you really have the will, then tbh nobody could done that
better than you...
regarding the forwarding stuff, i just added to cc, that should be enough...
thanks you sooo much,
cs
-------- Forwarded Message --------
Subject: Re: Ping me Csaba if that's your current email ...
Date: Wed, 24 Aug 2022 20:09:48 +0000
From: Kaliraj Vairavakkalai <>
To: mc36 <>, Tamas Mondal <>, Krzysztof Szarkowicz
<>
CC: Antoni Przygienda <>, Natrajan Venkataraman
<>, Reshma Das <>
>so can i forward some select mails from this thread to the lists?
Sure, ofcourse!. :)
Pls feel free to fwd emails that indicate eventual convergence points on
ideas.
I haven’t subscribed to those lists yet. Ok, will do. But I should set expectations: I don’t pay regular attention to mailing-lists I subscribe to, including ietf :). So I will mostly be in silent mode. Btw, that brings another question – if you are not subscribed to IETF-IDR mailing list yet, here is the link to d othat - https://www.ietf.org/mailman/listinfo/idr <https://www.ietf.org/mailman/listinfo/idr> . Again, silent mode is fine. :)
And yea, if you can think of real world use-cases that can get enabled by the
bgp-ct work we are doing – that’s exactly what we want. :)
The main intent is to be useful in real-world. That’s also why we don’t want
to take shortcuts for the sake of demo/showcase.
Thanks!
Kaliraj
*From: *mc36 <>
*Date: *Wednesday, August 24, 2022 at 12:09 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]
On 8/24/22 22:16, Kaliraj Vairavakkalai wrote:
Understood. :) Ofcourse!
Again, no guarantees on how much we will really be able to contribute to
code. But we would love to.
Nats was thinking about it (implementing CT in freertr) even before Tony
introduced you to us.
Thanks to Tony, you have been awesome. We could not have pulled off
implementing bgp-ct in freertr
in such short order.
And hopefully the design brainstorming we have been having so far is helpful.
:)
Thanks!
Kaliraj
*From: *mc36 <>
*Date: *Wednesday, August 24, 2022 at 12:41 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]
okk...
so for example when i asked you that you just want to design to help develop
and you said both...
for example that, the guys in the team wont believe me, i hope you
understand.... :)
On 8/24/22 21:08, mc36 wrote:
so can i forward some select mails from this thread to the lists?<https://urldefense.com/v3/__https:/lists.geant.org/sympa/info/rare-dev__;!!NEt6yMaO-gk!A59Wtzze5x4eOQxBLlnguTfpAaa2HGflokDSjkIZ0hXDMoIhizXcubIqBRIGZGsmYdmRFY5p$>
(imho you should do so as there are surely things that you would remove doing
beforehand)
https://urldefense.com/v3/__https://lists.geant.org/sympa/info/rare-dev__;!!NEt6yMaO-gk!A59Wtzze5x4eOQxBLlnguTfpAaa2HGflokDSjkIZ0hXDMoIhizXcubIqBRIGZGsmYdmRFY5p$
is a hidden one so it does not appear when you search for it but you should<https://urldefense.com/v3/__https:/www.nanog.org/events/nanog-86/__;!!NEt6yMaO-gk!BJz5jt_0-bIdAPBR6nEtpcL-6YAqNQIteU237OixFzXbQxVpkwlsV9J5n2rHaGyn4pLYrLAP$>
be able to subscribe.. (if not, just tell me)
so they told me recently that they're doing the twamp measures because they
want a distributed orchestra or so...
but lemme show attach you something... for example that could be a nice use
case, if there are not too big distances...
thanks,
cs
On 8/24/22 20:56, Kaliraj Vairavakkalai wrote:
Sorry, missed that question. Take what public?
The ideas/procedures we shared with you are kind of public already. Explained
the BGP-CT draft :)
Perhaps I didn’t get your question. Can you explain pls?
Thanks,
Kaliraj
*From: *mc36 <>
*Date: *Wednesday, August 24, 2022 at 11:51 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]
but could i ask once again if can we take it somehow public?
thanks,
cs
On 8/24/22 20:49, mc36 wrote:
thanks! i wont limit, imho the list will result in less loc....|
On 8/24/22 20:46, Kaliraj Vairavakkalai wrote:
That s right. :)
It can be either order based(left, right) or you can explicitly specify the
priority order.
You may limit it to two vrfs, for simplicity.
It s like,
* for MC <community>,
o take <transport-vrf1> as primary
o take <transport-vrf2> as fallback. [optional]
MC is mapping-community that comes on route and signals the resolution-scheme
to use.
e.g.:
* for MC color:0:100,
o take color-100 vrf as primary
o take default-vrf as fallback.
* for MC transport-target:0:100,
o take color-100 vrf as primary. (no fallback)
* for MC color:0:101,
o take color-100 as primary.
* for MC transport-target:0:101,
o take default-vrf as primary.
* for MC color:0:X,
o take color-Y vrf as primary
o take color-Z as fallback.
When a route matches NO such local resolution-scheme, then it takes
default-vrf as primary resolution-rib (that s your current implemented
behavior). Backward compatible.
Thanks
Kaliraj
*From: *mc36 <>
*Date: *Wednesday, August 24, 2022 at 10: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]
thanks for the confirmation, then tomorrow i'll start what i've written as
plan b...
for the resolution scheme, if i got you correctly (well not:) so that knob
should
ask the user for a list of vrfs and i must try from left to right in them if
i found
the ibgp nexthop, right?
On 8/24/22 18:39, Kaliraj Vairavakkalai wrote:
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
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:/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:/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:/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:/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:/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:/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:/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:/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:/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:/github.com/rare-freertr/freeRtr/blob/master/src/net/freertr/tab/tabRouteUtil.java*L34__;Iw!!NEt6yMaO-gk!G-_Xz7nJBYAGPp2dQeyhTCFyi-jd7I1md7Eh9ORHBr2Nf9g0P5vjtRgg8N1Q6-5inQd8nqK0$>>>>
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:/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:/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:/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:/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:/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:/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:/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:/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:/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:/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://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$>>>><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$<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$
<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
Juniper Business Use Only
Juniper Business Use Only
Juniper Business Use Only
- Re: [rare-dev] Ping me Csaba if that's your current email ..., mc36, 08/24/2022
- Re: [rare-dev] Ping me Csaba if that's your current email ..., Kaliraj Vairavakkalai, 08/24/2022
- <Possible follow-up(s)>
- Re: [rare-dev] Ping me Csaba if that's your current email ..., mc36, 08/24/2022
- Re: [rare-dev] Ping me Csaba if that's your current email ..., Kaliraj Vairavakkalai, 08/24/2022
- Re: [rare-dev] Ping me Csaba if that's your current email ..., mc36, 08/24/2022
- Re: [rare-dev] Ping me Csaba if that's your current email ..., Kaliraj Vairavakkalai, 08/25/2022
- Re: [rare-dev] Ping me Csaba if that's your current email ..., mc36, 08/25/2022
- Re: [rare-dev] Ping me Csaba if that's your current email ..., Kaliraj Vairavakkalai, 08/25/2022
- Re: [rare-dev] Ping me Csaba if that's your current email ..., mc36, 08/25/2022
- [rare-dev] Fwd: Ping me Csaba if that's your current email ..., mc36, 08/25/2022
- Message not available
- Re: [rare-dev] [freertr] [RARE-users] Fwd: Ping me Csaba if that's your current email ..., mc36, 08/26/2022
- Re: [rare-dev] Ping me Csaba if that's your current email ..., Kaliraj Vairavakkalai, 08/25/2022
- Re: [rare-dev] Ping me Csaba if that's your current email ..., mc36, 08/25/2022
- Re: [rare-dev] Ping me Csaba if that's your current email ..., Kaliraj Vairavakkalai, 08/25/2022
- Re: [rare-dev] Ping me Csaba if that's your current email ..., mc36, 08/24/2022
- Re: [rare-dev] Ping me Csaba if that's your current email ..., Kaliraj Vairavakkalai, 08/24/2022
Archive powered by MHonArc 2.6.19.