Subject: [spring] Conclusion of Adoption call for draft-filsfilscheng-spring-srv6-srh-compression

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 31 Oct 2021 11:36:22 -0400

With apologies to the working group for the delay, this email formally 
ends the adoption call that was announced at
https://mailarchive.ietf.org/arch/msg/spring/-tvDZ5biRXvfLlyJ8IMtX-7EUp4/
for draft-filsfilscheng-spring-srv6-srh-compression

The conclusion is somewhat unusual, so please read carefully.

First, let me thank all of the working group participants for their 
active and energetic participation in this call.  That is what we need.

In terms of the rough consensus of the feedback we received, the rough 
consensus of the working group is that we should adopt this document.
Due to process concerns, I am placing two caveats on this adoption, one 
of which can be easily dealt with by the authors, and one of which will 
cause some delay.

The SPRING working group chairs sent a policy statement last March
https://mailarchive.ietf.org/arch/msg/spring/vCc9Ckvwu5HA-RCleV712dsA5OA/
which calls attention to the issue of conflict between working group 
efforts and existing PS or BCP RFCs.  This policy applies to the subject 
document.  It is my judgment that the issues raised regarding whether 
this work complies with RFC 4291 require adherence to this policy.
As such, we need a draft in front of 6man (the responsible working group 
for RFC 4291) that addresses the raised disconnect.
fortunately, we have been told that the 6man chairs and area directors 
are appointing authors for just such a document to address the issue of 
the relationship of C-SIDs with RFC 4291.
Therefore, I will not be approving posting of the working group draft 
until the author team has posted an initial take for 6man consumption of 
such a draft. Once they have posted that draft, I will approve posting 
of a working group ID with the addition according to the next caveat.

As per the statement in the adoption call, as part of adoption the 
document is required to have a section (an appendix seems the most 
appropriate, but placement will be up to the editors) on open issues. As 
there is a lot of controversy about the open issues, and about how to 
describe them, I am providing text (below) for that section.   Once the 
draft is posted as a working group draft, the working group will of 
course own the text, and WG rough consensus can change the text.  Also, 
once we have a WG draft I will arrange to get an issue tracker to make 
sure we keep track of all the issues, not just the major ones in the 
open issues section of the document.

Expected text on Open Issues:

Open Issues:

Issues raised during and after the adoption call for this draft are 
tracked in an issue tracker. The remainder of this section identifies 
the most significant open issues, from the adoption call, for the 
working group to keep track of.

As a reminder to those reading this section, this document is a work in 
progress, and subject to change by the working group.  As noted at the 
front of this document, "It is inappropriate to use Internet-Drafts as 
reference material"

o Given that the working group has said that it wants to standardize one
data plane solution, and given that the document contains multiple SRv6
EndPoint behaviors that some WG members have stated are multiple data
plane solutions, the working group will address whether this is valid
and coherent with its one data plane solution objective.

o As reminded in the conclusion of the adoption call, this document is 
subject to the policy announced by the SPRING chairs in 
https://mailarchive.ietf.org/arch/msg/spring/vCc9Ckvwu5HA-RCleV712dsA5OA/.
In particular, this means that this document can not go to WG last call 
until 6man completes handling of an Internet Draft that deals with the 
relationship of C-SIDs to RFC 4291.  It is hoped and expected that said 
resolution will be a WG last call and document approval in 6man of a 
document providing for the way that C-SIDs use the IPv6 destination 
address field.

---

From: Robert Raszuk <[email-masked]>
Date: Sun, 31 Oct 2021 19:19:19 +0100

Dear Joel,

If I may, I would like to pose a clarification question in respect to the
below announcement.

*What makes RFC8986 compliant with RFC4291 which
draft-filsfilscheng-spring-srv6-srh-compression violaties ? *

Please kindly note that RFC8986 defines in sec 3.1 SID as LOC:FUNCT:ARG

The only recommendation it makes for ARG is following:

*   In such a case, the semantics and format of the ARG bits are defined
 as part of the SRv6 Endpoint behavior specification.   The ARG value of a
routed SID SHOULD remain constant among packets in   a given flow.  Varying
ARG values among packets in a flow may result   in different ECMP hashing
and cause reordering.*

On the other hand please kindly observe that
draft-filsfilscheng-spring-srv6-srh-compression provides set of semantics
for ARG part of SID.

*So that means that it entirely builds on prior art of RFC 8986. *

That specific RFC went via many discussions and even appeal and was
considered compliant with IETF prior documents. Now is this your judgement
that the IETF process which led to standardization of SRv6 Network
Programming was all fake and you can simply dismiss it ?

The answer to this question is important as vendors and operators are
investing in the technology especially when it comes out of IETF as
Standards Track formal RFC.

Kind regards,
Robert Raszuk

PS.

I think you have perhaps accidently violated the IETF process. And not in
regards to compression draft. But in respect to effectively asking 6man if
RFC8986 is compliant to RFC4291 or not after it has been issued and
approved.

Because if it is draft-filsfilscheng-spring-srv6-srh-compression is
automatically compliant.

On Sun, Oct 31, 2021 at 4:36 PM Joel M. Halpern <[email-masked]> wrote:

> _______________________________________________
> spring mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spring
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 31 Oct 2021 14:27:23 -0400

I am not attempting to revisit the question of whether RFC 8986 complies 
with RFC 4191.
This compression documents raises additional issues beyond those in 8986 
in some aspects of the flavors it describes.

Yours,
Joel

On 10/31/2021 2:19 PM, Robert Raszuk wrote:
> Dear Joel,
> 
> If I may, I would like to pose a clarification question in respect to 
> the below announcement.
> 
> /   In such a case, the semantics and format of the ARG bits are defined
>     as part of the SRv6 Endpoint behavior specification.
> 
>     The ARG value of a routed SID SHOULD remain constant among packets in
>     a given flow.  Varying ARG values among packets in a flow may result
>     in different ECMP hashing and cause reordering.
> /
> 
> draft-filsfilscheng-spring-srv6-srh-compression provides set of 
> semantics for ARG part of SID.
> 
> _So that means that it entirely builds on prior art of RFC 8986. _
> 
> considered compliant with IETF prior documents. Now is this your 
> judgement that the IETF process which led to standardization of SRv6 
> Network Programming was all fake and you can simply dismiss it ?
> 
> I think you have perhaps accidently violated the IETF process. And not 
> in regards to compression draft. But in respect to effectively asking 
> 6man if RFC8986 is compliant to RFC4291 or not after it has been issued 
> and approved.
> 
> On Sun, Oct 31, 2021 at 4:36 PM Joel M. Halpern <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     <https://mailarchive.ietf.org/arch/msg/spring/-tvDZ5biRXvfLlyJ8IMtX-7EUp4/>
>     <https://mailarchive.ietf.org/arch/msg/spring/vCc9Ckvwu5HA-RCleV712dsA5OA/>
>     <https://mailarchive.ietf.org/arch/msg/spring/vCc9Ckvwu5HA-RCleV712dsA5OA/>.
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/spring>
>

---

From: Robert Raszuk <[email-masked]>
Date: Sun, 31 Oct 2021 19:31:31 +0100

> in some aspects of the flavors it describes.

Could you be so kind and enumerate where in the draft you see *anything*
crossing the line by defining new semantics for the ARG part of the SID as
defined in RFC8986 ?

Hint: your argument could have been sustainable if RFC8986 would put
additional restrictions on the ARG field. But it does not.

Many thx,
Robert

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 31 Oct 2021 14:47:20 -0400

From my perspective the discussions as part of the adoption call in 
SPRING, and the discussions in 6man make it clear that there is an issue 
to be resolved.  It may be that the issue will be resolved in saying 
there is nothing that needs to be specified.  It may be resolved by 
saying that there are differences, and that they are acceptable.  There 
are many other ways that it may be resolved.

It is my job as chair, given the policy, to determine that there is an 
apparent discrepancy that needs to be addressed.  I have done so.

Yours,
Joel

On 10/31/2021 2:31 PM, Robert Raszuk wrote:
> crossing the line by defining new semantics for the ARG part of the SID 
> as defined in RFC8986 ?
>

---

From: Robert Raszuk <[email-masked]>
Date: Sun, 31 Oct 2021 20:04:19 +0100

Yes, the discussions in both SPRING and 6man prove that there is a group of
folks who either do not like and do not accept the existence of RFC 8986 or
simply do not fully understand what it contains.

I do not think that as such it is sufficient not to accept the document as
a WG draft observing the amount of industry support for it as expressed on
the list.

At min as requested a solid list of technical issues should have been
provided where text in the draft goes above to what is already written in
RFC8986.

Kind regards,
Robert.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 31 Oct 2021 15:10:43 -0400

You are of course welcome to your view.  My understanding of what I am 
required to do does not match yours.

Yours,
Joel

On 10/31/2021 3:04 PM, Robert Raszuk wrote:
> 
> Yes, the discussions in both SPRING and 6man prove that there is a group 
> of folks who either do not like and do not accept the existence of RFC 
> 8986 or simply do not fully understand what it contains.
> 
> I do not think that as such it is sufficient not to accept the document 
> as a WG draft observing the amount of industry support for it as 
> expressed on the list.
> 
> provided where text in the draft goes above to what is already written 
> in RFC8986.
> 
> Kind regards,
> Robert.
> 
> On Sun, Oct 31, 2021 at 7:47 PM Joel M. Halpern <[email-masked] 
>      >     This compression documents raises additional issues beyond
>     those in
>      >     8986