RARE user and assistance email list

[Tim Chown <>]

Hi,

On the extension headers, it’s been a thorny subject in the IETF for a while. 
 I did some experiments with Fernando Goat and wrote this - 
https://www.rfc-editor.org/rfc/rfc7872.html - which one vendor didn’t like 
(no names, but the vendor was building solutions with EHs :) so the text had 
to be somewhat watered down.

There is since https://www.rfc-editor.org/rfc/rfc9098.html - Operational 
Implications of IPv6 Packets with Extension Headers.

Ultimately, traffic that requires EHs to pass should be within a single 
domain, which I suspect much of the SRv6 use cases would be, but not 
therefore ideal for (for example) inter-domain INT-a-like implementations 
with EHs.

Tim

> On 21 Aug 2022, at 14:02, mc36 <> wrote:
> 
> 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,
>>>