RARE user and assistance email list

[mc36 <>]

well actually not a fature but a bugga??

XDDDDDDDDDDD



s0rry s0me0n3 m3nt10n4d atomkutatointezet a belv4r0sb4n? XDDDDDDDDDDDDDD

thx,

cs

On 3/21/23 16:50, Niall Donaghy wrote:
> 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>