there are +/- here 1) SRH will be notably more expensive to filter than dispatching ethertype in HW unless it can be guaranteed to be present at a fixed offset 2) ether type is completely optional and will interop easily with "pseudo-IPv6" per raviolli draft and is trivial to implement in HW on all silicon architectures I talked to 3) both are relatively hard to spoof out the server, 1) probably bit harder 4) forcing SRH is probably bits easier to implement for an overlay since ether type will need L2 capable tunneling. On the other hand, in overlay cases we talk mostly about a truly limited domain AFAIS so it may be not even particularly important to be able to differentiate v6 from srv6
will either work for security purposes/keeping clean STD, AFAIS yes, I would clearly lean towards 2) being more traditional/efficient/architecturally cleaner but 1) will provide reasonable fail-safe domain by default as well --- tony On Tue, Mar 26, 2024 at 6:32 PM Tom Herbert <tom= 40herbertland....@dmarc.ietf.org> wrote: > On Tue, Mar 26, 2024 at 10:14 AM 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, > > Giving SRV6 its own Ethertype might free it from "restrictions" of > IPv6 (in quotes because some of the restrictions are about eliciting a > robust protocol), but on the other hand a new Ethertype would be a > major undertaking to develop and deploy that might prove to be > infeasible. I believe the best answer is to always require an SRH, and > otherwise maintain compliance with IPv6 standard. > > Tom > > > > > 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
