Skip to Content.

rare-dev - [rare-dev] Fwd: Ping me Csaba if that's your current email ...

Subject: Rare project developers

List archive


[rare-dev] Fwd: Ping me Csaba if that's your current email ...


Chronological Thread 
  • From: mc36 <>
  • To: "" <>
  • Subject: [rare-dev] Fwd: Ping me Csaba if that's your current email ...
  • Date: Wed, 24 Aug 2022 23:28:20 +0200




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




Archive powered by MHonArc 2.6.19.

Top of Page