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 <[email protected]> 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= > [email protected]> 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 > > [email protected] > > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!S7rbnYg6aV2s3cyoTCL3wwWX4bpbFoawPLt6yLeYsms82sLl9tUpRU1X5c-D9A$ > >
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
