Subject: [spring] Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

From: Lizhenbin <[email-masked]>
Date: Wed, 26 Feb 2020 11:54:33 +0000

Hi Bruno and WG,
The LC has lasted for almost 3 months which greatly exceeds the expected 2 week. In the process all the comments have been resolved while some issues is raised again and again with little value.
On the other hand, there have been multiple commercial implementation and inter-op test and almost 20 deployments for SRv6 which justify the solution proposed by the draft in practice.

We sincerely request to close the LC of the draft and move forward.

Best Regards,
Zhenbin (Robin)

From: [email-masked] [mailto:[email-masked]]
Sent: Friday, December 06, 2019 1:15 AM
To: 'SPRING WG List' <[email-masked]>
Cc: [email-masked]; draft-ietf-spring-srv6-network-programming <[email-masked]>
Subject: WGLC - draft-ietf-spring-srv6-network-programming

Hello SPRING,

This email starts a two weeks Working Group Last Call on draft-ietf-spring-srv6-network-programming [1].

Please read this document if you haven't read the most recent version, and send your comments to the SPRING WG list, no later than December 20.

You may copy the 6MAN WG for IPv6 related comment, but consider not duplicating emails on the 6MAN mailing list for the comments which are only spring specifics.

If you are raising a point which you expect will be specifically debated on the mailing list, consider using a specific email/thread for this point.

This may help avoiding that the thread become specific to this point and that other points get forgotten (or that the thread get converted into parallel independent discussions)

Thank you,

Bruno

[1] https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-05

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.

Thank you.

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Wed, 26 Feb 2020 12:01:57 +0000

+1

Best regards,
Jie

From: spring [mailto:[email-masked]] On Behalf Of Lizhenbin
Sent: Wednesday, February 26, 2020 7:55 PM
To: [email-masked]; 'SPRING WG List' <[email-masked]>
Cc: [email-masked]; draft-ietf-spring-srv6-network-programming <[email-masked]>
Subject: [spring] Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

Hi Bruno and WG,

Best Regards,
Zhenbin (Robin)

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Friday, December 06, 2019 1:15 AM
To: 'SPRING WG List' <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; draft-ietf-spring-srv6-network-programming <[email-masked]<mailto:[email-masked]>>
Subject: WGLC - draft-ietf-spring-srv6-network-programming

Hello SPRING,

Thank you,

Bruno

Thank you.

---

From: Huzhibo <[email-masked]>
Date: Wed, 26 Feb 2020 12:06:00 +0000

+1

Thanks
Zhibo

Hi Bruno and WG,

Best Regards,
Zhenbin (Robin)

Hello SPRING,

Thank you,

Bruno

Thank you.

---

From: "[email-masked]" <[email-masked]>
Date: Wed, 26 Feb 2020 20:13:06 +0800

+1，I support the proposal to close the Last call of this draft.

Best regards
Chongfeng

From: Lizhenbin
Date: 2020-02-26 19:54
To: [email-masked]; 'SPRING WG List'
CC: [email-masked]; draft-ietf-spring-srv6-network-programming
Subject: [spring] Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming
Hi Bruno and WG,
The LC has lasted for almost 3 months which greatly exceeds the expected 2 week. In the process all the comments have been resolved while some issues is raised again and again with little value. 
On the other hand, there have been multiple commercial implementation and inter-op test and almost 20 deployments for SRv6 which justify the solution proposed by the draft in practice. 

 
Best Regards,
Zhenbin (Robin)

Hello SPRING, This email starts a two weeks Working Group Last Call on draft-ietf-spring-srv6-network-programming [1]. Please read this document if you haven't read the most recent version, and send your comments to the SPRING WG list, no later than December 20. You may copy the 6MAN WG for IPv6 related comment, but consider not duplicating emails on the 6MAN mailing list for the comments which are only spring specifics. If you are raising a point which you expect will be specifically debated on the mailing list, consider using a specific email/thread for this point.This may help avoiding that the thread become specific to this point and that other points get forgotten (or that the thread get converted into parallel independent discussions) Thank you,Bruno [1] https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-05 
 
_________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent doncpas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signalera l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law;they should not be distributed, used or copied without authorisation.If you have received this email in error, please notify the sender and delete this message and its attachments.As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.Thank you.

---

From: "Gengxuesong (Geng Xuesong)" <[email-masked]>
Date: Wed, 26 Feb 2020 12:18:34 +0000

+1

Best Regards
Xuesong

Hi Bruno and WG,

Best Regards,
Zhenbin (Robin)

Hello SPRING,

Thank you,

Bruno

Thank you.

---

From: "Chengli (Cheng Li)" <[email-masked]>
Date: Wed, 26 Feb 2020 12:22:35 +0000

+1

Cheng

From: ipv6 [mailto:[email-masked]] On Behalf Of Gengxuesong (Geng Xuesong)
Sent: Wednesday, February 26, 2020 8:19 PM
To: Lizhenbin <[email-masked]>; [email-masked]; 'SPRING WG List' <[email-masked]>
Cc: [email-masked]; draft-ietf-spring-srv6-network-programming <[email-masked]>
Subject: RE: Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

+1

Best Regards
Xuesong
To: [email-masked]<mailto:[email-masked]>; 'SPRING WG List' <[email-masked]<mailto:[email-masked]>>

Hi Bruno and WG,

Best Regards,
Zhenbin (Robin)

Hello SPRING,

Thank you,

Bruno

Thank you.

---

From: "dzp" <[email-masked]>
Date: Wed, 26 Feb 2020 20:31:35 +0800

+1

&nbsp;

&nbsp;

Best Regards

Zongpeng Du (cmcc)

------------------&nbsp;Original&nbsp;------------------
From:&nbsp;"Chengli (Cheng Li)"<[email-masked]&gt;;
Date:&nbsp;Wed, Feb 26, 2020 08:22 PM
To:&nbsp;"'SPRING WG List'"<[email-masked]&gt;;
Cc:&nbsp;"[email-masked]"<[email-masked]&gt;;"draft-ietf-spring-srv6-network-programming"<[email-masked]&gt;;
Subject:&nbsp;Re: [spring] Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

+1
 
&nbsp;
 
Cheng
 
&nbsp;
   
From: ipv6 [mailto:[email-masked]] On Behalf Of Gengxuesong (Geng Xuesong)
 Sent: Wednesday, February 26, 2020 8:19 PM
 To: Lizhenbin <[email-masked]&gt;; [email-masked]; 'SPRING WG List' <[email-masked]&gt;
 Cc: [email-masked]; draft-ietf-spring-srv6-network-programming <[email-masked]&gt;
 Subject: RE: Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

&nbsp;
 
+1 
 
&nbsp;
 
&nbsp;
 
Best Regards
 
Xuesong
   
From: spring [mailto:[email-masked]] On Behalf Of Lizhenbin
 Sent: Wednesday, February 26, 2020 7:55 PM
 To: [email-masked]; 'SPRING WG List' <[email-masked]&gt;
 Cc: [email-masked]; draft-ietf-spring-srv6-network-programming <[email-masked]&gt;
 Subject: [spring] Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

&nbsp;
 
Hi Bruno and WG,

 
&nbsp;

&nbsp;
 
&nbsp;
 
&nbsp;
 
Best Regards,
 
Zhenbin (Robin)
 
&nbsp;
 
&nbsp;
   
From: [email-masked] [mailto:[email-masked]] 
 Sent: Friday, December 06, 2019 1:15 AM
 To: 'SPRING WG List' <[email-masked]&gt;
 Cc: [email-masked]; draft-ietf-spring-srv6-network-programming <[email-masked]&gt;
 Subject: WGLC - draft-ietf-spring-srv6-network-programming

&nbsp;
 Hello SPRING, &nbsp; This email starts a two weeks Working Group Last Call on draft-ietf-spring-srv6-network-programming [1]. &nbsp; Please read this document if you haven't read the most recent version, and send your comments to the SPRING WG list, no later than December 20. &nbsp; You may copy the 6MAN WG for IPv6 related comment, but consider not duplicating emails on the 6MAN mailing list for the comments which are only spring specifics. &nbsp; If you are raising a point which you expect will be specifically debated on the mailing list, consider using a specific email/thread for this point. This may help avoiding that the thread become specific to this point and that other points get forgotten (or that the thread get converted into parallel independent discussions) &nbsp; Thank you, Bruno &nbsp; [1] https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-05 &nbsp; 
&nbsp;
 _________________________________________________________________________________________________________________________ &nbsp; Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. &nbsp; This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.

---

From: "[email-masked]" <[email-masked]>
Date: Wed, 26 Feb 2020 12:36:11 +0000

+1

Best Regards,
Peng (cmcc)

________________________________
[email-masked]

From: dzp<mailto:[email-masked]>
Date: 2020-02-26 20:31
To: 'SPRING WG List'<mailto:[email-masked]>
CC: [email-masked]<mailto:[email-masked]>; draft-ietf-spring-srv6-network-programming<mailto:[email-masked]>
Subject: Re: [spring] Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming
+1

Best Regards
Zongpeng Du (cmcc)

------------------ Original ------------------
From: "Chengli (Cheng Li)"<[email-masked]>;
Date: Wed, Feb 26, 2020 08:22 PM
To: "'SPRING WG List'"<[email-masked]>;
Cc: "[email-masked]"<[email-masked]>;"draft-ietf-spring-srv6-network-programming"<[email-masked]>;
Subject: Re: [spring] Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

+1

Cheng

+1

Best Regards
Xuesong

Hi Bruno and WG,

Best Regards,
Zhenbin (Robin)

Hello SPRING,

Thank you,

Bruno

Thank you.

---

From: "Chenxia (D)" <[email-masked]>
Date: Wed, 26 Feb 2020 12:39:41 +0000

+1

Xia
________________________________
发件人: Chengli (Cheng Li) [[email-masked]]
发送时间: 2020年2月26日 20:22
收件人: 'SPRING WG List'
抄送: [email-masked]; draft-ietf-spring-srv6-network-programming
主题: Re: [spring] Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

+1

Cheng

+1

Best Regards
Xuesong

Hi Bruno and WG,

Best Regards,
Zhenbin (Robin)

Hello SPRING,

Thank you,

Bruno

Thank you.

---

From: <[email-masked]>
Date: Wed, 26 Feb 2020 14:37:09 +0000

Hi Robin,

I think that this was expected that this specific LC would last for more than 2 weeks.
Summarizing and closing it is on my to do list. (I wish my to do list were smaller, or that I throw more $$ or contributors on action items. But wishing does not help much in my world.)

That been said, this does not change much with regards to technical comments been raised:

-          They are either addressed, non-addressed or pending

-          they can be raised after the WG LC (e.g. during IETF LC or IESG review)

-          they can even be raised after RFC publication. And eventually can led to errata, bis document, deprecation...

So technical review and comments are good, at all time. (although sooner is better)

Best regards,
--Bruno

From: spring [mailto:[email-masked]] On Behalf Of Lizhenbin
Sent: Wednesday, February 26, 2020 12:55 PM
To: DECRAENE Bruno TGI/OLN; 'SPRING WG List'
Cc: [email-masked]; draft-ietf-spring-srv6-network-programming
Subject: [spring] Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

Hi Bruno and WG,

Best Regards,
Zhenbin (Robin)

Hello SPRING,

Thank you,

Bruno

Thank you.

---

From: Fernando Gont <[email-masked]>
Date: Wed, 26 Feb 2020 11:45:14 -0300

On 26/2/20 11:37, [email-masked] wrote:
> Summarizing and closing it is on my to do list. (I wish my to do list 
> were smaller, or that I throw more $$ or contributors on action items. 
> But wishing does not help much in my world.)
> 
> -They are either addressed, non-addressed or pending
> 
> -they can be raised after the WG LC (e.g. during IETF LC or IESG review)
> 
> -they can even be raised after RFC publication. And eventually can led 
> to errata, bis document, deprecation…

So... is the plan to ship a document that violates RFC8200?

Should participants stop wasting time in constructive comments, and 
rather work and prepare to submit a formal appeal, instead?

Thanks,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: <[email-masked]>
Date: Wed, 26 Feb 2020 15:39:33 +0000

Fernando,

> From: Fernando Gont [mailto:[email-masked]] 
> 
> > to errata, bis document, deprecation...
> 

The above statement was meant to say that if the technical comment is valid, its timing (e.g., the fact that it is raised after the original Last Call period) is not an argument to dismiss this technical argument.

Then your question is orthogonal, and the answer to your question is 'No'.
Note that that is also orthogonal as to whether "doing A" violates RFC X or not.

> rather work and prepare to submit a formal appeal, instead?

What is not clear in " So technical review and comments are good, at all time. "?

Thank you
--Bruno

---

From: 神明達哉 <[email-masked]>
Date: Wed, 26 Feb 2020 11:39:55 -0800

At Wed, 26 Feb 2020 11:45:14 -0300,

> So... is the plan to ship a document that violates RFC8200?

Please forgive me asking some clarification question that seems to be
obvious for others: which part of
draft-ietf-spring-srv6-network-programming-10 violates RFC8200?  From
a quick read of it, Section 4.16 seems to describe the removal of an
extension header from an IPv6 packet at a forwarding node.  Is that
the one referenced as a violation?  Or is it something else, or are
there others in addition to 4.16?

--
JINMEI, Tatuya

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 27 Feb 2020 09:57:09 +1300

>  In the process all the comments have been resolved 

Unfortunately, this is not true.

For example, the word "pop" is used but still not defined. In computer science, it generally refers to popping a stack. I understand that in the MPLS context (a label stack) but not in the IPv6 context, where there is no stack in the header.

The text explaining penultimate segment pop, quite apart from using "pop" in this undefined way, still does not explain how it is compatible with the RFC8200 interdiction of inserting or removing headers en route. It explicitly describes removing a header before the final routing hop, which is explicitly against RFC8200.

As far as I'm concerned, these comments have been brushed aside.

The fact that there's running code is good, but it doesn't resolve anything in the text.

Regards
   Brian Carpenter

---

From: 神明達哉 <[email-masked]>
Date: Thu, 27 Feb 2020 12:11:52 -0800

> there others in addition to 4.16?

I've not seen any feedback, but according to the thread messages since
then, it's now pretty clear to me that it's at least about Section
4.16 (or more specifically, 4.16.1, which describes "PSP").

In that case, I have to oppose moving this doc forward in its current
form.

First, as (I believe) Brian also pointed out, the description of this
section is obscure.  And, in fact, it wasn't immediately clear to me
whether it's a violation of RFC8200 (hence the question).

Secondly, with more accurate understanding of the intent of this
section through the discussion of this thread, it's now clearer to me
that it's a violation of the following part of RFC8200:

   Extension headers (except for the Hop-by-Hop Options header) are not
   processed, inserted, or deleted by any node along a packet's delivery
   path, until the packet reaches the node (or each of the set of nodes,
   in the case of multicast) identified in the Destination Address field
   of the IPv6 header.

in that an intermediate node specified in a routing header with
segment left > 0 deletes an extension header.  So at least this
document has to clearly declare updating RFC8200 and get consensus
about it before moving on.  It's not done yet.  Hence my objection.

It's surprising to me that some people seem to (still) argue it's not
a violation because this node "is identified in the Destination
Address field of the IPv6 header" (before swapping it with the next
hop specified in the routing header).  Aside from that this
interpretation logically doesn't make sense as it's not compatible
with AH or PMTUD, if it could be justified with that logic, we
wouldn't have had to go through the long debate in promoting RFC2460
to RFC8200 in the first place.

The conclusion at that time (I wouldn't call it a "consensus" as I
know not everyone was happy about it) was that
- Such kind of insertion and deletion is indeed a violation of
  RFC2460; that's why RFC8200 now clearly says "inserted, or deleted"
  while RFC2460 only states "examined or processed".
- 6man and SPRING WGs will work together to see if we can define an
  exception to loosen the limitation so that a future version of
  SRv6 can validly coexist the base IPv6 standard.  Until then,
  encapsulation/decapsulation is the only standard-compliant behavior.

Now, beyond these technical points, I also have meta-level concerns.
Here I share the frustration of Fernando, even if his word may be too
blunt.  After the hot debate on revising RFC2460, I expected us to
"work together" towards the goal of seeking some middleground.
Admittedly, this process wouldn't be easy - some people who opposed to
the insertion/deletion at that time seem to believe there's no such
middleground anyway.  But some others seem more flexible, and, as far
as I can see, at least everyone is open to have discussions.

But, after nearly 3 years since the publication of RFC8200, we still
seem to have the same easy circumvention:
- Simply dismissing the concern by arguing this is not a violation
- Labeling those who raise concerns as innovation blockers
- Just blaming the IPv6 base protocol as being broken (because it
  doesn't accommodate a feature they want)
- Insisting SRv6 just happens to use IPv6 packet format and some part
  of spec but is not IPv6, indicating it doesn't matter whether it
  violates the IPv6 standard
- Pushing industry agenda instead of working together to reach consensus

I'm sad, but if this doesn't change, the only thing I, as a poor
individual, can make objections to last calls.  At least in the purely
technical sense, I've not seen any difference now and then.  So, the
history would suggest even if we blindly pass this WGLC we'll have a
very long debate at the IETF last call and just reach the same
conclusion.

That would be a waste of time for everyone.  I hope we can be more
cooperative instead of that.

--
JINMEI, Tatuya

---

From: "Pablo Camarillo (pcamaril)" <[email-masked]>
Date: Thu, 27 Feb 2020 20:38:41 +0000

Brian,

>     For example, the word "pop" is used but still not defined. In computer science, it generally refers to popping a stack. I understand that in the MPLS context (a label stack) but not in the IPv6…

You raised such comment on December 7th 2020 at the mailer with respect to draft-ietf-spring-srv6-network-programming-05.
We iterated throughout December publishing the clarifications that you requested in rev06 and 07.
https://mailarchive.ietf.org/arch/msg/spring/Y7XKvgshM8ces-HbkT2uQa37a_w/
https://mailarchive.ietf.org/arch/msg/spring/VpLfcUvDXHzMOU6fTE1_XPzhd68/
https://mailarchive.ietf.org/arch/msg/spring/mXcsWXaISqjzs7g_fJZYhcKabgY/

Also, the word pop is still used in the section title, but it has been removed from the definition of the behavior.

Could you please see the latest version of the draft?

Thanks,
Pablo.

-----Original Message-----
From: Brian E Carpenter <[email-masked]>
Date: Wednesday, 26 February 2020 at 21:57
To: Lizhenbin <[email-masked]>, "[email-masked]" <[email-masked]>, 'SPRING WG List' <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, draft-ietf-spring-srv6-network-programming <[email-masked]>
Subject: Re: Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming
Resent from: <[email-masked]>
Resent to: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Resent date: Wednesday, 26 February 2020 at 21:57

    

    
    
    Regards
       Brian Carpenter

---

From: Ron Bonica <[email-masked]>
Date: Thu, 27 Feb 2020 21:29:24 +0000

Jinmei,

The current discussion is about Penultimate Segment Popping (PSP) (Section 4.16). Normally, when an IPv6 node processes a packet that includes a Routing header with Segment Left equal to 1, the node decrements Segments Left and forwards the packet, with the Routing header intact. In PSP, when an IPv6 node processes a packet that includes a Routing header with Segment Left equal to 1, the node removes the Routing header and forwards the packet, without the Routing header.

The question is whether PSP violates the following clause from Section 4 of RFC 8200:

"Extension headers (except for the Hop-by-Hop Options header) are not
   processed, inserted, or deleted by any node along a packet's delivery
   path, until the packet reaches the node (or each of the set of nodes,
   in the case of multicast) identified in the Destination Address field
   of the IPv6 header."

A literal reading of this text suggest that any segment endpoint (i.e., any node referenced in the Routing Header) can process, insert, or delete any extension header. This is because when a packet arrives at a segment endpoint, one of its addresses appears in the IPv6 Destination Address field.

At least one RFC contradicts this literal reading. Section 3.3.3.1.1.2 of RFC 4302 says that the payload length and next header fields of the IPv6 header are immutable. PSP would change both of these and break AH processing.

When RFC 4302 was published, nobody questioned the assumption that the payload length and next header fields of the IPv6 header are immutable. Therefore, we can assume that it was a commonly held belief.

Some argue that none of this is a problem because the SRH is incompatible with the IPv6 Authentication header (see Section 7.5 of draft-ietf-6man-segemnt-routing-header-26). 

Others argue that PSP may break more than IPv6 AH. Other applications may, may concur with the RFC 4302 reading of RFC 8200. If they rely on payload length and next header fields of the IPv6 header being immutable, they will also break.

                                                                    Ron

Juniper Business Use Only

-----Original Message-----
From: spring <[email-masked]> On Behalf Of ????
Sent: Wednesday, February 26, 2020 2:40 PM
To: Fernando Gont <[email-masked]>
Cc: [email-masked]; SPRING WG List <[email-masked]>; [email-masked]; Lizhenbin <[email-masked]>; draft-ietf-spring-srv6-network-programming <[email-masked]>
Subject: Re: [spring] Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

> So... is the plan to ship a document that violates RFC8200?

Please forgive me asking some clarification question that seems to be obvious for others: which part of
draft-ietf-spring-srv6-network-programming-10 violates RFC8200?  From a quick read of it, Section 4.16 seems to describe the removal of an extension header from an IPv6 packet at a forwarding node.  Is that the one referenced as a violation?  Or is it something else, or are there others in addition to 4.16?

--
JINMEI, Tatuya

_______________________________________________
spring mailing list
[email-masked]
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!X7yacQY8b6Y0TpWJZiqa09s9YN5jOWOtfAZJteY4jOHczN4U3b7fl6FDtYPDLknI$

---

From: Fernando Gont <[email-masked]>
Date: Thu, 27 Feb 2020 18:57:29 -0300

> At least one RFC contradicts this literal reading. Section 3.3.3.1.1.2 of RFC 4302 says that the payload length and next header fields of the IPv6 header are immutable. PSP would change both of the…

The intent is grasped in Appendix B of RFC8200:

    o  Clarified that extension headers (except for the Hop-by-Hop
       Options header) are not processed, inserted, or deleted by any
       node along a packet's delivery path.

We might have done a poor job polishing the text. That doesn't change 
anything. And that's what Errata's are for.

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: 神明達哉 <[email-masked]>
Date: Thu, 27 Feb 2020 14:18:25 -0800

At Thu, 27 Feb 2020 21:29:24 +0000,

> A literal reading of this text suggest that any segment endpoint (i.e., any node referenced in the Routing Header) can process, insert, or delete any extension header. This is because when a packet…

Please see my response to my own message.  Yes, purely "literally", it
could read that way (it's amazing human-written text can be always
ambiguous to some extent, no matter how hard we try to clarify it), but
that doesn't make sense if we recall a larger context.  If the phrase
"Destination Address field of the IPv6 header" could justify the
deletion (or even insertion, for that matter) of an EH at a node like
that, then changing this text in RFC2460

   With one exception, extension headers are not examined or processed
   by any node along a packet's delivery path, until the packet reaches
   the node (or each of the set of nodes, in the case of multicast)
   identified in the Destination Address field of the IPv6 header.

to the above one in RFC8200 shouldn't have caused the painful debate
regarding the implication of SRv6.  We should have known this change
would make the SRv6-style insertion/deletion a violation of the RFC
even more clearly than RFC2460 at that time, and that's why we needed
that discussion.

And that's why I'm surprised at seeing this argument now.  Perhaps
those making this just because they forgot the previous discussion or
simply weren't involved in it.  But combining this point and other
signals that indicate the reluctance to take on the tedious
reconciliation between RFC8200 and this spec (which would be most
likely to require an update to the RFC), it wouldn't be unreasonable
if one suspects it may be an attempt of easily circumventing the
process rather than a genuine misunderstanding of the text.  I guess
this suspicion is somewhat commonly shared by those raising concerns
(including myself).

--
JINMEI, Tatuya

---

From: Suresh Krishnan <[email-masked]>
Date: Thu, 27 Feb 2020 17:34:16 -0500

Hi Jinmei,

> On Feb 27, 2020, at 5:18 PM, 神明達哉 <[email-masked]> wrote:
> 
> ambiguous to some extent, no matter how hard we try to clarify it),

Yes, this is unfortunate. We ended up strengthening some constraints while leaving some others open. While I would (and do) interpret things exactly as you did, it is impossible to determine after the fact if a different text formulation would have gotten consensus. What we have is the text of RFC8200.

> but
> regarding the implication of SRv6.  

In my mind it did because some people claimed that RFC2460 did allow insertion and deletion since it only prohibited “examining and processing” the headers. The controversy was because some people were opposed to the prohibition for insertion and deletion be explicit.

> We should have known this change

Just so we are clear, SRv6 is defined in draft-ietf-6man-segment-routing-header-26 and it does not have anything about header insertion. Some earlier versions of the draft did and I was clear that it needed to be removed for it to progress from 6man. The authors removed the insertion mode from the draft.

Thanks
Suresh

---

From: Fernando Gont <[email-masked]>
Date: Thu, 27 Feb 2020 19:43:25 -0300

> Yes, this is unfortunate. We ended up strengthening some constraints while leaving some others open. While I would (and do) interpret things exactly as you did, it is impossible to determine after…

That's why we have erratas. The intent of RFC8200 is very clear. And I'm 
not sure how, having being involved in such discussion, you question the 
intent.

And if you don't, what would be your argument to process the errata I've 
submitted in any other way than "Verified".

> Just so we are clear, SRv6 is defined in draft-ietf-6man-segment-routing-header-26 and it does not have anything about header insertion. Some earlier versions of the draft did and I was clear that…

No, we are not clear: PSP does extension header removal.

---

From: Mark Smith <[email-masked]>
Date: Fri, 28 Feb 2020 09:57:12 +1100

Hi Ron,

> A literal reading of this text suggest that any segment endpoint (i.e., any node referenced in the Routing Header) can process, insert, or delete any extension header. This is because when a packet…

Some other text that is relevant to the above Section 4 from Section
4.4, "Routing Header":

"The Routing header is used by an IPv6 source to list one or more
   intermediate nodes to be "visited" on the way to a packet's
   destination."

Can intermediate node DAs ever be multicast IPv6 addresses?

If the answer was no, then that means that

"until the packet reaches the node (or each of the set of nodes,
   in the case of multicast) identified in the Destination Address field
   of the IPv6 header."

can only be referring to final unicast or final multicast DAs, not the
intermediate node DAs in an RH.

I wondered if SIDs in the the SRH could be multicast.
'draft-ietf-spring-srv6-network-programming-10' doesn't mention the
word 'multicast' at all, and neither does
'draft-ietf-6man-segment-routing-header-26'.

Regards,
Mark.

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Ron Bonica <[email-masked]>
Date: Thu, 27 Feb 2020 23:06:19 +0000

Mark,

Good point. I think that "The Devil's Paragraph" in RFC 8200 may be ambiguous. We should tighten it us using whatever mechanism the AD's suggest. 

Clearly, this will take time. Until then, we should probably hammer out some compromise so that the bulk of the network programming draft can progress. I suggest such a compromise in https://mailarchive.ietf.org/arch/msg/ipv6/Cj_I28dpXQ1uKPhdGsSaYgMeOo0/.

                                                                               Ron

-----Original Message-----
From: Mark Smith <[email-masked]> 
Sent: Thursday, February 27, 2020 5:57 PM
To: Ron Bonica <[email-masked]>
Cc: 神明達哉 <[email-masked]>; Fernando Gont <[email-masked]>; SPRING WG List <[email-masked]>; [email-masked]; draft-ietf-spring-srv6-network-programming <[email-masked]>
Subject: Re: [spring] Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

Hi Ron,

> A literal reading of this text suggest that any segment endpoint (i.e., any node referenced in the Routing Header) can process, insert, or delete any extension header. This is because when a packet…

Some other text that is relevant to the above Section 4 from Section 4.4, "Routing Header":

can only be referring to final unicast or final multicast DAs, not the intermediate node DAs in an RH.

I wondered if SIDs in the the SRH could be multicast.
'draft-ietf-spring-srv6-network-programming-10' doesn't mention the word 'multicast' at all, and neither does 'draft-ietf-6man-segment-routing-header-26'.

Regards,
Mark.

> At least one RFC contradicts this literal reading. Section 3.3.3.1.1.2 of RFC 4302 says that the payload length and next header fields of the IPv6 header are immutable. PSP would change both of these and break AH processing..
>
> Cc: [email-masked]; SPRING WG List <[email-masked]>; 
> [email-masked]; Lizhenbin <[email-masked]>; 
> draft-ietf-spring-srv6-network-programming 
> <[email-masked]>
> Subject: Re: [spring] Request to close the LC and move forward//RE: 
> WGLC - draft-ietf-spring-srv6-network-programming
>
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spri
> ng__;!!NEt6yMaO-gk!X7yacQY8b6Y0TpWJZiqa09s9YN5jOWOtfAZJteY4jOHczN4U3b7
> fl6FDtYPDLknI$
>
> Administrative Requests: 
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6
> __;!!NEt6yMaO-gk!UjKW8iONc2cSqHE0v27Zk_LKJsFFkan6BYM_bKFHbu3oCjMb7IAgB
> qDifsVU8B_i$

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Thu, 27 Feb 2020 23:41:18 +0000

Hi Jinmei, allow me to address the two technical concerns you raise in this email, upon which it appears this interpretation of RFC8200 hinges for you.  You state:
> Aside from that this

I know a lot of documentation and work has been done with SPRING and 6man since that debate.

1 - I expect everyone reviewing and commenting on draft-ietf-spring-srv6-network-programming (NETPGM) to have fully read draft-ietf-6man-segment-routing-header (SRH) as stated in section 1 NETPGM.
1.1 - remember SRH section 5 defines a deployment model for the SR domain applicable to both documents.

2 - AH is not defined for SRH (section 7.5 of SRH) so the question of how SRH with a PSP SID affects AH is not applicable to NETPGM.

3 - PMTUD within an SR domain is unaffected by PSP.
3.1 - Section 5.3 of SRH, provides recommendation on how MTU is handled within an SR Domain for traffic encapsulated for its journey within the SR domain.  i.e. it is not reliant on PMTUD within the SR Domain.
3.2 - Regardless, as others have stated, performing PSP and reducing the size of a packet has no impact on PMTUD.

I hope this helps clarify your understanding of the current state of the art vs what may have been assumed at some point in the past before this was clarified by 6man and SPRING.

Thanks
 Darren

> On Feb 27, 2020, at 3:11 PM, 神明達哉 <[email-masked]> wrote:
>

---

From: Ron Bonica <[email-masked]>
Date: Thu, 27 Feb 2020 22:59:06 +0000

Jinmei,

My apologies. I was writing my message as you posted yours.

I agree fully with both the spirit and letter of your message.

                                                 Ron

-----Original Message-----
From: 神明達哉 <[email-masked]> 
Sent: Thursday, February 27, 2020 5:18 PM
To: Ron Bonica <[email-masked]>
Cc: Fernando Gont <[email-masked]>; SPRING WG List <[email-masked]>; [email-masked]; draft-ietf-spring-srv6-network-programming <[email-masked]>
Subject: Re: [spring] Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

> A literal reading of this text suggest that any segment endpoint (i.e., any node referenced in the Routing Header) can process, insert, or delete any extension header. This is because when a packet…

Please see my response to my own message.  Yes, purely "literally", it could read that way (it's amazing human-written text can be always ambiguous to some extent, no matter how hard we try to clarify it), but that doesn't make sense if we recall a larger context.  If the phrase "Destination Address field of the IPv6 header" could justify the deletion (or even insertion, for that matter) of an EH at a node like that, then changing this text in RFC2460

to the above one in RFC8200 shouldn't have caused the painful debate regarding the implication of SRv6.  We should have known this change would make the SRv6-style insertion/deletion a violation of the RFC even more clearly than RFC2460 at that time, and that's why we needed that discussion.

And that's why I'm surprised at seeing this argument now.  Perhaps those making this just because they forgot the previous discussion or simply weren't involved in it.  But combining this point and other signals that indicate the reluctance to take on the tedious reconciliation between RFC8200 and this spec (which would be most likely to require an update to the RFC), it wouldn't be unreasonable if one suspects it may be an attempt of easily circumventing the process rather than a genuine misunderstanding of the text.  I guess this suspicion is somewhat commonly shared by those raising concerns (including myself).

--
JINMEI, Tatuya

---

From: 神明達哉 <[email-masked]>
Date: Thu, 27 Feb 2020 16:48:17 -0800

At Thu, 27 Feb 2020 23:41:18 +0000,
"Darren Dukes (ddukes)" <[email-masked]> wrote:

> Hi Jinmei, allow me to address the two technical concerns you raise
> in this email, upon which it appears this interpretation of RFC8200
> hinges for you.  You state:

> I hope this helps clarify your understanding of the current state of the art vs what may have been assumed at some point in the past before this was clarified by 6man and SPRING.

This is not my point (I was actually afraid about having this type of
response when referring to AH/PMTUD.  In retrospect it was probably a
mistake...); I didn't mean NETPGM violates RFC8200 because it would be
incompatible with AH/PMTUD.  My point was that it doesn't make sense
to refer to the phrase "the node...identified in the Destination
Address field of the IPv6 header" to justify the argument that NETPGM
doesn't violate RFC8200.

Now, please note that I'm not necessarily saying that the NETPGM draft
shouldn't move forward simply because it violates RFC8200.  If the
authors/WG believe NETPGM can be an exception to this part of RFC, it
should say it updates this part of RFC8200 and explain why it's
justified (where the discussion about AH/PMTUD will matter).  This
will certainly draw more attention from various kinds of reviewers and
you may find it difficult to defend the claim for these reviewers, but
I don't think it necessarily impossible.  The current version of the
draft doesn't do this, and authors and its supporters just seem to
dismiss the RFC violation with the awkward reference to the
"Destination Address" text.  That's what concerned me.

--
JINMEI, Tatuya

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 28 Feb 2020 14:51:15 +1300

Pablo,

I have been looking at the latest version. See my previous note to Stefano Salsano. I really think that the problem here is that certain things are obvious to SRH experts but not to others, and they simply need more explanation in elementary terms.

Regards
   Brian Carpenter

---

From: huruizhao <[email-masked]>
Date: Fri, 28 Feb 2020 10:12:12 +0000

+1

Best Regards,
Ruizhao

发件人: spring [mailto:[email-masked]] 代表 Lizhenbin
发送时间: 2020年2月26日 19:55
收件人: [email-masked]; 'SPRING WG List' <[email-masked]>
抄送: [email-masked]; draft-ietf-spring-srv6-network-programming <[email-masked]>
主题: [spring] Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

Hi Bruno and WG,

Best Regards,
Zhenbin (Robin)

Hello SPRING,

Thank you,

Bruno

Thank you.