Hi Robert, > On Oct 26, 2021, at 5:30 PM, Robert Raszuk <rob...@raszuk.net> wrote: > > Hi John, > > Many thx for your detailed clarification.
You are welcome. > > CRH is not strictly based on SRv6 but is able to provide equivalent > > functionality. > > Now it is pretty obvious that all of those endless discussions are about > C-SID vs CRH. I wouldn’t say the topic I raised was “endless” [*], and it has nothing whatsoever to do with CRH, it relates solely to the document in question. If you have some specific reason to say otherwise, that involves things I wrote [**], please do share. > It does sound like LDP vs CR-LDP many years ago :) > > However the topic is IMO orthogonal to > draft-filsfilscheng-spring-srv6-srh-compression and the discussion should > return on the correct tracks of either revisiting single vs many data plane > solutions or question the results from design team analysis draft. I’m not making any attempt to derail such discussions; however, it’s still the case that the topic I raised hasn’t been closed and I would equally appreciate it if you’d refrain from trying to derail this line of discussion with distractions like bringing up CRH. Regards, —John [*] I count fifteen messages not including this one. [**] Obviously, beyond the fact that I quoted a paragraph from a document you cited, that included the letters C, R, and H. > > Many thx, > R. > > > On Tue, Oct 26, 2021 at 11:21 PM John Scudder <j...@juniper.net> wrote: > Hi Robert, > > > On Oct 26, 2021, at 3:41 PM, Robert Raszuk <rob...@raszuk.net> wrote: > > > > Hello John, > > > > May I inquire what was not definitive as part of my answer ? > > I answered that in my response to your earlier message: > https://mailarchive.ietf.org/arch/msg/spring/dtKC6Um6USs0Jf7-LssRVsZzwTw/ > > > 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 > > This one says (§4.1) > > Description: A solution to compress SRv6 SID Lists SHOULD be based on > the SRv6 architecture, control plane and data plane. The compression > solution MAY be based on a different data plane and control plane, > provided that it derives sufficient benefit. > > “Based on” is different from “does not change”. I don’t see any documentation > or claim of the latter. > > > https://datatracker.ietf.org/doc/html/draft-srcompdt-spring-compression-analysis > > Similarly (§3.1) > > A solution to compress SRv6 SID Lists SHOULD be based on the SRv6 > architecture, control plane and data plane. The compression solution > MAY be based on a different data plane and control plane, provided > that it derives sufficient benefit. > … > Conclusion: CSID is SRv6 based, requiring no updates to existing SRv6 > standards, VSID and UIDSR require updates. CRH is not strictly based > on SRv6 but is able to provide equivalent functionality. > > That does make the stronger claim “no updates to existing SRv6 standards”. > It’s still the case that this is not the same as saying it doesn’t change the > data plane, however, for the reasons I gave previously. > > > Would your enquiry be satisfied if the draft in question s/SRH data > > plane/SRv6 data plane/ ? > > Using the more commonly-used term would be a good start. I think if the only > change were that, though, it would still be problematic, for example the > revised abstract would say “This solution does not require any SRv6 data > plane change”. AFAICT, that still fails the test I proposed in my initial > note. > > Regards, > > —John > > > > > > > > > Kind regards, > > > > Robert > > > > > > > > > > > > > > On Tue, Oct 26, 2021 at 7:55 PM John Scudder <j...@juniper.net> 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=40juniper....@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://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!S7rbnYg6aV2s3cyoTCL3wwWX4bpbFoawPLt6yLeYsms82sLl9tUpRU1X5c-D9A$ > > > _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
