Rare project developers

[mc36 <>]

-------- Forwarded Message --------
Subject: Re: Ping me Csaba if that's your current email ...
Date: Tue, 23 Aug 2022 20:57:00 +0200
From: mc36 <>
To: Kaliraj Vairavakkalai <>, Tamas Mondal 
<>, Krzysztof Szarkowicz <>
CC: Antoni Przygienda <>, Natrajan Venkataraman <>, 
Reshma Das <>

hi,

On 8/23/22 19:57, Kaliraj Vairavakkalai wrote:
> Yes,    demo together    is fine. Nats is in LA, where Nanog will be 
> happening. So you can join him there, may be?
i'm in budapest, hungary, europe... i can travel but, i prefer to participate 
remotely:
the thing is that, i'm an external contractor and they does not cover the 
costs...

> You can talk about MD-VPN use-case, and how BGP-CT fits in there at the GEANT 
> AS, complementing BGP-LU.
>
> Nats can talk about the Junos side explanation, and answer any overview 
> questions.
fineee!

> > ibgp-ct works in freerouter already, that's why i mentioned that the 
> > outermost label will be constant, that is, will not have color...
> > aka seamless mpls, but with bgp-ct instead of bgp-lu, i can already give you 
> > the config for that 3 node as2 core... :)
>
> I think what you mean is, ibgp-ct resolves over best-effort tunnels today. 
> Just like ibgp-lu. Got it.
>
> That is also useful in some scenarios (e.g. when color tunnels don   t exist 
> in that as2 domain). So yes,
>  > we can do that 3 node as2 core with best-effort tunnels, for the demo.
so if you accepted that the single node as2 was color aware then,
the 3 node as2 will be color aware from as1 and as3 point of view...
(internally it won't be for now, but i'll change soon...)
pe1----p----pe2
the p wont do a thing but a choice of routing protocol, and label 
distribution...
the pe1 will speak ebgp-ct to as1 as before and ibgp-ct to pe2...
but, in freerouter the bgp-ct became a drop-in replacement of bgp-lu....
for example i already have a csc-vpn test case with bgp-ct:
https://github.com/rare-freertr/freeRtr/tree/master/cfg/rout-bgp667.tst
the only cheating here is that the p wont see the colors,
but that's what will change very soon... :)

> And sure, we will help with the junos side config. We will first try to get 
> freertr
>
> up in my lab locally. :) That can be used as interop tests internally.
niceee!!! let me know if you need anything! it's ugly very different than 
junos,
so don't let it f*ck up your brain, just drop me a mail and i'm more than 
happy
to jump into a vc... :)

> But the real    end-to-end SLA preserving    will happen only when freertr 
> ibgp-ct with a transport-target:0:100 is able
>
> to resolve over a rsvp-te/srte/flexalgo tunnel of color 100. I was talking 
> about making that part also work.
yeahh, fully agreeing....
so 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...
that's for the sr things... for the rsvp-te, well, it's the cisco's 
auto-tunnel way in freerouter, that is,
a template cloned per ibgp nexthop... you can write any affinity/etc 
requirements to that template already...
the sr-policy thing is not yet there, just as an afi, but, as things seems to 
get started, and you gave
me a good use case to do the stuff, so, i bet you it'll arrive soon too... :)

> If there is any question on this part during the demo, we can say that part 
> is in the works, for future release.
sure thing, and the same is true for the freerouter part... :)

thanks,
cs

> Thanks
>
> Kaliraj
>
> *From: *mc36 <>
> *Date: *Tuesday, August 23, 2022 at 9:44 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]
>
>
> hi,
>
> On 8/23/22 17:47, Kaliraj Vairavakkalai wrote:
> > > what is your preference, should i host the vms and provide you access to them
> >         or you feel more convenient if you run it in your infra?
> >
> > My preference would be that you are the one doing the demo, please :). We 
> > haven     t decided the venue yet. It could be at NANOG.
> i'm far below an average jncia neteng so my best offer is to do the demo 
> together with the complex topology...
> tbh i even was not able to originate a single bgp-ct route so instead i hoped 
> you implemented what was written... :)
> so if you still would prefer to i should do it alone, then i would go with 
> just a freertr-vsrx-freertr stuff...
> or maybe both?
>
>
> > And we could just give a pointer to that recorded demo-presentation/video in 
> > IETF.
> sure! i also hate london, too wet for me... :)
>
> > Also, we wanted to ask you, can we add you to the authors/contributor list in 
> > the BGP-CT IETF draft? Please let us know. :)
> surely, yess, and i cannot express the appreciation...
> even i don't know that i did anything for that... but hell, yeahhh! :)
>
> > > helping me with brainstorming about the planning or even jumping into the 
> > > development? :)
> >
> > Both, actually. :)
> > Natz and I were eager to understand how nexthop resolution process works in 
> > freertr, and imagine how it can be enhanced to resolve over       tunnels of 
> > a color     .
> > i.e. whether the current resolution-logic can be just       scaled out       
> > to work on a different instance (one per color) of nexthop-database.
> > I downloaded the freertr code to browse
> > thru, but haven     t made much progress since then.
> sounds crazy good! :) we have a public list at 
> https://urldefense.com/v3/__https://lists.geant.org/sympa/info/rare-dev__;!!NEt6yMaO-gk!BbosUmjNPpCa6Mhvb_cO5fMwtTTlyDHkpBna6n-rSkJCBdF_qZ7TualjEvfkHP-MMQKoEAqX$ 
> <https://urldefense.com/v3/__https:/lists.geant.org/sympa/info/rare-dev__;!!NEt6yMaO-gk!BbosUmjNPpCa6Mhvb_cO5fMwtTTlyDHkpBna6n-rSkJCBdF_qZ7TualjEvfkHP-MMQKoEAqX$>
> if that does not work for a reason, then the 
> https://urldefense.com/v3/__https://groups.io/g/freertr/__;!!NEt6yMaO-gk!BbosUmjNPpCa6Mhvb_cO5fMwtTTlyDHkpBna6n-rSkJCBdF_qZ7TualjEvfkHP-MMQtXvfSc$ 
> <https://urldefense.com/v3/__https:/groups.io/g/freertr/__;!!NEt6yMaO-gk!BbosUmjNPpCa6Mhvb_cO5fMwtTTlyDHkpBna6n-rSkJCBdF_qZ7TualjEvfkHP-MMQtXvfSc$>     is connected to
> https://urldefense.com/v3/__https://lists.geant.org/sympa/info/rare-users__;!!NEt6yMaO-gk!BbosUmjNPpCa6Mhvb_cO5fMwtTTlyDHkpBna6n-rSkJCBdF_qZ7TualjEvfkHP-MMXllMsNV$ 
> <https://urldefense.com/v3/__https:/lists.geant.org/sympa/info/rare-users__;!!NEt6yMaO-gk!BbosUmjNPpCa6Mhvb_cO5fMwtTTlyDHkpBna6n-rSkJCBdF_qZ7TualjEvfkHP-MMXllMsNV$>
> i'm more than happy to answer, but, can we take these freertr specific parts 
> to the public?
> regarding the code, well, actually sorry for hurting your eyeballs....
> basically i write c code to java files with some exceptions...:)
>
>
>
> > > i see that is's still a cheat, but just for the demo, does it make the 
> > > topology more attractive?
> >
> > For demonstrating EBGP-CT, the MD-VPN solution and topology with single ASBR 
> > seems perfect.
> okk then, i need your help on he surrounding junos as1 and as3..
> the asbr3 config is there, i saw it working, maybe needs 1-2 knobs but 
> heyy... :)
>
> > IMHO, (to make judicious use of your time), further effort should be directed 
> > to make IBGP-CT work on freertr, with any one transport-protocol.
> ibgp-ct works already... so if you still would go with an as2 consisting of 
> more freerouters,
> i'm more than happy to prepare an other test case with more core routers in 
> as2... :)
>
> > And, Fyi: Junos BGP-CT only supports the following transport-protocols today: 
> > rsvp-te, srte, isis-flexalgo. It does not support ospf-flexalgo yet.
> freerouter right now have nothing else but bgp-ct when it comes to colors...
> but it'll change if you see my design idea about the rd=0:algo could work... 
> :)
> (basically that's how i handle the bgp-ct right now, and i see it feasible 
> for the igps too...:)
> maybe it won't be a fully fledged solution as yours, but more than 
> nothing.... :)
>
>
> > So, following statement is intriguing:
> >
> > > have, i realized that i even does not announce nor calculate the flexalgo
> >         part of nor isis nor ospf... and, doing so is about a day of work but
> >         reminded me the real reason: the e-lsa in ospf3 seems to be completely
> >         missing everywhere? but without that, i have to comment out half of 
> > the
> >         the colorful ospf interops... (i have it already for rsvp6-te but when
> >         i turn it on just with the hostname of the e-router-info, we lose the
> >         ospfv3 database for a while:)
> >
> > Do you mean IBGP-CT (colored resolution) works on freertr with 
> > rsvp-te/rsvp6-te? If so then we could do
> ibgp-ct works in freerouter already, that's why i mentioned that the 
> outermost label will be constant, that is, will not have color...
> aka seamless mpls, but with bgp-ct instead of bgp-lu... so that one works, i 
> can already give you the config for that 3 node as2 core... :)
> the cheat here is that the labels' colors will be preserved between the two 
freerouter pes through the p, but the p wont see them...
> for now.... :)))
>
>
> > rsvp-te/rsvp6-te in one AS (freertr) and rsvp-te/srtev6 in another AS(junos).
> >
> > (Junos doesn     t implement rsvp6-te today, but implements srtev6.)
> srtev6 -- with isis, right? so it's not the 
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/rfc8362__;!!NEt6yMaO-gk!BbosUmjNPpCa6Mhvb_cO5fMwtTTlyDHkpBna6n-rSkJCBdF_qZ7TualjEvfkHP-MMbv7A_Wb$ 
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc8362__;!!NEt6yMaO-gk!BbosUmjNPpCa6Mhvb_cO5fMwtTTlyDHkpBna6n-rSkJCBdF_qZ7TualjEvfkHP-MMbv7A_Wb$>     plus the 
> srtev6 drafts?
> with isis, i cover that with an interop already: 
> https://urldefense.com/v3/__https://github.com/rare-freertr/freeRtr/blob/master/cfg/intop9-isis07.tst__;!!NEt6yMaO-gk!BbosUmjNPpCa6Mhvb_cO5fMwtTTlyDHkpBna6n-rSkJCBdF_qZ7TualjEvfkHP-MMfd7MTch$ <https://urldefense.com/v3/__https:/github.com/rare-freertr/freeRtr/blob/master/cfg/intop9-isis07.tst__;!!NEt6yMaO-gk!BbosUmjNPpCa6Mhvb_cO5fMwtTTlyDHkpBna6n-rSkJCBdF_qZ7TualjEvfkHP-MMfd7MTch$>
> and here the pweth2 on r1 and r3, which an eompls over ipv6 prefixes...
>
> and yeahh, in freerouter, everything is dual stack and works over ospf and 
> isis too, rsvp-te is not an exception... :)
>
> https://urldefense.com/v3/__https://github.com/rare-freertr/freeRtr/blob/master/cfg/mpls-te01.tst__;!!NEt6yMaO-gk!BbosUmjNPpCa6Mhvb_cO5fMwtTTlyDHkpBna6n-rSkJCBdF_qZ7TualjEvfkHP-MMTLxc-Zr$
>  
> <https://urldefense.com/v3/__https:/github.com/rare-freertr/freeRtr/blob/master/cfg/mpls-te01.tst__;!!NEt6yMaO-gk!BbosUmjNPpCa6Mhvb_cO5fMwtTTlyDHkpBna6n-rSkJCBdF_qZ7TualjEvfkHP-MMTLxc-Zr$>
> cd src ; ./tw.sh mpls-te01 capture r1 eth1
> gave me the attached capture... it's yellow in wireshark at some packets but 
> imho it's not me.... :)
> btw that test case have some extra commands at the end resulting a screenshot 
> and it updates as the ci-cd works:
> https://urldefense.com/v3/__http://www.freertr.org/screen/mpls-te.html__;!!NEt6yMaO-gk!BbosUmjNPpCa6Mhvb_cO5fMwtTTlyDHkpBna6n-rSkJCBdF_qZ7TualjEvfkHP-MMQAJ5J0T$ 
> <https://urldefense.com/v3/__http:/www.freertr.org/screen/mpls-te.html__;!!NEt6yMaO-gk!BbosUmjNPpCa6Mhvb_cO5fMwtTTlyDHkpBna6n-rSkJCBdF_qZ7TualjEvfkHP-MMQAJ5J0T$>
>
> thanks,
> cs
>
>
> > Thanks
> >
> > Kaliraj
> >
> > *From: *mc36 <>
> > *Date: *Tuesday, August 23, 2022 at 12:39 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]
> >
> >
> > hi,
> >
> > On 8/22/22 23:37, Kaliraj Vairavakkalai wrote:
> > > True - ASBR3 does not need to implement the resolution part of the draft for 
> > > this scenario.
> > >
> > > Given this is a practical scenario, we can indeed demo this. It provides 
> > > complete functionality
> > >
> > > of preserving inter-domain SLA for the MD-VPN solution, and demonstrates 
> > > bgp-ct on the wire interop.
> >
> > i was thinking a bit about it further, and, i can provide a core instead of 
> > asbr3 with the following:
> > so if we replace asbr3 with a pe-p-p-pe, where the 2 pe speak ibgp-ct 
> > internally too,
> > then we'll have 3 labels at the two p boxes:
> > the outer label to reach the other pe, (and i well know that it'll constant 
> > for now:)
> > the middle label will be the color label allocated between the two pe boxes,
> > and the inner label will be service label allocated by the surrounding junos 
> > ases...
> >
> > i see that is's still a cheat, but just for the demo, does it make the 
> > topology more attractive?
> >
> > thanks,
> > cs
> >
> >
> > Juniper Business Use Only
>
>
> Juniper Business Use Only