Robert,
Please read the Metric for this requirement:
* Metric: The utilization metric (U) records whether a proposal utilizes
the SRv6 specifications.
*
A proposal can use 8404, 8986, etc and still change the SRv6 data plane.
Ron
Juniper Business Use Only
From: Robert Raszuk <[email protected]>
Sent: Tuesday, October 26, 2021 4:10 PM
To: Ron Bonica <[email protected]>
Cc: John Scudder <[email protected]>;
[email protected]; [email protected]
Subject: Re: [spring] "This solution does not require any SRH data plane
change" in draft-filsfilscheng-spring-srv6-srh-compression-02
[External Email. Be cautious of content]
4. SRv6 Specific Requirements
4.1. SRv6 Based
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.
It is clearly a requirement. It is not an exclusive requirement, but that does
not make it of any less importance as evaluation criteria. Analysis draft
provides comparison table in section 3.1
But please let's not derail this thread as I provided a specific question to
John.
On Tue, Oct 26, 2021 at 10:01 PM Ron Bonica
<[email protected]<mailto:[email protected]>> wrote:
Many thx,
R.
Robert,
Which requirement was that?
Ron
Juniper Business Use Only
From: spring <[email protected]<mailto:[email protected]>> On
Behalf Of Robert Raszuk
Sent: Tuesday, October 26, 2021 3:41 PM
To: John Scudder <[email protected]<mailto:[email protected]>>
Cc:
[email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>
Subject: Re: [spring] "This solution does not require any SRH data plane
change" in draft-filsfilscheng-spring-srv6-srh-compression-02
[External Email. Be cautious of content]
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://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-srcompdt-spring-compression-requirement__;!!NEt6yMaO-gk!W8DcKe4AgQyCCvA2v_GW3_9ZaJ_RJ2Ll6-kbhylSgO0YHbi3AQVZRHMPrQcnZRJk$>
https://datatracker.ietf.org/doc/html/draft-srcompdt-spring-compression-analysis<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-srcompdt-spring-compression-analysis__;!!NEt6yMaO-gk!W8DcKe4AgQyCCvA2v_GW3_9ZaJ_RJ2Ll6-kbhylSgO0YHbi3AQVZRHMPrft1hBsN$>
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]<mailto:[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
> <[email protected]<mailto:[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]<mailto:[email protected]>
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!S7rbnYg6aV2s3cyoTCL3wwWX4bpbFoawPLt6yLeYsms82sLl9tUpRU1X5c-D9A$<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
