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

[Robert Raszuk <[e-mail]>]

Hello John,

May I inquire what was not definitive as part of my answer ?

Please observe that below documents which are product of this WG go in
depth to evaluate compression against the requirement not to change SRv6
data plane:

https://datatracker.ietf.org/doc/html/draft-srcompdt-spring-compression
-requirement

https://datatracker.ietf.org/doc/html/draft-srcompdt-spring-compression
-analysis


Would your enquiry be satisfied if the draft in question s/SRH data
plane/SRv6 data plane/ ?


Kind regards,

Robert




On Tue, Oct 26, 2021 at 7:55 PM John Scudder <[e-mail]> wrote:

> (For clarity: I’m not wearing any hats other than “WG contributor”.)
>
> Hi All,
>
> Since there hasn’t been any definitive answer from the authors, nor any
> update to the draft to address the issue, and given that the disputed
> statement seems to be an important premise for evaluation of the fitness of
> the draft for adoption (at least, the authors considered it fundamental
> enough to put in the abstract): I’m opposed to adoption of the draft until
> this question has been settled, or at least meaningfully addressed.
>
> Regards,
>
> —John
>
> P.S.: I will also follow up to the main adoption thread to assist with
> issue tracking.
>
> > On Oct 13, 2021, at 6:28 PM, John Scudder <jgs=
> [e-mail]> 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
> > [e-mail]
> >
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!S7rbnYg6aV2s3cyoTCL3wwWX4bpbFoawPLt6yLeYsms82sLl9tUpRU1X5c-D9A$
>
>