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

[Robert Raszuk <[e-mail]>]

Ok Joel - final question from me on this.

Do you believe that **SRv6 data plane** exists or it does not exist and all
we are dealing with is **IPv6** data plane** with some SRv6 extensions made
to it ? Notice that the SPRING WG charter clearly talks about SRv6 data
plane(s).

I think this is fundamental and not only for C-SID draft, but for any other
future SPRING WG document to be produced.

Thx,
R.







On Fri, Nov 5, 2021 at 8:01 PM Joel M. Halpern <[e-mail]> wrote:

> Robert, as far as I can tell, no one other than you believes that "SRv6
> should not be positioned as extension of IPv6 data plane."  The SRH was
> approved by 6man, whose only remit is the IPv6 data plane.   Many
> descriptions of SRv6 describe it as providing segment routing to IPv6.
>   And all SRv6 packets when carried on Ethernet use the IPv6 Ethertype.
>
> By any measure I can see, SRv6 is part of IPv6.  Just as SR-MPLS is part
> of MPLS.  It is relevant that SRv6 in my understanding changes the
> forwarding behavior of IPv6, and C-SID changes it significantly more.
> But that doe snot mean it is not an extension of IPv6.
>
> More importantly in terms of the adoption call, the issue of the
> relationship between C-SIDs and RFC 4291 was raised in such a way that I
> concluded that even if I did not agree with the issue I would have to
> recognize that it needed to be addressed.
>
> Yours,
> Joel
>
> On 11/5/2021 2:46 PM, Robert Raszuk wrote:
> > Dear Joel,
> >
> > It is clear that your personal view of the relevance of SID ARG content
> > to IPv6 address differs from the view of many WG participants.
> >
> > To be very clear - whatever SPRING WG decides to put into SID ARG field
> > it is completely orthogonal to IPv6 community as it has completely
> > nothing to do with IPv6 addressing architecture. That is based on
> > approved RFC 8986.
> >
> > We can call it c-sid, sid++, sid/4, rainbow and I am sure the list will
> > grow with time. The entire concept of SRv6 NP is that the data plane
> > will also need to be programmable. And yes at segment endpoints to
> > properly process SRv6 packets plain IPv6 data plane support is not
> > sufficient. SRv6 data plane must be in place.
> >
> > I think looking from the beginning of this discussions to me it is
> > obvious that SRv6 should not be positioned as extension of IPv6 data
> > plane. To me this is new data plane however made in a
> > backwards compatible way with IPv6 for the transit nodes.
> >
> > Kind regards,
> > Robert
> >
> >
> > On Fri, Nov 5, 2021 at 6:39 PM Joel M. Halpern <[e-mail]
> > <mailto:[e-mail]>> wrote:
> >
> >     Darren, while I appreciate your requests, I must decline both
> requests.
> >
> >     On he first request, the bullet is derived from the stated SPRING
> >     chairs
> >     policy, as was announced to the working group and is cited in the
> >     adoption conclusion.  It is not reliant on the charter item, the
> >     question I asked 6man about the charter item, nor the answer that
> 6man
> >     provided.
> >
> >     On the second, the issue for holding up posting of the adopted
> document
> >     (and potentially holding up last call on the document, assuming as I
> do
> >     that we will get that far), is about this document.  Which is about
> >     C-SIDs.  If 6man chooses to address the larger SID question in their
> >     document, that is their call.  Our dependence is on the C-SID part of
> >     that.  I have been told C-SID will be dealt with in that.  In the
> >     unlikely event that no document dealing with the relationship of
> C-SIDs
> >     to RFC 4291 appears, then we will work out how to get one, as that is
> >     what we need to advance work on this compression document.
> >
> >     Yours,
> >     Joel
> >
> >     On 11/5/2021 10:17 AM, Darren Dukes (ddukes) wrote:
> >      > Hello Joel,
> >      >
> >      > I want to make note of two suggestions, I’m copying the list for
> >     record
> >      > keeping only.
> >      >
> >      > 1 – The second bullet (beginning with “As reminded”) should
> >     include the
> >      > link to the questions asked of the 6man chairs/ADs
> >      >
> >
> https://mailarchive.ietf.org/arch/msg/ipv6/merG-RgtA3shloDqpyRk-xWHniw/
> >     <
> https://mailarchive.ietf.org/arch/msg/ipv6/merG-RgtA3shloDqpyRk-xWHniw/>
> >
> >      >
> >     <
> https://mailarchive.ietf.org/arch/msg/ipv6/merG-RgtA3shloDqpyRk-xWHniw/
> >     <
> https://mailarchive.ietf.org/arch/msg/ipv6/merG-RgtA3shloDqpyRk-xWHniw/>>
> >     and
> >      > their response
> >      >
> >
> https://mailarchive.ietf.org/arch/msg/spring/z_3nbdwVQ_V66ZqkV-ZhIg7kakA/
> >     <
> https://mailarchive.ietf.org/arch/msg/spring/z_3nbdwVQ_V66ZqkV-ZhIg7kakA/>
> >     <
> https://mailarchive.ietf.org/arch/msg/ipv6/3k8_1JgKGtnLsfsVf65qvReNuLc/
> >     <
> https://mailarchive.ietf.org/arch/msg/ipv6/3k8_1JgKGtnLsfsVf65qvReNuLc/>>
> >      >
> >      > 2 – About the requirements for a document identifying the
> >     “relationship
> >      > of C-SIDs with RFC 4291.”.  The word “C-SIDs” should be changed
> >     to “SRv6
> >      > SIDs” in the sentences when such a document is discussed.  This
> >     would
> >      > better match the 6man chairs/ADs response:
> >      >
> >      > “To summarize: we do not object to C-SID behavior work continuing
> in
> >      > SPRING, we simply need a clarifying document described in [A].”
> >      >
> >      > And
> >      >
> >      > “[A] A separate 6MAN document to clarify and categorize SRv6 SIDs
> is
> >      > needed.”
> >      >
> >      > Thanks
> >      >
> >      > Darren
> >      >
> >      > On 2021-10-31, 11:37 AM, "spring" <[e-mail]
> >     <mailto:[e-mail]>> wrote:
> >      >
> >      >
> >      >
> >      > 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/
> >     <
> https://mailarchive.ietf.org/arch/msg/spring/-tvDZ5biRXvfLlyJ8IMtX-7EUp4/
> ><
> https://mailarchive.ietf.org/arch/msg/spring/-tvDZ5biRXvfLlyJ8IMtX-7EUp4/
> >     <
> 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/
> >     <
> https://mailarchive.ietf.org/arch/msg/spring/vCc9Ckvwu5HA-RCleV712dsA5OA/
> ><
> https://mailarchive.ietf.org/arch/msg/spring/vCc9Ckvwu5HA-RCleV712dsA5OA/
> >     <
> 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/
> >     <
> https://mailarchive.ietf.org/arch/msg/spring/vCc9Ckvwu5HA-RCleV712dsA5OA/
> ><
> https://mailarchive.ietf.org/arch/msg/spring/vCc9Ckvwu5HA-RCleV712dsA5OA/
> >     <
> 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.
> >      >
> >      > _______________________________________________
> >      > spring mailing list
> >      > [e-mail] <mailto:[e-mail]>
> >      > https://www.ietf.org/mailman/listinfo/spring
> >     <https://www.ietf.org/mailman/listinfo/spring><
> https://www.ietf.org/mailman/listinfo/spring
> >     <https://www.ietf.org/mailman/listinfo/spring>>
> >      >
> >
> >     _______________________________________________
> >     spring mailing list
> >     [e-mail] <mailto:[e-mail]>
> >     https://www.ietf.org/mailman/listinfo/spring
> >     <https://www.ietf.org/mailman/listinfo/spring>
> >
>