RARE user and assistance email list

[mc36 <>]

hi,

so what arrived this spring is a colorful resolution for the unicast, let's 
call it global in cisco terminology...

 red         red---r5
r0-->r1---r2<--r4
blue         blue

so in the above topology we can separate the two colors while using a single 
link in between r1 and r2 with 1 bgp-ct session...

these are not mpls layer3 vpns in the term of address family yet, so no 
vpnv4/vpnv6 involved at the moment,
(however r1 and r2 can run two vpnv4/vpnv6 in the two vrfs imho to provide 
red-only and blue-only mpls vpns...)

so they're just imports from the global table (based on color extcomm) into 
separate colorful vrfs...

we can say, filtering aliases of the global bgp table...
(so unicast, labeled-unicast, -ct, -car, are all the same table under the 
hood here, like in cisco)

so to have proper vpnv4/vpnv6 above the red/blue vrfs with fallback to the 
other color is an other round here...

bonus: on r1 we can have an additional bgp-ct peering to r0, and on r2 we can 
have a bgp-lu to r5 in blue,
then r0 and r5 will be able to have a vpnv4/vpnv6 between each other for 
blue-only vpnv4/vpnv6... (but for now,
on r0, you can configure this over the global (or in the blue vrf import), 
but regardless what you do, it'll be
single-color only, so if that topology fails, the vpnv4/vpnv6 bgp will die 
with timeout)

so the rout-bgp670 of your choice, v1 is the global, v2..v3 are the color 
imports above v1...
but the v2's loopbacks are also visible & one-way reachable in v1... and if 
v1's loopback
is imported somehow int v2 somewhere then the ping will also work... (not 
shown in config)
let's call that bgp-ct extranet or hub&spoke bgp-ct or what... sorry for the 
confusion...:)

so how can i summarize this all up, hmmm: colorful resolution for the global 
traffic,
is all what we have now, with plans to continue to a more complete 
implementation,
which seems a never-ending story here as the protocols always evolve... :)

br,
cs

ps: shrinking mail body & adding list...




On 2/14/23 23:59, Kaliraj Vairavakkalai wrote:
> Reference to ietf115 demo:
>
> https://www.linkedin.com/feed/update/urn:li:activity:6995848035926712320?utm_source=share&utm_medium=member_desktop 
> <https://www.linkedin.com/feed/update/urn:li:activity:6995848035926712320?utm_source=share&utm_medium=member_desktop>
>
>        (topology detail at 1:23 in the video)
>
>       freeRtr ASBR config: https://github.com/neonatty/IETF_Hackathan_BGPCT_JUNOS_FreeRTR/blob/main/freertr-asbr21-sw.txt 
> <https://github.com/neonatty/IETF_Hackathan_BGPCT_JUNOS_FreeRTR/blob/main/freertr-asbr21-sw.txt>
>
> In above demo topo, in the freeRtr AS, LDP was used. i.e. best effort traffic.
>
> Now for the new demo,
>
> Question to Csaba: in the current new feature-set (colorful resolution) on 
> freeRtr, which transport-protocols
>
> are supported to be associated with transport-class/color? E.g. Is 
> RSVP-TE/LDP supported? And what is the configuration?
>
> In the following example unit-test config, I couldn   t find the transport color 
> config: http://sources.freertr.org/cfg/rout-bgp670.tst 
> <http://sources.freertr.org/cfg/rout-bgp670.tst>
>
> Once we know the current supported transport, we can plan on the demo 
> topology with minimal boxes.
>
> And I think it would be good to re-use the configs/topo for both IETF 
> (virtual boxes) and EANTC (physical boxes) demos.
>
> Thanks
>
> Kaliraj