Skip to Content.

rare-dev - Re: [rare-dev] Ping me Csaba if that's your current email ...

Subject: Rare project developers

List archive


Re: [rare-dev] Ping me Csaba if that's your current email ...


Chronological Thread 
  • From: Kaliraj Vairavakkalai <>
  • To: mc36 <>, "" <>, 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: Thu, 25 Aug 2022 00:35:40 +0000
  • Accept-language: en-US
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=juniper.net; dmarc=pass action=none header.from=juniper.net; dkim=pass header.d=juniper.net; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=/YkKcodCLHxCxeFhVTARIPgk7AGi6C3N0wkI0fspOLQ=; b=jkvEhi2eo+7aoB9HjDxIlg3aU23E1vcBCGUe5RrtgHFBPZvbHctaUM8yAq9dPXLqXx9hrhVIlo9Fq1UY3wXrx9N5tw0J0gSv/1vnMKYyNfInlUlDEFn8MrHdNlgHaGZrmrxCMcdmSpyN8+G5/EZi/dbIsyz519brXXVnYi2PWXrg1elFRpZrMujug0/s30M1wN72XLfB2et4tKxrqPjTEzNNW9nnSPwjE+rN33gnDtNsighPPK+fxj7WHrqBqjFeghO38kf/eSEuMnYhuZwOR/kum93+Esrm1Mz23aooHOJiVMsCWbo4nrVM8HqSLW5iOrPrgOePpI71oT91JUSZXw==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=chqtOd2RQJpFkSNCvOKQ+/wTdz4ipy5kyzyI9zMNG98jn8+JS4NB+wYWEdqfE/uLkT3aXXnHh6Ep6XCbo7KrvkHkeM3nM3fWhyUNYPhJ+UF3DV4m4Qq7HRuQvx14iH59cI+DDQC60D+QVw0Mp+M/geiTm7Kx7HfASBRtHhQgpnwso9pHXkdqzw1zuk0zmo8MYSybT3RdaRdyqqroQyWCmpUO8ZmfL5Ydx3uglmAVVvsrDCmBoNQ0G8HffSlr39Ql6FJyNj3onRsDIiqemd94P1PuC5p79M2jrJdwJwwNpeBMHNv5qsYZCHvF4ytHt5/6gWArE6NlXDjlBQBVVSFheQ==
  • Msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=True;MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4;MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2022-08-24T23:46:51.7644225Z;MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=0;MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Method=Standard

I’d rather avoid any discussions about CAR. But.. ;)

 

Yes, that deck can be shared if there is any curiosity on comparing CT vs CAR.

 

And other materials in that shared folder are OK to share as-well. :)

 

If you want any email-ids to be added to access the shared folder, pls let us know. We can add them.

 

Thanks,

Kaliraj

From: mc36 <>
Date: Wednesday, August 24, 2022 at 4:46 PM
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 ...

[External Email. Be cautious of content]


ack, will wait a bit then...
btw i also found the "BGP CT vs BGP CAR.pdf" interesting... maybe that too?
and please feel free to shoot me down when i ask too much... :)
thanks,
cs


On 8/24/22 23:54, Kaliraj Vairavakkalai wrote:
> I think that’s cool.
>
> But Krzysztof should confirm, as I see he is the author of that slide-deck. PLM material. :)
>
> If there is a replay-able link to this webinar video, Krzysztof may want to share that as-well.
>
> Thanks
>
> Kaliraj
>
> *From: *mc36 <>
> *Date: *Wednesday, August 24, 2022 at 2: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]
>
>
> just a last question for today... can i share the "BGP CT 5G_Network_Slicing Webinar.pdf" you gave me?
> imho i've a use case but with rtp instead of gtp...
> thanks,
> cs
>
>
>
>>
>>
>> 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?
>>>> (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$
> <https://urldefense.com/v3/__https:/lists.geant.org/sympa/info/rare-dev__;!!NEt6yMaO-gk!A59Wtzze5x4eOQxBLlnguTfpAaa2HGflokDSjkIZ0hXDMoIhizXcubIqBRIGZGsmYdmRFY5p$>
>>> <https://urldefense.com/v3/__https:/lists.geant.org/sympa/info/rare-dev__;!!NEt6yMaO-gk!A59Wtzze5x4eOQxBLlnguTfpAaa2HGflokDSjkIZ0hXDMoIhizXcubIqBRIGZGsmYdmRFY5p$
> <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 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$>>>> <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$ <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 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
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 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/event s/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
>>>
>
>
> Juniper Business Use Only
>


Juniper Business Use Only




Archive powered by MHonArc 2.6.19.

Top of Page