RARE user and assistance email list

[Niall Donaghy <>]

Hi Csaba,

Apologies for the late reply but I've had to prioritise.

I see the main question, and hope this answers: our current production Junos 
code does not feature bgp inet(6) transport tables.

Br,
Niall

Niall Donaghy
Senior Technical Product Manager
GÉANT
M: +44 (0) 7557770303

Please note my work days are Tuesday through Friday.

Networks • Services • People 
Learn more at www.geant.org​
​​ 
GÉANT Vereniging (Association) is registered with the Chamber of Commerce in 
Amsterdam with registration number 40535155 and operates in the UK as a 
branch of GÉANT Vereniging. Registered office: Hoekenrode 3, 1102BR 
Amsterdam, The Netherlands. UK branch address: City House, 126-130 Hills 
Road, Cambridge CB2 1PQ, UK.

-----Original Message-----
From: mc36 <> 
Sent: Saturday, February 11, 2023 10:15 PM
To: Niall Donaghy <>
Cc: Natrajan Venkataraman <>; Manish Gupta 
<>; Kaliraj Vairavakkalai <>; 
Reshma Das <>; 
Subject: Re: confirmation of presence of a feature in the geant backbone...

so just to quickly convince you hereby we don't want you to lie them or 
anything! (as my mail seems a bit biased after rereading...) so please take 
your time, study a bit the topic... i already got a bouncer about you're on 
your leave :) so the two competing drafts we're talking about are these:
https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-car/
https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-ct/
when i initially got noticed about the two, just after checking the nrli 
encodings it was clear that -ct is the way simpler.
well it can be -car also but recently mrs nobody (somebody 
fixme/stopme/killme?) decided to merge the two drafts but somehow came up 
with something very ietf-car alike structure, but a bit more complicated, and 
at least heavily cisco-biased one...
then i quickly started experimenting original -car and well it was that bad 
as i thought...
for example imho no way to keep the prefixes sorted properly because of the 
variable length nlri encoding with the non-key fields... now which one would 
be the first in your imaginary sorting algorithm?
1.1.1.1/32:red ?
1.1.1.1/32:red+label=123 ?
1.1.1.1/32:red+index=123 ?
1.1.1.1/32:red+srv6=1234::1 ?
and that latter 2, so for example we have a whole bgp attribute just for 
doing sr(v6) properly in bgp:
https://www.rfc-editor.org/rfc/rfc8669.html and it was cisco and they really 
have at least a decoder in shows for it already!!!!
then why do they want it be there in the nlri once again!? and again, why the 
key vs non-key parts???
so my overall opinion is please stop killing bgp! "it hurts me doc when 
you're doing this"
and i had some other smaller question marks also during implementing -car... 
:( br, cs

On 2/11/23 22:56, mc36 wrote:
> hi niall,
> 
> could we involve you in helping us a bit? if everything is fine, it's as 
> easy as barking something to this thread:
> https://mailarchive.ietf.org/arch/msg/idr/k__lr9ccF_IGvwktg7tlhJiz640/
> 
> long story short:
> - could you please disclose what version of junos are you running in bud.mx?
> - do you have the any show commands for this new address-family called 
> "inet(6) transport" there?
>     
> https://github.com/rare-freertr/freeRtr/blob/master/cfg/intop9-bgp20.tst#L90
>     
> https://github.com/rare-freertr/freeRtr/blob/master/cfg/intop9-bgp20.tst#L94
>     please take a look below, it looks like that after running this 
> specific test on junos22.4
>     as far as i know it should be there in junos21.4 and upwards but 
> natv@junos please fixme!
> - when rare team had a stub pe in geant isis thanks to you, i saw your 
> segment routing indexes allocated network-wide
>     for ipv4 and ipv6 which is nice! it's a prerequisite for the inner core 
> workings as far as i know...
> - the issue is that seemingly cisco started a counter-draft a year later 
> than junos's -ct draft and it's shitty
>     as hell and seemingly no working code available: 
> https://mailarchive.ietf.org/arch/msg/idr/RBlS9j7U1mXdPjg9klYIQB4aJZ4/
> - so if you have something, and you would be kind enough to express on 
> idr@ietf that geant could be interested at least to evaluate
>     the bgp-ct, that would be extra cool from your side! you could think 
> about it as a plane-a-b version of geant's current mdvpn offering...
>     but you would not be able to provide it eu-wide until our vendor 
> (c1$c0) picks up the right track and stops talking/doing bullshit.
> 
> thank you soo much in advance,
> csaba
> 
> mc36@vsrx> show bgp summary
> Threading mode: BGP I/O
> Default eBGP mode: advertise - accept, receive - accept
> Groups: 2 Peers: 4 Down peers: 0
> Table                   Tot Paths   Act Paths Suppressed       History Damp 
> State       Pending
> bgp.transport.3
>                                               8                   6         
>           0                   0                   0                   0
> bgp.transport-inet6.3
>                                               4                   4         
>           0                   0                   0                   0
> Peer                                         AS           InPkt         
> OutPkt       OutQ     Flaps Last Up/Dwn 
> State|#Active/Received/Accepted/Damped...
> 1.1.1.1                                     1                 14            
>        9             0             0               3:23 Establ
>     bgp.transport.3: 2/4/4/0
> 1.1.2.1                                     3                 13            
>        9             0             0               3:27 Establ
>     bgp.transport.3: 4/4/4/0
> 1234:1::1                                 1                 14              
>      9             0             0               3:19 Establ
>     bgp.transport-inet6.3: 2/2/2/0
> 1234:2::1                                 3                 13              
>      9             0             0               3:20 Establ
>     bgp.transport-inet6.3: 2/2/2/0
> 
> mc36@vsrx> show route table bgp.transport.3
> 
> bgp.transport.3: 6 destinations, 8 routes (6 active, 0 holddown, 0 
> hidden)
> + = Active Route, - = Last Active, * = Both
> 
> 0:0:1.1.1.0/88
>                                       *[BGP/167] 00:05:59, localpref 100
>                                             AS path: 1 I, validation-state: 
> unverified
>                                         >   to 1.1.1.1 via ge-0/0/0.0, Push 
> 352173
> 0:0:1.1.2.0/88
>                                       *[BGP/167] 00:06:03, localpref 100
>                                             AS path: 3 I, validation-state: 
> unverified
>                                         >   to 1.1.2.1 via ge-0/0/1.0, Push 
> 617898
> 0:0:2.2.2.1/96
>                                       *[BGP/167] 00:05:59, localpref 100
>                                             AS path: 1 I, validation-state: 
> unverified
>                                         >   to 1.1.1.1 via ge-0/0/0.0, Push 
> 352173
> 0:0:2.2.2.3/96
>                                       *[BGP/167] 00:06:03, localpref 100
>                                             AS path: 3 I, validation-state: 
> unverified
>                                         >   to 1.1.2.1 via ge-0/0/1.0, Push 
> 617898
> 0:0:3.3.3.0/94
>                                       *[BGP/167] 00:06:03, localpref 100
>                                             AS path: 3 I, validation-state: 
> unverified
>                                         >   to 1.1.2.1 via ge-0/0/1.0, Push 
> 617898
>                                         [BGP/167] 00:05:59, localpref 100
>                                             AS path: 1 I, validation-state: 
> unverified
>                                         >   to 1.1.1.1 via ge-0/0/0.0, Push 
> 352173
> 0:0:3.3.3.4/94
>                                       *[BGP/167] 00:06:03, localpref 100
>                                             AS path: 3 I, validation-state: 
> unverified
>                                         >   to 1.1.2.1 via ge-0/0/1.0, Push 
> 617898
>                                         [BGP/167] 00:05:59, localpref 100
>                                             AS path: 1 I, validation-state: 
> unverified
>                                         >   to 1.1.1.1 via ge-0/0/0.0, Push 
> 352173
> 
> mc36@vsrx> show route table bgp.transport-inet6.3
> 
> bgp.transport-inet6.3: 4 destinations, 4 routes (4 active, 0 holddown, 
> 0 hidden)
> + = Active Route, - = Last Active, * = Both
> 
> 0:0:1234:1::/96
>                                       *[BGP/167] 00:06:14, localpref 100
>                                             AS path: 1 I, validation-state: 
> unverified
>                                         >   to 1234:1::1 via ge-0/0/0.0, 
> Push 537370
> 0:0:1234:2::/96
>                                       *[BGP/167] 00:06:15, localpref 100
>                                             AS path: 3 I, validation-state: 
> unverified
>                                         >   to 1234:2::1 via ge-0/0/1.0, 
> Push 905095
> 0:0:4321::1/192
>                                       *[BGP/167] 00:06:14, localpref 100
>                                             AS path: 1 I, validation-state: 
> unverified
>                                         >   to 1234:1::1 via ge-0/0/0.0, 
> Push 537370
> 0:0:4321::3/192
>                                       *[BGP/167] 00:06:15, localpref 100
>                                             AS path: 3 I, validation-state: 
> unverified
>                                         >   to 1234:2::1 via ge-0/0/1.0, 
> Push 905095
> 
> mc36@vsrx>
>

Attachment: smime.p7s
Description: S/MIME cryptographic signature