Subject: Rare project developers
List archive
- From: Krzysztof Szarkowicz <>
- To: Kaliraj Vairavakkalai <>
- Cc: Mr. Csaba Máté <>, Tamas Mondal <>, Antoni Przygienda <>, Natrajan Venkataraman <>, Reshma Das <>, "" <>
- Subject: Re: [rare-dev] Ping me Csaba if that's your current email ...
- Date: Thu, 25 Aug 2022 06:49:07 +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=KKDJ4OcHdNWREOEjgYxZY5gGqbWUx8vEi7Ay1pt8ibU=; b=mNhvmHc/pYHaodQprRhIhOhQUAt1oAwWfmdC15B+y9QIr4uNsVGkxo5BsKWEyIqy8H+hJtdZNltGJXvYHX1XHh6zZGMBzpqGBoSGk9672n+RD+/eyCAo99CNz7KKXr8QnSDCsxApXPftY/22zWu5p++otCb7NSSklO62MVVJYretW6bqXqJ2ZFYTWKLvkmZrl+mjpuAraip1c24RKrc27usxyaB6haM+Y2MeU1ad469OrZu/EyVg7quwDmxP/dtfk5kcspLG11ZCTiamjkcqrd7KCb76Sra0gQgDHTXu1xRn4i0pTP0RXbFSIWrUsiG6qKO6KRICAEf8sjliycbHBQ==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=JPxRrkN2LpzgHsWnJ9Wn00q3nHAjaMPaLlIm102s/D0niTd51ZmB+NEZMj/fdamgWG2zcNa4yL72svd51rsiULDH3ABc74Q1C3VJfU1Nak38MUOmzvLJyYPQlRWzen3bz1aYUhRTTYo7RL1hxSQ/OclCJ85SPcitMS4NG3ppYya2XTEwuBNY08jdbq2gG1Zo/k2qiG8y3twuKZtYravBDCAa110Ex0lcmrpsmqFyhayXlUiqmeOurFKKGwaBupArQQ1yGljDp6/BGjiRYgtOe9ol0iE4wX6Z1umBs+LHHgrXoLV91Sj00inM8Rs8Bx/foPhftAqVzKXpereoSREx2g==
Kaliraj,
Could you point me to the version of "BGP CT 5G_Network_Slicing Webinar.pdf” shared with Csaba. Just wanted to have last look on it,.
Thanks,
—
Krzysztof Grzegorz Szarkowicz, Solution Architect, Mobile Transport | Phone: +49 89 203 012 127
Please consider my current timezone, when calling: CEST (UTC+02:00)
Krzysztof Grzegorz Szarkowicz, Solution Architect, Mobile Transport | Phone: +49 89 203 012 127
Please consider my current timezone, when calling: CEST (UTC+02:00)
On 2022 -Aug-24, at 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.ThanksKalirajFrom: 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$>
>>> 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$>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> 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 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/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
- [rare-dev] Fwd: Ping me Csaba if that's your current email ..., (continued)
- [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 ..., mc36, 08/26/2022
- Re: [rare-dev] Ping me Csaba if that's your current email ..., Kaliraj Vairavakkalai, 08/26/2022
- Re: [rare-dev] 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 ..., mc36, 08/26/2022
- Re: [rare-dev] 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 ..., mc36, 08/26/2022
- Re: [rare-dev] 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 ..., mc36, 08/26/2022
- Re: [rare-dev] Ping me Csaba if that's your current email ..., mc36, 08/29/2022
- Re: [rare-dev] Ping me Csaba if that's your current email ..., mc36, 08/29/2022
- Re: [rare-dev] Ping me Csaba if that's your current email ..., mc36, 08/29/2022
- Re: [rare-dev] Ping me Csaba if that's your current email ..., mc36, 08/29/2022
- Re: [rare-dev] Ping me Csaba if that's your current email ..., mc36, 08/29/2022
- Re: [rare-dev] Ping me Csaba if that's your current email ..., mc36, 08/29/2022
- Re: [rare-dev] Ping me Csaba if that's your current email ..., mc36, 08/29/2022
- Re: [rare-dev] Ping me Csaba if that's your current email ..., Antoni Przygienda, 08/29/2022
- Re: [rare-dev] Ping me Csaba if that's your current email ..., mc36, 08/29/2022
Archive powered by MHonArc 2.6.19.