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 <[email protected]> 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 <[email protected] > > <mailto:[email protected]>> 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" <[email protected] > > <mailto:[email protected]>> 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 > > > [email protected] <mailto:[email protected]> > > > 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 > > [email protected] <mailto:[email protected]> > > https://www.ietf.org/mailman/listinfo/spring > > <https://www.ietf.org/mailman/listinfo/spring> > > >
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
