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

[Tony Przygienda <[e-mail]>]

which has been said many times since the effort started by people who have
been around many architectures in networking space and lived the dreams of
violating/bending standards, shortcutting layers and other "clever"
solutions justified by exigency, limited-use-only or whatever other
figleaves could be conjured while the reality at the end always asserted
itself, either by economics or operational impact.

I for myself  have by now largely given up figuring out _what_ SRv6 is
supposed to be, it's NAT but not NAT, it's a tunnel but not a tunnel, it's
IPv6 but it's not, it's limited domain but not really. As in being limited
domain now it generates BoFs about inter-AS interoperability as was utterly
predictable.

The real, big ticket impact will be security given that it seems to able to
masquerade as IPv6 with suggested properties that will make it
indistinguishable from faulty hardware, possible attacks, whatever ... And
hence needs at minimum a fail-safe trusted domain per default for customers
unless they specifically decide to configure it as open on specific easily
dispatchable property or otherwise feel daring and try to untangle the
implications of it running as IPv6 masquerade. Ether type or
MUST-include-SRH-on-each packet seem architecturally and economically
simplest and safest solutions.

But I guess the argument has been made during last internet area already
and with each of those it-is-it-is-not tortured threads appearing now is
being validated.

-- tony

On Mon, Mar 25, 2024 at 8:40 PM Tom Herbert <tom=
[e-mail]> wrote:

> On Mon, Mar 25, 2024 at 12:31 PM Alvaro Retana <[e-mail]>
> 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 ([e-mail])
> wrote:
> >
> > On Mon, Mar 25, 2024 at 11:17 AM Alvaro Retana <[e-mail]>
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spring
>