Re: [spring] Chair Review of draft-ietf-spring-srv6-srh-compression-11

Thanks, Ron, for showing some of your typical charity and moderation. I have just been catching up on the SPRING list (a lot can happen in one day) and when I got to Antione’s email I was upset enough to start write to the chairs to ask them to bring some better behaviour back to the

Re: [spring] Chair Review of draft-ietf-spring-srv6-srh-compression-11

While different WGs use issue trackers differently, in SPRING we consider the email list the primary source of information.  We use the issue tracker to help us track long term issues.  We also use it when the chairs when to be explixcit about how we understand the issue.  At the current time,

Re: [spring] Chair Review of draft-ietf-spring-srv6-srh-compression-11

The WG LC has not been closed because it is clear that the discussion of issues is ongoing.  Declaring a conclusion seems to this chair to be inappropriate.   The rules are very clear that the time limit when we start a call is a guideline.  Chairs are not free to cut off unresolved

Re: [spring] [EXTERNAL] Re: Chair Review of draft-ietf-spring-srv6-srh-compression-11

Sasha, Are we in violent agreement ? Ron Juniper Business Use Only From: Alexander Vainshtein Sent: Wednesday, March 27, 2024 10:44 AM To: Stewart Bryant ; Andrew Alston - IETF Cc: Tom Herbert ; Ron Bonica ; spring@ietf.org

Re: [spring] [EXTERNAL] Re: Chair Review of draft-ietf-spring-srv6-srh-compression-11

Stewart, Andrew, and all, More of the same, I suspect that the people who call for a new Ethernet for SRv6 are trying to lock the stable door after the horse has been stolen. If you look at RFC 8159 (Standards Track, published 7 years ago long

Re: [spring] Chair Review of draft-ietf-spring-srv6-srh-compression-11

Folks, Previously in this thread, Antoine Fressancourt wrote: " I think everyone here has realized that the current discussion about C-SID is a proxy for some people’s discontent with Segment Routing at large". At first, I took offense to this comment and was not going to grace it with a

Re: [spring] [EXTERNAL] Re: Chair Review of draft-ietf-spring-srv6-srh-compression-11

Alexander, You are assuming that the 6man-sids document and the ethertype document are mutually exclusive, and they aren’t – they are complementary. The 6man-sids document does not negate the argument for an ethertype? What am I missing here? Andrew Internal All Employees From: Alexander

Re: [spring] [EXTERNAL] Re: Chair Review of draft-ietf-spring-srv6-srh-compression-11

Hi! This discussion has now moved beyond the specifics of this document (subject line) and spring's scope. Please move the discussion to a new thread where both spring and 6man are cc'd. Thanks! Alvaro. ___ spring mailing list spring@ietf.org

Re: [spring] [EXTERNAL] Re: Chair Review of draft-ietf-spring-srv6-srh-compression-11

Stewart, The 6man-sid draft is a WG document of the 6MAN that has passed the WG Last Call in this WG and has been submitted by the WG to IESG for approval. The shepherd write-up for this

Re: [spring] Chair Review of draft-ietf-spring-srv6-srh-compression-11

Any router that has interfaces of mixed type has to be able to re-write the datalink header. Changing the Ethertype is a trivial part of changing the Mac header and should therefore be considered a fundamental part of the IETF IP forwarding plane.In reading this discussion I am reminded of very

Re: [spring] Chair Review of draft-ietf-spring-srv6-srh-compression-11

That still does not negate the point – if hardware is capable of stripping the mac address – and ethertype – and pushing such at the LER – I fail to see why you cannot push the mac addresses with a different ethertype. Lets look at this: Packet comes in unlabelled – we strip the mac addresses

Re: [spring] Chair Review of draft-ietf-spring-srv6-srh-compression-11

100% agree with t hat – the checksum issue is another incremental issue – the sids document documents multiple other issues – and I’m far from convinced it’s a complete list of issues. I do agree with that Tom that a draft that documents all the divergence that already exists would be useful –

Re: [spring] Chair Review of draft-ietf-spring-srv6-srh-compression-11

Antoine, The checksum issue is not the first to make us consider whether SRv6 should be forked from IPv6. Nor is it the most significant. Please take a look at draft-ietf-6man-sids. That exercise in equivocation would not have been necessary if SRv6 more clearly conformed to IPv6 standards.

Re: [spring] Chair Review of draft-ietf-spring-srv6-srh-compression-11

Andrew, What you describe in is not an Ethertype re-write IMHO. In your example the entire Layer 2 header (MAC addresses, VLAN tags and the Ethertype that identifies IPv4 or IPv6) are stripped after the packet is identified as an IP packet. When the label stack is pushed onto the packet, a new

Re: [spring] Chair Review of draft-ietf-spring-srv6-srh-compression-11

Tom, I am assuming that we have volunteered each other to write the draft. Does that mean that we will co-author? Ron Juniper Business Use Only From: Tom Herbert Sent: Tuesday, March 26, 2024

Re: [spring] Chair Review of draft-ietf-spring-srv6-srh-compression-11

Errr When unlabelled ipv4 traffic (ethertype 0x0800) gets pushed onto an LSP, the traffic is labelled – and the ethertype is switched to 0x8847 (MPLS). When the MPLS decap occurs – the ethertype is rewritten back to 0x0800. Further more – when pushing VLAN tags – ethertype will move from

Re: [spring] Chair Review of draft-ietf-spring-srv6-srh-compression-11

Andrew, Can you please provide any details about re-write of MPLS Ethertype? Why is it needed, what are the applications etc. I am not aware of any such operations. Regards, Sasha From: Andrew Alston - IETF Sent: Wednesday, March 27, 2024 2:25 PM To: Alexander Vainshtein ; Robert Raszuk

Re: [spring] Chair Review of draft-ietf-spring-srv6-srh-compression-11

Actually there are many reasons – which have been detailed in the ethertype document why various operators believe that this is insufficient. It is still a fail open mechanism. Irrespective of that – I do not believe that 6man-sids contradicts the ravioli draft – in fact I would argue they

Re: [spring] Chair Review of draft-ietf-spring-srv6-srh-compression-11

Andrew, Robert and all, IMHO and FWIW Section 5 of the 6man-sid draft defines a simple security mechanism that can be easily deployed by the operators that have security concerns about SRv6 at the border of their network.

Re: [spring] Chair Review of draft-ietf-spring-srv6-srh-compression-11

Hello, Indeed, I think everyone here has realized that the current discussion about C-SID is a proxy for some people’s discontent with Segment Routing at large, because if the red hearing you see in the proposal is that a middlebox violating both the end to end principle and the layer

Re: [spring] Chair Review of draft-ietf-spring-srv6-srh-compression-11

Last I checked, 1. Issue trackers in Github are not mandatory 2. The slide check presented by the authors at the meeting is significantly newer and far more up to date So – which do you wish us to rely on – what the authors are reporting in their slide deck at a meeting held far more

Re: [spring] Chair Review of draft-ietf-spring-srv6-srh-compression-11

Andrew, In IETF process issues should be opened by those who claim their existence not by the authors of the document. And repo shows 5 closed issues: https://github.com/ietf-wg-spring/draft-ietf-spring-srv6-srh-compression/issues?q=is%3Aissue+is%3Aclosed Maybe authors could keep latest

Re: [spring] Chair Review of draft-ietf-spring-srv6-srh-compression-11

Interesting Robert, That entire repo is entirely empty – was last updated on Feb 11th – and directly conflicts with the slide deck presented at 119 which expressly lists the checksum issue as an open issue. As per

Re: [spring] Chair Review of draft-ietf-spring-srv6-srh-compression-11

Nick, So which part of RFC7282 ? In tracker I see zero open issues: https://github.com/ietf-wg-spring/draft-ietf-spring-srv6-srh-compression/issues All issues have been addressed. So what is the problem ? Thx, R. On Wed, Mar 27, 2024 at 11:43 AM Nick Hilliard wrote: > Robert Raszuk wrote

Re: [spring] Chair Review of draft-ietf-spring-srv6-srh-compression-11

Robert Raszuk wrote on 27/03/2024 10:13: WGLC on this doc started Jan 22nd - Today we have March 27th - was the result of the working group's last call announced and I missed it ? Looking at the list it seems this draft got pretty overwhelming support already. Why are we not progressing ? What

Re: [spring] Chair Review of draft-ietf-spring-srv6-srh-compression-11

Andrew, It is so cool IETF is about rough consensus ... Dear SPRING chairs, WGLC on this doc started Jan 22nd - Today we have March 27th - was the result of the working group's last call announced and I missed it ? Looking at the list it seems this draft got pretty overwhelming support already.

Re: [spring] Chair Review of draft-ietf-spring-srv6-srh-compression-11

No Robert, There are operators that have legitimate security concerns and concerts about layer violations – and those operators are entirely in their rights to have such concerns and act on them accordingly. What this means is that unless those concerns are addressed (with a fail closed

Re: [spring] Chair Review of draft-ietf-spring-srv6-srh-compression-11

Andrew, > because there are operators out there that will never run srv6 So for the operator who will never run SRv6 what exactly is the problem ? How is he going to be affected by any SRv6 extensions ? Isn't such an operator acting like coast guard of selected IPv6 extensions defending its day

Re: [spring] Chair Review of draft-ietf-spring-srv6-srh-compression-11

Except – the objection to the checksum was never really about middleboxes – the middle box issue was merely an example – and has been used as a red hearing – as I clearly stated in subsequent emails, RFC8200 never mentions middleboxes – and nowhere in RFC8200 does it state that checksums can be

Re: [spring] Chair Review of draft-ietf-spring-srv6-srh-compression-11

Hello, I think it is a bit odd that the question that led us to discuss whether SRv6 was an extension of IPv6 or a separate dataplane protocol on the ground of SRv6’s divergence from the IPv6 standard came from a question about whether middleboxes, which addresses are not in the packet’s IPv6

Re: [spring] Chair Review of draft-ietf-spring-srv6-srh-compression-11

Tom, I believe a number of the differences are highlighted in draft-ietf-6man-sids. Though that does not go as far as to say they ipv6 and srv6 are not the same thing – it does highlight that there are key deviations between srv6 and rfc4291 for example. (I hit discuss on this when I was