Re: [spring] "This solution does not require any SRH data plane change" in draft-filsfilscheng-spring-srv6-srh-compression-02

Hi John,
thank you for equipping your question with the definition of the data
plane. That helps a lot. I agree with Gyan that as the local function
processing the SID encoding in an SRH container must change, so the only
conclusion we can make is that the data plane that supports C-SID is
different from the one that only supports RFC 8754.

Regards,
Greg

On Wed, Oct 13, 2021 at 3:29 PM John Scudder <jgs=
40juniper.net@dmarc.ietf.org> wrote:

> Hi Folks,
>
> I’m struggling with the claim repeated throughout the beginning of
> draft-filsfilscheng-spring-srv6-srh-compression-02 (Abstract, §1, §3) that
> “this solution does not require any SRH data plane change”.
>
> I’m not aware of a standardized formal definition of “data plane”, it
> seems to follow Justice Stewart’s maxim of “I know it when I see it”.
> However, here’s an attempt, cribbed from some Washington University course
> slides: a “local, per-router function that determines how a datagram
> arriving on a router input port is forwarded to a router output port”.
> Seems reasonable.
>
> I also am not aware of a standardized formal definition of the term “SRH
> data plane”, in fact this draft, its predecessors, some associated blog
> posts, and Clarence’s dissertation, are the only places a search finds the
> phrase (but it’s not formally defined in any of them). So I’m just going to
> assume it means the data plane, as applied to packets that include an SRH.
> (I’m not sure why we should disregard packets that are encoded using
> NEXT-C-SID that omit the SRH, but let’s overlook that for now.)
>
> If this solution does not require any SRH data plane change, presumably it
> would be true that if I take a packet that includes an SRH and place within
> it a series of SIDs encoded with (for example) the REPLACE-C-SID flavor,
> then that packet would be able to successfully traverse a network of
> routers that support plain vanilla RFC 8754. That is, it would arrive at
> its first hop router which according to a local, per-router function, would
> determine how to take the datagram arriving on the router input port and
> forward it to (the correct) router output port. Then that process would be
> repeated across the rest of the network.
>
> But that is patently incorrect: when it’s delivered to the first hop, the
> plain vanilla RFC 8754 router will be unable to apply the REPLACE-C-SID
> behavior, and forwarding to the next hop will fail. It seems that a
> different local, per-router function is required (in fact, the local,
> per-router function defined in the draft) in order for the forwarding to
> succeed. By the definitions I’m using here, that is exactly a data plane
> change.
>
> What, precisely, is then being claimed?
>
> Thanks,
>
> —John
> _______________________________________________
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
>