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$
>
> 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
