Rare project developers

[mc36 <>]

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

hi,

On 8/22/22 23:37, Kaliraj Vairavakkalai wrote:
> (Restating the topology with fixed-width font, for readability:)
>
>
>               as1                   as2                   as3
>
> pe----p----asbr1             asbr4----p-----pe
>     |       |           |   \         /     |         |           |
>     |       |           |     asbr3       |         |           |
>     |       |           |   /         \     |         |           |
> pe----p----asbr2             asbr5----p-----pe
>
> > here as1 will be fully junos zone, as2 will be a single freerouter consisting 
> > of asbr3, and as3 will be fully junos zone again...
> > (it's a bgp-lu for now, and geant provides rr for the vpns but it could be 
> > bgp-ct and without any rr to simplify things -- or if you wish, asbr3
> can be an vpn rr with next-hop-unchanged and so on...)
>
> That   s nice to know. Given this MD-VPN topology is a practical real world 
> deployment
>
> scenario today, yes this will work for demo.
imho you also know other examples, and i also remember some, but this one is 
public and heavily used,
and geant runs junos but for example kifu on the list is a cisco shop so you 
two really should agree
upon on a common afi to not ruin the game... :)


> Having    VPN RR with nexthop-unchanged    will be good. As its more 
> practical than having
>
> full bgp mesh across these nren ASes.
sure thing, i'll add a new process for that on asbr3...


> 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.
okk, then let's do this... 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? imho for that latter 
i wont need any access because
the asbr3 config is really simple, and if it still misses a bit here or 
there, we can have a quick vc?


> But, personally I would really like to be able to help you to complete the 
> bgp-ct resolution part
>
> of support also on freertr such that it can play SN and BN roles in as1 and 
> as3. That is not for
>
> this ietf demo, but for your practical deployment in real-world usage.

i cannot express how much i appreciate the repeated offer of your help!
well, i changed my mind about the topology because after checked what i
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:)

thanks,
cs


> Thanks
>
> Kaliraj
>
> *From: *mc36 <>
> *Date: *Monday, August 22, 2022 at 1:18 PM
> *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 17:05, mc36 wrote:
> > tony mentioned the showoff of bgp-ct at ietf which is fine and i'm more
> > than happy to make a small pptx showing the interop from my perspective,
> > that is, i can traverse a vpn through a vsrx... which would not be more
> > than making some screenshots from the test case and adding some text...
> > the reason i did not done it already is that i have the feeling that
> > you would so something much more complex?
>
> so i was thinking about it further, and if that's the case, then imho the 
> easiest way
> is to show them both the bgp-ct afi and the forwarding at the same time is 
> the following:
>
>               as1                   as2                   as3
>
> pe----p----asbr1             asbr4----p-----pe
>     |       |           |   \         /     |         |           |
>     |       |           |     asbr3       |         |           |
>     |       |           |   /         \     |         |           |
> pe----p----asbr2             asbr5----p-----pe
>
> here as1 will be fully junos zone, as2 will be a single freerouter consisting 
> of asbr3, and as3 will be fully junos zone again...
>
> so as1 and as3 are different eu nrens, and as2 is the geant and we're demoing the thing they call mdvpn 
> (https://urldefense.com/v3/__https://network.geant.org/vpn-services/__;!!NEt6yMaO-gk!GhNqUi9akqwnkXJd2YcMOTdJ-XV3RkA1HoiJBYO_z5AhSmXMa1ORLvRZyQNvzFE4Qtbhaqyq$ )...
> (it's a bgp-lu for now, and geant provides rr for the vpns but it could be 
> bgp-ct and without any rr to simplify things -- or if you wish, asbr3
> can be an vpn rr with next-hop-unchanged and so on...)
>
> then i asbr3 can already process and install for forwarding any number of 
> different rd for a given prefix...
>
> i prepared a test case showing off this scenario, but with only 3 routers 
> from the 3 ases (attached)
> (you can run it if you yourself if you do the following: cp ~/zzz.tst cfg/ ; 
> cd src ; ./tw.sh zzz )
>
> r1 is in as1, r2 is in as2 and r3 is in as3... both r1 and r3 have 2 links to 
> r2: r1===r2===r3
> r1 and r3 have a locally routed eompls in between them to test the end to end 
> mpls...
> r2 would be asbr3 in the ietf showoff topology btw...
>
> if you take a closer look at r1 and r3 configs, i rewrite the rd to 1234:1 
> and 1234:2
> on the two links when advertising, so r2 considers these two as different 
> paths,
> allocates a label for them and installs them for forwarding too...
> r1 and r2 then rewrite when receiving, to be selected and installed locally...
>
> after running the topology, i see the following (you'll get different labels 
> because freerouter
> randomizes everything that is not fixed to fuzzy-test a bit the stacks it 
> meets with...:)
>
> on r2 (which have nothing hackish in it's config) i see the two paths with 2 
> labels allocated:
>
> r2#show ipv4 labels v1 | hinclude 2.2.2.1
> prefix             local       remote     hop
> 2.2.2.1/32     248166     212627     1.1.1.1
> 2.2.2.1/32     531497     212627     1.1.1.5
>
> r2#show ipv4 labels v1 | hinclude 2.2.2.3
> prefix             local       remote     hop
> 2.2.2.3/32     757777     1034378   1.1.1.10
> 2.2.2.3/32     487991     1034378   1.1.1.14
>
> r2#
>
> after removing a hack from r1, i see them arriving:
>
> r1#show config-differences
> router bgp4 1
>     no neighbor 1.1.1.6 route-policy-in in
>     exit
>
> r1#show ipv4 bgp 1 neighbor 1.1.1.6 ctp learned 2.2.2.3/32 1234:1 | include 
> label
> alt0   evpn label*16             0
> alt0   pmsi label*16             0
> alt0   local label                 null
> alt0   remote label               757777
>
> r1#show ipv4 bgp 1 neighbor 1.1.1.6 ctp learned 2.2.2.3/32 1234:2 | include 
> label
> alt0   evpn label*16             0
> alt0   pmsi label*16             0
> alt0   local label                 null
> alt0   remote label               487991
>
> r1#
>
> the label switcing obviously works... so what's your opinion, could this r2 
> do the job?
>
> thanks,
> cs
>
>
> Juniper Business Use Only