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

[John Scudder <[e-mail]>]

Hi Robert,

> On Oct 26, 2021, at 5:30 PM, Robert Raszuk <[e-mail]> 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 <[e-mail]> wrote:
> Hi Robert,
> 
> > On Oct 26, 2021, at 3:41 PM, Robert Raszuk <[e-mail]> 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 <[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$
> > 
>