RARE user and assistance email list

[Tim Chown <>]

Ah yes, that is a good and (very!) recent RFC on the filtering topic.

The point is that EHs can certainly work inter-domain, but when you’re in 
your own network you’re of course in full control of what is and isn’t 
filtered.

Tim

> On 22 Aug 2022, at 12:21, mc36 <> wrote:
> 
> my bad, this one: https://www.rfc-editor.org/info/rfc9288
> 
> On 8/22/22 13:18, mc36 wrote:
>> hi,
>> that's it, thanks for the clarification and precise with the rfc 
>> numbers.... :)
>> regarding the inter-domain use cases, i disagree, it's not a discretion of 
>> an as long as they provide
>> inter-as vpns like mdvpn or any other big telco communities like the dt 
>> family of telcos...
>> br,
>> cs
>> On 8/22/22 11:16,  wrote:
>>> 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,
>>>>>> 
>>> 
>>> 
>>> 
>>> -=-=-=-=-=-=-=-=-=-=-=-
>>> Groups.io Links: You receive all messages sent to this group.
>>> View/Reply Online (#521): https://groups.io/g/freertr/message/521
>>> Mute This Topic: https://groups.io/mt/93160875/6006518
>>> Group Owner: 
>>> Unsubscribe: https://groups.io/g/freertr/unsub []
>>> -=-=-=-=-=-=-=-=-=-=-=-
>>> 
>>>