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
