RARE user and assistance email list

[mc36 <>]

sorry, i forgot to reply to an implicit, but very important part of the 
question of yours:
so by default, the srv6 dataplane is a source routing technique but at 
layer3. it have
the consequences that once it's enabled, you have to carefully protect at the 
edges,
and i recently saw an rfc about the default handling of the extension 
headers, and
not surprisingly, they suggested that these should be dropped by default...
and it's not surprises me at all, back in the time before cisco made default 
the
no ipv[4/6] source routing, we learned the hard way that a small isp used the
kifu backbone to traverse their own packets between two ix-es in two different
cities in hungary where we both peered to the shared layer2...
br,
cs



On 8/21/22 14:50, mc36 wrote:
> On 8/17/22 16:18, Tim Chown wrote:
> > Catching up after being off a while   
> >
> > So are there NRENs running SRv6?   I think SURF are running SR, and GEANT 
> > maybe?   But SRv6?
>
> kifu is running on cisco gear with ospf as igp... we run sr-mpls since cisco 
> introduced it...
> but sr in general have huge limitations when it comes to ospf: for ospfv2 
> (ipv4) they found
> very convenient ways to express the extensions but for ospfv3 (ipv6) they 
> came up with the
> thing called extended lsas, which, are now tlv based and one have to migrate 
> to it to enable
> anything fancy but ip routing.... i tried several times announcing just the 
> router information
> lsa (with my hostname) but the best that happened is we were not able to 
> query the database:
>
> RP/0/RSP0/CPU0:rtr2.vh#
> RP/0/RSP0/CPU0:rtr2.vh#show ospfv3 database
> Sun Aug 21 14:41:52.759 CEST
>
> Error retrieving data from OSPFv3 process 100 ('sysdb' detected the 'warning' 
> condition 'An invalid argument was passed to a SysDB function (maybe a NULL 
> pointer?)')
> RP/0/RSP0/CPU0:rtr2.vh#
> RP/0/RSP0/CPU0:rtr2.vh#
>
>
> sniffer.vh#configure revert
> 2022-08-21 14:42:14
>           1: router ospf6 100
>           2:   no area 0 hostname
>           3:   exit
>
> errors=0
>
> router ospf6 100
>    area 0 hostname
>    exit
>
> sniffer.vh#
>
>
>
> RP/0/RSP0/CPU0:rtr2.vh#show ospfv3 database
> Sun Aug 21 14:42:10.628 CEST
>
> Error retrieving data from OSPFv3 process 100 ('sysdb' detected the 'warning' 
> condition 'An invalid argument was passed to a SysDB function (maybe a NULL 
> pointer?)')
> RP/0/RSP0/CPU0:rtr2.vh#show ospfv3 database
> Sun Aug 21 14:43:05.011 CEST
>
>                         OSPFv3 Router with ID (195.111.97.109) (Process ID 
> 100)
>
>                         Router Link States (Area 0)
>
> ADV Router           Age                 Seq#             Fragment ID   Link 
> count   Bits
>
>
> [..]
>
>
> i'm much less knowledgeable when it cames to juniper but a quick google 
> showed me no migration guide for the new lsa format.... :(
>
> but it's a bit different with isis, fortunately, they used tlv from the start 
> for both v4 and v6 prefix advertisement...
> freerouter was part of the geant igp about a year ago because of a vmware 
> migration and frederic help me restore the
> link and forbidden me to request the relocation to the kifu 100g geant link 
> so i cannot show you but i clearly remember
> that geant had both v4 and v6 prefixes advertised with a prefix sid in their 
> isis... the dataplane imho still mpls btw...
>
> regarding srv6 dataplane, please let me continue it in my next email to 
> carmen...
>
> thanks,
> cs
>
>
>
>
>
>
> > I think most use cases to date are single domain, but interesting to see 
> > there are multiple implementations, even if as Csaba hints the sands are 
> > regularly shifting underneath(!)
> >
> > It   s the sort of thing one of our project reviewers would be interested to 
> > hear about.
> >
> > Tim
> >
> > > On 22 Jul 2022, at 14:17, mc36 <> wrote:
> > >
> > > hi,
> > > here is my first opinion:
> > >
> > > pros:
> > > -finally a feasible solution in terms of insertion point...
> > > (the barefoot proposal is a bit shitty with the layer4 port as indicator of 
> > > the header)
> > >
> > > cons:
> > > -they're proposing to overload hop-by-hop option, but, it's intended to pass 
> > > traffic to the control plane: rsvpv6 & pim6 uses it already...
> > > it just adds complexity if the dataplane have to distinguish in between these 
> > > cases going the parser deeper into the tlvs...
> > > -as it's an ip protocol afterall, there are 2 possibilities:
> > > 1) the dataplane will compute a different ecmp path as otherwise would do (the current state we have: 
> > > https://github.com/rare-freertr/freeRtr/blob/358f214db2af62be04e5bc1a8d0b654b7880a2f3/misc/p4bf/include/hsh_ipv4_ipv6_hash.p4#L96)
> > > 2) the additional complexity of continuing the parsing to have the proper 
> > > upper protocol...
> > > that latter, the walking a tlv list, is hard to do properly on anything but 
> > > npus or cpus!
> > >
> > > bonus: so we already support srv6 but unfortunately i have to revisit the 
> > > control plane parts yearly to make it compatible with the latest xr 
> > > releases... :(
> > >
> > > bonus2: as we're a router, and we support sr-te and rsvp-te, there is already 
> > > a standard method to trace the path and have a per node counter for a flow:
> > > if you have the question that a given flow have issues, you just create a 
> > > separate rsvp-te with the same path-options as the original,
> > > or auto if not yet specified, and it'll have it's own labels on all the 
> > > transit nodes, and each will have the associated counters...
> > >
> > > br,
> > > cs
> > >
> > >
> > >
> > > On 7/22/22 12:03, Simon Leinen wrote:
> > > > (To revisit an old discussion :-)
> > > > For SRv6 networks, draft-filsfils-spring-path-tracing[1] is advertised
> > > > as a lower-overhead alternative to INT.   Do you think this would be
> > > > interesting to integrate into RARE? Apparently there's already an open
> > > > source P4 implementation available, see below.
> > > > Good time synchronization (like via PTP) of the routers/switches is
> > > > required to make this useful.
> > > > I don't usually follow SRv6-related stuff, but there was a nice
> > > > presentation[2] in the archive of the last month's NANOG meeting.
> > > > According to the presentation (and looking at the list of contributors
> > > > to the I-D), this has been implemented on various vendor ASICs (Broadcom
> > > > Jericho2, Cisco Silicon One, Marvell Prestera...), and there's open
> > > > source implementations (Linux, FD.io VPP, P4) and tools
> > > > (Wireshark/tcpdump dissectors)
> > > > Cheers,