Hey Tony, Perfect point ... so look at section 3 of IETF STD: https://datatracker.ietf.org/doc/html/rfc8754
With that please kindly indicate in what respect the subject draft does not comply ? Observe that RFC8754 was approved and published after RFC8200 Any more discussions on IETF STD violation ? Cheers, Robert On Tue, Mar 26, 2024 at 6:33 PM Tony Przygienda <tonysi...@gmail.com> wrote: > Robert, please do read the according draft with the explanation of this > being completely optional and freely mixable with "SRv6 is IPv6 kind of" > mode ... > > And let's stick to basic technical sanity and IETF STD documents being > standards that cannot be violated by following documents lest they be not > standards at all rather than calling the usual deities of exigency to > justify any transgression committed or prepared to be committed. There is > no statute of limitations on STD documents or security/operational impact. > Rather, debt incurred in technology tends to accumulate over years > mercilessly. > > --- tony > > On Tue, Mar 26, 2024 at 6:24 PM Robert Raszuk <rob...@raszuk.net> wrote: > >> Ron, >> >> While I did suggest the use of new Ethertype for SRv6 in the very early >> days the killer and valid argument against it was ease of deployment. An >> equally valid argument was built in the extensibility of IPv6 protocol. >> >> So we see the latter is an interesting one, but let's zoom on the former. >> >> In a 1000 node network, if I want to enable SRv6 only on subset of nodes >> (which in many cases is sufficient for a lot of TE purposes) I need to >> upgrade only those affected nodes leaving all other nodes just doing basic >> vanilla IPv6. >> >> If for SRv6 encapsulation new Ethertype is used all 1000 nodes need to be >> upgraded. It will be worse then transition to IPv6 as you will then say - >> Oh Mr. Customer ... do you really need to upgrade your entire network and >> spend millions doing it - just stick to SR-MPLS :) And I know you would >> love to do that. >> >> So I think like others say .. The ship has hit the waters. You have a >> choice to jump on it or stay on the shore. >> >> Cheers, >> Robert >> >> >> On Tue, Mar 26, 2024 at 6:14 PM Ron Bonica <rbon...@juniper.net> wrote: >> >>> Working Group, >>> >>> Might SRv6 progress much more quickly if we did the following: >>> >>> >>> - Divorce SRv6 from IPv6 >>> - Give SRv6 its own ethertype >>> - Let SRv6 progress along its own evolutionary trajectory, >>> unencumbered by IPv6 restrictions >>> >>> >>> At very least, this divorce would end the long and painful debates >>> regarding IPv6 compliance. And would it give SRv6 more degrees of freedom >>> as it evolves, >>> >>> As far as I can see, the only benefit of binding SRv6 to IPv6 is in the >>> expectation that IPv6-enabled hardware won't have to change too much to >>> support SRv6. This benefit might still be realized if SRv6 doesn't deviate >>> too much from IPv6. >>> >>> My question is not rhetorical. Maybe I am missing something, but is >>> there any real benefit in continuing to bind SRRv6 to IPv6? >>> >>> Ron >>> >>> Juniper Business Use Only >>> ------------------------------ >>> *From:* Tom Herbert <t...@herbertland.com> >>> *Sent:* Monday, March 25, 2024 3:40 PM >>> *To:* Alvaro Retana <aretana.i...@gmail.com> >>> *Cc:* Robert Raszuk <rob...@raszuk.net>; Andrew Alston - IETF >>> <andrew-i...@liquid.tech>; Ron Bonica <rbon...@juniper.net>; >>> spring@ietf.org <spring@ietf.org>; Joel Halpern <j...@joelhalpern.com> >>> *Subject:* Re: [spring] Chair Review of >>> draft-ietf-spring-srv6-srh-compression-11 >>> >>> [External Email. Be cautious of content] >>> >>> >>> On Mon, Mar 25, 2024 at 12:31 PM Alvaro Retana <aretana.i...@gmail.com> >>> wrote: >>> > >>> > Tom: >>> > >>> > Hi! >>> > >>> > I understand your point. >>> > >>> > I put the option out there because it came up at last week’s spring >>> meeting and it should be discussed. >>> >>> Alvaro, >>> >>> This seems to come back to the fundamental question: is SRv6 still >>> IPv6 or is it a new protocol. If it's IPv6 then it should adhere to >>> all the requirements and expectations of IPv6, if it's a new protocol >>> that is going to diverge from the standard IPv6 then maybe it needs >>> its own EtherType and standards development path. >>> >>> Tom >>> >>> >>> > >>> > Thanks! >>> > >>> > Alvaro. >>> > >>> > >>> > On March 25, 2024 at 2:58:48 PM, Tom Herbert (t...@herbertland.com) >>> wrote: >>> > >>> > On Mon, Mar 25, 2024 at 11:17 AM Alvaro Retana <aretana.i...@gmail.com> >>> wrote: >>> > > >>> > > FWIW, I agree with most of what Joel wrote. ;-) >>> > > >>> > > I see another path forward: Given that the issue is constrained to >>> an SR domain, the draft could also point out the issues as >>> operational/deployment considerations. Operators can then make an informed >>> decision on whether they want to/can use C-SIDs without an SRH in their >>> network. This path forward (or leaving it out of scope, as Joel suggests >>> below) is something the spring WG can reach consensus on by itself (i.e., >>> without needing to consult or agree with other WGs). >>> > >>> > Alvaro,. >>> > >>> > This wouldn't be robust and would seem to violate the "be conservative >>> > in what you send clause". Punting this to the operators doesn't seem >>> > practical either, in an even moderately large network they wouldn't be >>> > able to know all the potential problems they might hit in devices. >>> > They're about one misconfiguration away from having to debug a rather >>> > unpleasant problem. For instance, if operator gets a packet trace from >>> > a router they would see a whole bunch of packets with bad checksums, >>> > but they would have no way of knowing if these were cases of segment >>> > routing or actually corrupted packets. >>> > >>> > Tom >>> >> _______________________________________________ >> spring mailing list >> spring@ietf.org >> https://www.ietf.org/mailman/listinfo/spring >> >
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
