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]
<mailto:[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]>
> <mailto:[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/>>
>
> >
>
<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/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/>
>
<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]>
> <mailto:[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/>><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/>><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/>><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]>
<mailto:[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>><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]> <mailto:[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>>
>
