Rare project developers

[Kaliraj Vairavakkalai <>]

> please let us know if you find anything else or need any other help to show them the 2nd interop?

 

Csaba, we need the EANTC interop to succeed. Is it possible to make that happen?

 

Will you be able to join remotely? Or can someone else available on site help?

 

Nats and Reshma have registered for EANTC and got access.

 

We were trying to work with other GEANT participants on site (Simon?) and try to

save the event. But Anton could not reach Simon, I believe, to wire up the topology.

 

If we can have someone from GEANT work with Anton, and us – to save the EANTC

interop event, that would be great. Nats can show the same IETF demo topology

at EANTC too. We just need some ‘on the ground’ support from GEANT.

 

Thanks,

Kaliraj

 

From: Natrajan Venkataraman <>
Date: Tuesday, March 14, 2023 at 9:01 PM
To: mc36 <>, <>
Cc: Krzysztof Szarkowicz <>, Anton Elita <>, Reshma Das <>, Kaliraj Vairavakkalai <>
Subject: Re: [rare-dev] BGP CT interop - Colorful Resolution

Hi Csaba,

 

Sure! Yes, we are very happy with the fixes you have committed for FreeRTR and we have a pretty solid demo.  I am composing a list of observed behavior w.r.t CT colorful resolution vs the expected BGP-CT draft behavior. I will share the same with you by PDT morning tomorrow. It is with respect to advertisement behavior and VRF forwarding behavior based on what configuration exists in the VRF definition. This will help us stay ahead of the InterOp report that is expected from IETF which, we can prepare together as we progress further.

 

Thanks in advance and stay tuned!

-Nats-

 

From: mc36 <>
Date: Tuesday, March 14, 2023 at 8:47 PM
To: Natrajan Venkataraman <>, <>
Cc: Krzysztof Szarkowicz <>, Anton Elita <>, Reshma Das <>, Kaliraj Vairavakkalai <>
Subject: Re: [rare-dev] BGP CT interop - Colorful Resolution

[External Email. Be cautious of content]


thank you so much for the feedback...

happy to hear that now you can demo something?

please let us know if you find anything else or need any other help to show them the 2nd interop?

thx,

cs

On 3/14/23 19:50, Natrajan Venkataraman wrote:
> Hi Csaba,
>
> ps: have you validates my sitload fix 4 the excessive bgp update?
>
> I have verified the fix. The fix is working fine.
>
> Thanks,
>
> -Nats-
>
> *From: *mc36 <>
> *Date: *Monday, March 13, 2023 at 11:08 AM
> *To: * <>
> *Cc: *Natrajan Venkataraman <>, Krzysztof Szarkowicz <>, Anton Elita <>, Reshma Das <>
> *Subject: *Re: [rare-dev] BGP CT interop - Colorful Resolution
>
> *[External Email. Be cautious of content]*
>
> we failed to upgrade the asic.... reason: no clearnet access on the venue.... ;(
>
> maybe in prage?
>
> ps: have you validates my sitload fix 4 the excessive bgp update?
>
> thx
>
> cs
>
> Get BlueMail for Android <https://urldefense.com/v3/__https:/bluemail.me__;!!NEt6yMaO-gk!Gx5_nVeLfwBMpUFVtAyF3EZXMGRlAWrcXqgTCnIg69vtpH8R-96HuDUlGJNB5Rmz8_LYJg$>
>
> On Mar 11, 2023, at 03:22, Kaliraj Vairavakkalai < <>> wrote:
>
>     Hi Csaba,
>
>     Sorry for the delay in response.
>
>     We are OK with what you and Anton are comfortable with for the EANTC demo.
>
>     For the IETF demo, we plan to use resolving BGP-CT routes over RSVP-TE tunnels,
>
>     using the virtual VM environment. Natz has that working.
>
>     It would have been good to use RSVP-TE tunnel for EANTC also. But if that   s not
>
>     possible because of hardware limitation...
>
>     wait, one question/thought:
>
>     >now it uses only 2 labels everywhere so the outer label is the color, the inner is the service...
>     >because of dataplane limitations (only 2 labels in hw)
>
>     What if we do Internet(IPv4-Unicast) as the service instead of L3VPN?
>
>     Then with just two labels (CT label and RSVP-TE label), will it be possible
>
>     to demonstrate IPv4-Unicast traffic resolving over BGP-CT interdomain LSP?
>
>     It will be two labels intra-domain, and one label on inter-AS link.
>
>     Thanks,
>
>     Kaliraj
>
>     *From: *mc36 <>
>     *Date: *Tuesday, March 7, 2023 at 11:24 PM
>     *To: *Kaliraj Vairavakkalai <>, Natrajan Venkataraman <>, <>, Krzysztof Szarkowicz
>     <>, Anton Elita <>
>     *Cc: *Reshma Das <>
>     *Subject: *Re: [rare-dev] BGP CT interop - Colorful Resolution
>
>     [External Email. Be cautious of content]
>
>
>     hi,
>
>     please find attached the final topology we'll go on the demo...
>
>     r3-r4-r5 are the nodes to look at, now no ugly route-policy at all,
>
>     just pure rt-import/export magic everywhere plus the new afi-vrf xxx set-vrf knob...
>
>     in the freerouter asn i keep a bgp-ctp session and no isis nor ldp...
>
>     now it uses only 2 labels everywhere so the outer label is the color, the inner is the service...
>
>     because of dataplane limitations (only 2 labels in hw) we'll go with this config at the plugfest!
>
>     thanks,
>     cs
>
>
>
>     On 3/3/23 12:01, mc36 wrote:
>     > hi, guys,
>     >
>     > imho from now, freerouter have cheat-less colorful resolution for vpnv4/vpnv6 afis:
>     >
>     > https://urldefense.com/v3/__https://github.com/rare-freertr/freeRtr/commit/335d83792d7123ca164691f124ceab71a98e21b9__;!!NEt6yMaO-gk!HEBLz8ryW8TQ-i7tWo_ne8DbLM3pL0_M3_g8ldQFRe73AjncdILqnDG-T-c-4U0CF8Izd-f7$ <https://urldefense.com/v3/__https:/github.com/rare-freertr/freeRtr/commit/335d83792d7123ca164691f124ceab71a98e21b9__;!!NEt6yMaO-gk!HEBLz8ryW8TQ-i7tWo_ne8DbLM3pL0_M3_g8ldQFRe73AjncdILqnDG-T-c-4U0CF8Izd-f7$>
>     >
>     > unfortunately this contains a smaller refactoring also, i just forgot to commit that beforehand... :)
>     >
>     >
>     > the code is still not covered by a test case, that will be the next,
>     >
>     > then i'll get back to you with a new topology for the plugfest...
>     >
>     > happy weekend,
>     > thanks,
>     > cs
>     >
>     > sid#show config-differences
>     > router bgp4 65535 vrf v1
>     >       afi-vrf niif set-vrf v2 ipv4
>     >       exit
>     >
>     > sid#clear ipv4 bgp 65535 all in vpnuni
>     > sid#show ipv4 route niif | first 10
>     > typ     prefix                                                     metric                 iface                     hop                                     time
>     > B             0.0.0.0/0                                         200/0                     null@v2:4     10.10.10.25     00:00:02
>     > B             4.0.0.0/9                                         200/0                     null@v2:4     10.10.10.25     00:00:02
>     > B             4.23.88.0/24                             200/0                     null@v2:4     10.10.10.25     00:00:02
>     > B             4.23.89.0/24                             200/0                     null@v2:4     10.10.10.25     00:00:02
>     > B             4.23.92.0/23                             200/0                     null@v2:4     10.10.10.25     00:00:02
>     > B             4.23.94.0/23                             200/0                     null@v2:4     10.10.10.25     00:00:02
>     > B             4.35.69.0/24                             200/0                     null@v2:4     10.10.10.25     00:00:02
>     > B             4.38.0.0/21                                 200/0                     null@v2:4     10.10.10.25     00:00:02
>     > B             4.38.8.0/21                                 200/0                     null@v2:4     10.10.10.25     00:00:02
>     >
>     > sid#configure revert
>     >                     1: router bgp4 65535 vrf v1
>     >                     2:     no afi-vrf niif set-vrf v2 ipv4
>     >                     3:     exit
>     >
>     > errors=0
>     >
>     > router bgp4 65535 vrf v1
>     >       afi-vrf niif set-vrf v2 ipv4
>     >       exit
>     >
>     > sid#clear ipv4 bgp 65535 all in vpnuni
>     > sid#show ipv4 route niif | first 10
>     > typ     prefix                                                     metric                     iface                     hop                                     time
>     > B             0.0.0.0/0                                         200/0                         null@v1:4     10.10.10.25     00:00:02
>     > B             4.0.0.0/9                                         200/0                         null@v1:4     10.10.10.25     00:00:02
>     > B             4.23.88.0/24                             200/0                         null@v1:4     10.10.10.25     00:00:02
>     > B             4.23.89.0/24                             200/0                         null@v1:4     10.10.10.25     00:00:02
>     > B             4.23.92.0/23                             200/0                         null@v1:4     10.10.10.25     00:00:02
>     > B             4.23.94.0/23                             200/0                         null@v1:4     10.10.10.25     00:00:02
>     > B             4.35.69.0/24                             200/0                         null@v1:4     10.10.10.25     00:00:02
>     > B             4.38.0.0/21                                 200/0                         null@v1:4     10.10.10.25     00:00:02
>     > B             4.38.8.0/21                                 200/0                         null@v1:4     10.10.10.25     00:00:02
>     >
>     > sid#
>     >
>     >
>     >
>     > On 2/28/23 23:21, mc36 wrote:
>     >> hi,
>     >>
>     >> On 2/28/23 22:39, Kaliraj Vairavakkalai wrote:
>     >>> That         s cool. So now we have two demo setups:
>     >>>
>     >>> 1/ Csaba         s setup with FreeRTR as Ingress-PE doing colorful resolution.
>     >>>
>     >>> 2/ Natz setup with FreeRTR as ASBR doing colorful resolution.
>     >>>
>     >>> We could have a combo of the two setups, to show FreeRTR in both ASBR and ingress-PE roles.         ;)
>     >>>
>     >>
>     >> well, for a really really proper color resolution imho i need to introduce the "afi-vrf cust-blue resolve-in core-blue" knob...
>     >> it'll simply set the route's underlaying table like when we need to send out a vrf packet in mpls in the core vrf, but here,
>     >> it'll a per vrf override that i'll set that paramter to a user defined table... no fallback yet, just a static mechanism...
>     >> that'll be the first tomorrow what i'll start playing with... :)
>     >>
>     >>
>     >>> Just some comments -
>     >>>
>     >>> It         s worth noting that:
>     >>>
>     >>>                   route-policy ibgp-in
>     >>>
>     >>>                           sequence 10 if extcomm 2562:0:100
>     >>>
>     >>>                           sequence 20                 set vrf v2 ipv4
>     >>>
>     >>>                           sequence 30                 pass
>     >>>
>     >>>                           sequence 40 enif
>     >>>
>     >>>                           sequence 50 if extcomm 2562:0:200
>     >>>
>     >>>                           sequence 60                 set vrf v3 ipv4
>     >>>
>     >>>                           sequence 70                 pass
>     >>>
>     >>>                           sequence 80 enif
>     >>>
>     >>>                           sequence 90 drop
>     >>>
>     >>>                           exit
>     >>>
>     >>> This policy config kind of implements the             resolution-scheme         . :)
>     >>>
>     >>
>     >> yeahh, i knew that matching against the rd is not the color but the path... :)
>     >>
>     >>
>     >>
>     >>> It works with LDP tunnels in VRFs v2, v3. BGP-CT routes are able to resolve over LDP routes
>     >>>
>     >>> (in main VRF v1 or color VRFs v2,v3), and create SWAP routes properly.
>     >>>
>     >>> We could not make BGP routes resolve over RSVP-TE Tunnel routes in any VRF. That         s why we used
>     >>>
>     >>> LDP-tunnels in previous IETF demo as-well. We may be missing something there.
>     >>
>     >> so that was just another dirty hack that i put the rsvp to a dummy vrf to have a color on it.... :)
>     >>
>     >>
>     >>>
>     >>> And, the code-change in rtrBgpNeigh.java was needed to make the following config work:
>     >>>
>     >>
>     >> [..]
>     >>
>     >> let's discuss this on my previous mail, i did a lot of changes to that part as i realized
>     >> that you were right and a lot were missing on that part of the code.... :)
>     >> thanks again for spotting it... :)
>     >>
>     >> thanks,
>     >> cs
>
>     Juniper Business Use Only
>
>
> Juniper Business Use Only
>

 

Juniper Business Use Only

Juniper Business Use Only