Subject: 6man w.g. last call for <draft-ietf-6man-segment-routing-header-19.txt>

From: Bob Hinden <[email-masked]>
Date: Wed, 22 May 2019 09:39:43 -0400

Hello,

This message starts a new two week 6MAN Working Group Last Call on advancing:

       Title           : IPv6 Segment Routing Header (SRH)
       Authors         : Clarence Filsfils
                         Darren Dukes
                         Stefano Previdi
                         John Leddy
                         Satoru Matsushima
                         Daniel Voyer
	Filename        : draft-ietf-6man-segment-routing-header-19.txt
	Pages           : 32
	Date            : 2019-05-21

    https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header

as a Proposed Standard.  

This document was in an extended last call that started in March of 2018.   An issue tracker was set up, and eight new versions of the draft were produced and discussed on the list and at face to face 6man sessions.   All of the issues in the tracker have been closed.  The chairs believe it is ready to advance, but given the number of changes and the time that elapsed, a new w.g. last call is warranted.  Please review the new document.

Our thanks to the authors/editors and the working group for the work on this document.

Substantive comments and statements of support for publishing this document should be directed to the mailing list. Editorial suggestions can be sent to the author.  This last call will
end on 5 June 2019.

Thanks,
Bob & Ole

---

From: Ron Bonica <[email-masked]>
Date: Wed, 22 May 2019 14:55:45 +0000

Darren,

This may not be a show stopper, but......

Previous versions of this document defined "The END SID". This version defines same SID, but takes away its name.

Why the change? 

                                                 Ron

Juniper Internal

-----Original Message-----
From: ipv6 <[email-masked]> On Behalf Of Bob Hinden
Sent: Wednesday, May 22, 2019 9:40 AM
To: IPv6 List <[email-masked]>
Cc: Bob Hinden <[email-masked]>
Subject: 6man w.g. last call for <draft-ietf-6man-segment-routing-header-19.txt> 

Hello,

    https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2D6man-2Dsegment-2Drouting-2Dheader&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=fDNcELVN4MiFFCkbuV13XrHGSIAnmcRh0zLgQR5srcA&s=icSZuD2M4ujZr1tcY63Q--niU-arOKvEa_jnNSQcjmU&e=

as a Proposed Standard.  

Substantive comments and statements of support for publishing this document should be directed to the mailing list. Editorial suggestions can be sent to the author.  This last call will end on 5 June 2019.

Thanks,
Bob & Ole

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_ipv6&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=fDNcELVN4MiFFCkbuV13XrHGSIAnmcRh0zLgQR5srcA&s=UHddJVc1xna4g23l3V_ZpMx6jBizB0qi87dhSPU6nB0&e=
--------------------------------------------------------------------

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Wed, 22 May 2019 15:05:44 +0000

This was a minor request from the chairs (copy from the private exchange below).

“We think calling it “END SID” makes it harder to understand, we had to go back to see if there were other SIDs defined that would have different behavior.   Since there is only one kind of SID defined, like FIRST SID.  We wonder if it can be just called “SID” and if in the future other SIDs are defined they can be called something else, for example "FOO SID”, or "SID 2”.  This is not a showstopper, but might make the document clearer.”

Darren

> On May 22, 2019, at 10:55 AM, Ron Bonica <rbonica=[email-masked]> wrote:
> 
> Darren,
> 
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6

---

From: Ron Bonica <[email-masked]>
Date: Wed, 22 May 2019 17:06:06 +0000

Darren,

We may have made life more difficult for the following reasons:

- Customers are already talking about "The END SID".
- At least two other drafts refer to "The END SID".  In the future, will they refer to "the otherwise nameless SID defined in draft-ietf-6man-segment-routing-header".  
- The naming conventions that the chairs suggest introduces ambiguity. Does the term "SID" refer to all SIDs (END.X, END.DT4, etc.) collectively? Or does the term "SID" refer to one particular SID that is defined in draft-ietf-6man-segment-routing-header.

If the chairs insist on changing the name of the END SID, let's at least give it a new name.

                                                                               Ron

Juniper Internal

-----Original Message-----
From: Darren Dukes (ddukes) <[email-masked]> 
Sent: Wednesday, May 22, 2019 11:06 AM
To: Ron Bonica <[email-masked]>
Cc: Bob Hinden <[email-masked]>; IPv6 List <[email-masked]>
Subject: Re: 6man w.g. last call for <draft-ietf-6man-segment-routing-header-19.txt> 

Darren

> Administrative Requests: https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_ipv6&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=PhGRH-JTB15lCLlWMcvhkLwXdJePg_9M_xm1MCRZcsE&s=AppdXOgNUZJwY2bO1q6n-0-yqIAXnTLqbjmOzDimpnI&e=

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 22 May 2019 17:47:10 +0000

Bob Hinden wrote on 22/05/2019 13:39:
> The chairs believe it is ready to advance, but given the number of
> changes and the time that elapsed, a new w.g. last call is warranted.
> Please review the new document.

leaving the AH situation unresolved looks fine in the context of having 
a flag to mark each EH as mutable / non-mutable.  No further need to 
bike-shed there.

The rest of the document falls into the category of nuclear power plant 
complexity in terms of direct technical details and downstream 
consequences and applications, but from a helicopter view, it looks 
sensible, thorough and well thought.

Is it ok for a document like this to specify the registration request 
procedure in section 8? This seems a bit like the tail wagging the dog.

Nick

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Wed, 22 May 2019 17:59:39 +0000

Hi Nick, thanks for re-reading.  

If you refer to the text starting with "For registration requests where a Designated Expert should…” in section 8, RFC8126 tells us how to write the designated expert portion of the IANA considerations and references RFC3748 as a model of how to write that section.

The Text in section 8 is based on that of RFC2748 and is what was requested in RFC8126.

Darren

> On May 22, 2019, at 1:47 PM, Nick Hilliard <[email-masked]> wrote:
> 
> leaving the AH situation unresolved looks fine in the context of having a flag to mark each EH as mutable / non-mutable.  No further need to bike-shed there.
> 
> The rest of the document falls into the category of nuclear power plant complexity in terms of direct technical details and downstream consequences and applications, but from a helicopter view, it looks sensible, thorough and well thought.
> 
> Is it ok for a document like this to specify the registration request procedure in section 8? This seems a bit like the tail wagging the dog.
> 
> Nick
>

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 22 May 2019 18:02:34 +0000

Darren Dukes (ddukes) wrote on 22/05/2019 17:59:
> If you refer to the text starting with "For registration requests
> where a Designated Expert should…” in section 8, RFC8126 tells us how
> to write the designated expert portion of the IANA considerations and
> references RFC3748 as a model of how to write that section.

That, I did not know.  No further comments, m'lord.

Nick

---

From: Bob Hinden <[email-masked]>
Date: Wed, 22 May 2019 19:28:50 -0400

Ron,

> On May 22, 2019, at 1:06 PM, Ron Bonica <[email-masked]> wrote:
> 
> Darren,
> 

How can anything be more difficult than it already is :-)

> 
> - Customers are already talking about "The END SID”.
> - At least two other drafts refer to "The END SID".  In the future, will they refer to "the otherwise nameless SID defined in draft-ietf-6man-segment-routing-header”.  

SID would refer to the SID defined in the SRH draft.   I note that in RFC 8402, this appears to be called SRv6 SID.  That seems to be consistent.

When we reviewed the changes in what became the -19 draft, we found the use of “END SID” confusing.  We went back to see if there were other kinds of SIDs defined (for example is there a START SID, MIDDLE SID, etc.), but there isn’t.   We thought it would be better to just say SID.   If new SIDs are later defined elsewhere they can have different names that distinguish them from the SID defined in the SRH draft.  

> If the chairs insist on changing the name of the END SID, let's at least give it a new name.

To be clear, we didn’t insist, we made a suggestion that Darren adopted:

Bob

---

From: Ron Bonica <[email-masked]>
Date: Thu, 23 May 2019 00:25:17 +0000

Bob,

All of the SID in draft-ietf-spring-srv6-nework-programming begin with the word "END". The following are examples:

- END
- END.X
- END.DT4

So, you are correct in saying that the word "END" doesn't do much to distinguish one SID from another. Maybe the naming convention should be:

- SID
- SID.X
- SID.DT4
- etc

As long as we are consistent throughout the network programming draft, I am OK with the change.

Also, we need a good collective noun for SIDs of all types. Neither SID nor SRv6 SID work well. If we use the word "SID", it becomes overloaded. The term "SRv6 SID" is a little too close to "SID" to prevent confusion.

                                                                                                         Ron

Juniper Internal

-----Original Message-----
From: Bob Hinden <[email-masked]> 
Sent: Wednesday, May 22, 2019 7:29 PM
To: Ron Bonica <[email-masked]>
Cc: Bob Hinden <[email-masked]>; Darren Dukes (ddukes) <[email-masked]>; IPv6 List <[email-masked]>
Subject: Re: 6man w.g. last call for <draft-ietf-6man-segment-routing-header-19.txt> 

Ron,

Bob

---

From: Bob Hinden <[email-masked]>
Date: Wed, 22 May 2019 21:33:56 -0400

Ron,

> On May 22, 2019, at 8:25 PM, Ron Bonica <[email-masked]> wrote:
> 
> Bob,
> 

I think that would be better.

> Also, we need a good collective noun for SIDs of all types. Neither SID nor SRv6 SID work well. If we use the word "SID", it becomes overloaded. The term "SRv6 SID" is a little too close to "SID" t…

Perhaps when meaning all SIDs, just say “all SIDs”.  When one specific SID, by it’s name SID, SID.X, etc.  

Bob

---

From: Ron Bonica <[email-masked]>
Date: Thu, 23 May 2019 01:58:56 +0000

Works for me!

Juniper Internal

-----Original Message-----
From: Bob Hinden <[email-masked]> 
Sent: Wednesday, May 22, 2019 9:34 PM
To: Ron Bonica <[email-masked]>
Cc: Bob Hinden <[email-masked]>; Darren Dukes (ddukes) <[email-masked]>; IPv6 List <[email-masked]>
Subject: Re: 6man w.g. last call for <draft-ietf-6man-segment-routing-header-19.txt> 

Ron,

Bob

---

From: Xiejingrong <[email-masked]>
Date: Thu, 23 May 2019 08:47:12 +0000

Support WGLC.

Some minor/editorial nits:
(1) Below text in section 2 is irrelevant and incorrect, because there is no 'mutable' or 'mutability' word in RFC8200.

   In the SRH, the Next Header, Hdr Ext Len, and Routing Type fields are
   defined in Section 4.4 of [RFC8200] as not mutable.  The Segments
   Left field is defined as mutable in Section 4.4 of [RFC8200].

   Some of the other fields of the SRH change en route (i.e. they are
   mutable).  The SRH is processed as defined in Section 4.3 of this
   document, and uniquely per SID type.  The mutability of the remaining
   fields in the SRH (Flags, Tag, Segment List, Optional TLVs) are
   defined in that section, in the context of segment processing.

(2)the "or No Next Header" in the title of section 4.3.1.2 is irrelevant.
4.3.1.2.  Upper-layer Header or No Next Header

Thanks,
Jingrong

-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of Bob Hinden
Sent: Wednesday, May 22, 2019 9:40 PM
To: IPv6 List <[email-masked]>
Cc: Bob Hinden <[email-masked]>
Subject: 6man w.g. last call for <draft-ietf-6man-segment-routing-header-19.txt> 

Hello,

as a Proposed Standard.  

Thanks,
Bob & Ole

---

From: Bob Hinden <[email-masked]>
Date: Thu, 23 May 2019 08:32:46 -0400

Jingrong,

> On May 23, 2019, at 4:47 AM, Xiejingrong <[email-masked]> wrote:
> 
> Support WGLC.
> 

The w.g. chairs concluded that the consensus of the 6man w.g. was that the the mutability of the SRH fields be specified.  See:

  https://mailarchive.ietf.org/arch/msg/ipv6/jBpmjGZd77ZRHKOKUF6Hsbcc0is

That makes it both correct and relevant.   

Regards,
Bob

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Thu, 23 May 2019 15:22:15 +0000

Ron and Bob, this is not complicated.

This document refers to "the SID type defined in section 4.3.1” vs calling it END.
Other documents will refer to it as “the SID type defined in section 4.3.1 of draft-ietf-6man-segment-routing-header”.
This is simple and all we need to be concerned with for draft-ietf-6man-segment-routing-header-19.

The second part of this thread is about draft-ietf-spring-network-programming.
It defines a set of additional functions that can be associated with a SID and names them End, End.X, End.T, End.DX2, etc.
It defines a registry to assign each of these SID types a number.
This is how protocols (ISIS, OSPF, BGP, etc) distributing SIDs and identify their type for use at SR Source nodes.
As mentioned on the SPRING alias, the definition of End in draft-ietf-spring-network-programming will get updated to better align with section 4.3.1 of draft-ietf-6man-segment-routing-header.

Darren

> On May 22, 2019, at 9:58 PM, Ron Bonica <[email-masked]> wrote:
> 
> Works for me!
> 
> 
> Juniper Internal
>

---

From: stefano previdi <[email-masked]>
Date: Thu, 23 May 2019 18:09:49 +0200

Hi,

I support the publication of draft-ietf-6man-segment-routing-header.

thanks.
s.

> On May 22, 2019, at 3:39 PM, Bob Hinden <[email-masked]> wrote:
> 
> Hello,
>

---

From: Tom Herbert <[email-masked]>
Date: Thu, 23 May 2019 09:12:50 -0700

Darren,

I don't know what a "SID type" is, so it's hard to understand the
requirements reference SID types. Please provide a normative
definition for this term or a reference to the document containing the
definition of this term. And if multiple SID types are allowed then
obious question becomes how are different SID types distinguished from
one another in the protocol.

Tom

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Thu, 23 May 2019 16:55:20 +0000

Tom, read the paragraph below your question.

> On May 23, 2019, at 12:12 PM, Tom Herbert <[email-masked]> wrote:
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 23 May 2019 12:58:59 -0400

Let me try rephraising Tom's question, since I think I share his 
concern.  (Apologies Tom if I ask something else.)

The mutability constraints for SRH are described in teh document as 
depending upon the SID type.
These mutability requirements affect validation of an AH header.
This seems to raise several problems.

1) When the AH is being verified at someplace other than the current SRH 
SID enadpoint, there is no reason to expect the verifier to know the SID 
type.  So how can it verify the AH?

2) More importantly, consider the case where there are several SIDs in 
the SID list.  Suppose SID 2 has more generous mutability than SID 3. 
So the endpoint identified by SID 2 modifies some of the SRH according 
to the SID2 rules.  Then changes the destination to SID 3.  Now the 
packet arrives at SID 3 and he wants to verify the AH.  But the SRH has 
been modified in accordance with the SID2 rules.  Which SID3 does not 
even know about.  How is this supposed to work?

Yours,
Joel

PS: The wording on the mutability is unclear as to whether what can be 
changed is just the TLV content, or the type value itself.  If you can, 
please clarify.

---

From: Tom Herbert <[email-masked]>
Date: Thu, 23 May 2019 11:22:47 -0700

Darren,

I assume you mean this:

"The second part of this thread is about
draft-ietf-spring-network-programming. It defines a set of additional
functions that can be associated with a SID and names them End, End.X,
End.T, End.DX2, etc. It defines a registry to assign each of these SID
types a number."

But draft-ietf-spring-network-programming only mentions the term "SID
type" once and only mentions the IPv6 address SID type:

"SID: A Segment Identifier which represents a specific segment in
segment routing domain.  The SID type used in this document is IPv6
address (also referenced as SRv6 Segment or SRv6 SID)."

END, END.X, END.T are referred "Functions associated with a SID" as in
section 4, not as SID type. Are these SID types distinct from the IPv6
address SID type?

If this term is being used in a normative manner, for instance if the
mutability requirements are dependent on the SID type, then I think it
warrants a clear definition.

Tom

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 24 May 2019 08:55:26 +1200

> That makes it both correct and relevant.   

To be even more clear, RFC8200 does not use the word mutable, but it
does deal with the mutability of options:
"The third-highest-order bit of the Option Type specifies whether or
not the Option Data of that option can change en route to the
packet's final destination." And it's clear in RFC8200 that at least
the "Segments Left" field of a routing header is mutable. So the
concept of mutability is covered, even if the word is not used.
Of course RFC4302 makes this even clearer.

Regards
   Brian

> .

---

From: Tom Herbert <[email-masked]>
Date: Thu, 23 May 2019 15:06:58 -0700

On Thu, May 23, 2019 at 1:55 PM Brian E Carpenter
<[email-masked]> wrote:
> packet's final destination."

That makes one wonder why the text from RFC8200 wasn't directly
adapted for use here. For instance, this could read:

"The highest-order bit of the TLV type specifies whether or not the
TLV data of that option can change en route to the packet's final
destination.

       0 - TLV data does not change en route

       1 - TLV data may change en route"

but the current text reads:

"TLVs may change en route at each segment.  To identify when a TLV
type may change en route the most significant bit of the Type has the
following significance:

      0: TLV data does not change en route

      1: TLV data does change en route"

I believe the intent here is that TLV data may change in route why the
high order bit is set in the type, so the phrase " TLVs may change en
route" is imprecise, only TLV data can change not type or length (if
this is not the intent please let us know). The additional text about
mutability in section 4.3.1 does nothing to bring clarity on this.

Tom

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Fri, 24 May 2019 15:41:41 +0000

Tom, the action requested by the WG was to restore the text from rev 17. that was done.

Now you appear to have an editorial comment to change that restored text to be something slightly different that you find more precise.  Is that correct?

Darren

On May 23, 2019, at 6:06 PM, Tom Herbert <[email-masked]<mailto:[email-masked]>> wrote:

On Thu, May 23, 2019 at 1:55 PM Brian E Carpenter
<[email-masked]<mailto:[email-masked]>> wrote:

On May 23, 2019, at 4:47 AM, Xiejingrong <[email-masked]<mailto:[email-masked]>> wrote:

Support WGLC.

Tom

Regards
  Brian

Regards,
Bob

Thanks,
Jingrong

-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of Bob Hinden
Sent: Wednesday, May 22, 2019 9:40 PM
To: IPv6 List <[email-masked]<mailto:[email-masked]>>
Cc: Bob Hinden <[email-masked]<mailto:[email-masked]>>
Subject: 6man w.g. last call for <draft-ietf-6man-segment-routing-header-19.txt>

Hello,

as a Proposed Standard.

Thanks,
Bob & Ole

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

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

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

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

---

From: Tom Herbert <[email-masked]>
Date: Fri, 24 May 2019 09:33:56 -0700

> Now you appear to have an editorial comment to change that restored text to be something slightly different that you find more precise.  Is that correct?
Tom,

If this is just an editorial change to that text then that would be
fine, but this isn't the only change in -19 that discusses mutability.
The last paragraph in section 4.3.1 was added in -19,and not in -17 or
18, and I don't know that there was discussion in the WG about the
need for this. In particular, the sentence: "The remainder of the SRH
(Flags, Tag, Segment List, and TLVs that do not change en route) are
immutable while processing this SID type." seems to imply that the
mutbability requirements are depended on SID type (a term which AFAICT
isn't clearly defined). So to me, the mutability requirements are
still either ambiguous or conflicting in version -19 of the draft. I
would to proceed to write the draft on SR and AH, but without clear
unambiguous requirements on mutability that's hard.

Tom

> Darren
>
> On May 23, 2019, at 6:06 PM, Tom Herbert <[email-masked]> wrote:
>

---

From: Bob Hinden <[email-masked]>
Date: Fri, 24 May 2019 19:33:28 -0400

Joel, 

> On May 23, 2019, at 12:58 PM, Joel M. Halpern <[email-masked]> wrote:
> 
> Let me try rephraising Tom's question, since I think I share his concern.  (Apologies Tom if I ask something else.)
> 
> The mutability constraints for SRH are described in teh document as depending upon the SID type.

Are we discussing from Section 2. Segment Routing Extension Header:

The document defines a single SID and the mutability fields in the SRH header and TLVs.   It says that in the future other SIDs may be defined.  Of course, a future document can redefine anything, like all new IETF documents.   

The chairs view of the w.g. consensus was to define the mutability of SRH so some future document could specify how AH works with SRH.   It was out of scope to define how AH works in this document.  

Would it help to change the language to make it clearer that mutability is not tied to a single SID definition?   Or that future SID definitions need to specify their mutability?

Thanks,
Bob

> 1) When the AH is being verified at someplace other than the current SRH SID enadpoint, there is no reason to expect the verifier to know the SID type.  So how can it verify the AH?
> 
> 2) More importantly, consider the case where there are several SIDs in the SID list.  Suppose SID 2 has more generous mutability than SID 3. So the endpoint identified by SID 2 modifies some of the SRH according to the SID2 rules.  Then changes the destination to SID 3.  Now the packet arrives at SID 3 and he wants to verify the AH.  But the SRH has been modified in accordance with the SID2 rules.  Which SID3 does not even know about.  How is this supposed to work?
> 
> Yours,
> Joel
> 
> PS: The wording on the mutability is unclear as to whether what can be changed is just the TLV content, or the type value itself.  If you can, please clarify.
>

---

From: Bob Hinden <[email-masked]>
Date: Fri, 24 May 2019 19:37:21 -0400

Tom,

> mutability in section 4.3.1 does nothing to bring clarity on this.

To my read, I think I prefer that text you are proposing.  That is:

  The highest-order bit of the TLV type specifies whether or not the
  TLV data of that option can change en route to the packet's final
  destination.

      1 - TLV data may change en route”

Any objections to making this change?

Bob

---

From: "[email-masked]" <[email-masked]>
Date: Fri, 24 May 2019 20:25:22 -0400

If this document says "this is the mutabuty" then we are fine.  But if the mutability is claimed to be per SID type, then I do not see how it works.  If there were a constraint that a given packet could only use SIDs of one type, then it could work.  But what does it mean for mutabuty to depend on type, but the SID list to contain several types.  Presumably with possibly different mutability constraints?The problem is not with defining AH.  It is with allowing varying mutability.Yours,JoelSent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone
-------- Original message --------From: Bob Hinden <[email-masked]> Date: 5/24/19  19:33  (GMT-05:00) To: "Joel M. Halpern" <[email-masked]> Cc: Bob Hinden <[email-masked]>, Tom Herbert <[email-masked]>, "Darren Dukes (ddukes)" <[email-masked]>, IPv6 List <[email-masked]> Subject: Re: 6man w.g. last call for
  <draft-ietf-6man-segment-routing-header-19.txt> Joel, > On May 23, 2019, at 12:58 PM, Joel M. Halpern <[email-masked]> wrote:> > Let me try rephraising Tom's question, since I think I share his concern.  (Apologies Tom if I ask something else.)> > The mutability constraints for SRH are described in teh document as depending upon the SID type.Are we discussing from Section 2. Segment Routing Extension Header:  Some of the other fields of the SRH change en route (i.e. they are  mutable).  The SRH is processed as defined in Section 4.3 of this  document, and uniquely per SID type.  The mutability of the remaining  fields in the SRH (Flags, Tag, Segment List, Optional TLVs) are  defined in that section, in the context of segment processing.The document defines a single SID and the mutability fields in the SRH header and TLVs.   It says that in the future other SIDs may be defined.  Of course, a future document can redefine anything, like all new IETF documents.   The chairs view of the w.g. consensus was to define the mutability of SRH so some future document could specify how AH works with SRH.   It was out of scope to define how AH works in this document.  Would it help to change the language to make it clearer that mutability is not tied to a single SID definition?   Or that future SID definitions need to specify their mutability?Thanks,Bob> These mutability requirements affect validation of an AH header.> This seems to raise several problems.> > 1) When the AH is being verified at someplace other than the current SRH SID enadpoint, there is no reason to expect the verifier to know the SID type.  So how can it verify the AH?> > 2) More importantly, consider the case where there are several SIDs in the SID list.  Suppose SID 2 has more generous mutability than SID 3. So the endpoint identified by SID 2 modifies some of the SRH according to the SID2 rules.  Then changes the destination to SID 3.  Now the packet arrives at SID 3 and he wants to verify the AH.  But the SRH has been modified in accordance with the SID2 rules.  Which SID3 does not even know about.  How is this supposed to work?> > Yours,> Joel> > PS: The wording on the mutability is unclear as to whether what can be changed is just the TLV content, or the type value itself.  If you can, please clarify.> > On 5/23/19 12:12 PM, Tom Herbert wrote:>> On Thu, May 23, 2019 at 8:23 AM Darren Dukes (ddukes) <[email-masked]> wrote:>>> >>> Ron and Bob, this is not complicated.>>> >>> This document refers to "the SID type defined in section 4.3.1” vs calling it END.>>> Other documents will refer to it as “the SID type defined in section 4.3.1 of draft-ietf-6man-segment-routing-header”.>>> This is simple and all we need to be concerned with for draft-ietf-6man-segment-routing-header-19.>> Darren,>> I don't know what a "SID type" is, so it's hard to understand the>> requirements reference SID types. Please provide a normative>> definition for this term or a reference to the document containing the>> definition of this term. And if multiple SID types are allowed then>> obious question becomes how are different SID types distinguished from>> one another in the protocol.>> Tom>>> >>> The second part of this thread is about draft-ietf-spring-network-programming.>>> It defines a set of additional functions that can be associated with a SID and names them End, End.X, End.T, End.DX2, etc.>>> It defines a registry to assign each of these SID types a number.>>> This is how protocols (ISIS, OSPF, BGP, etc) distributing SIDs and identify their type for use at SR Source nodes.>>> As mentioned on the SPRING alias, the definition of End in draft-ietf-spring-network-programming will get updated to better align with section 4.3.1 of draft-ietf-6man-segment-routing-header.>>> >>> Darren>>> >>> >>>> On May 22, 2019, at 9:58 PM, Ron Bonica <[email-masked]> wrote:>>>> >>>> Works for me!>>>> >>>> >>>> Juniper Internal>>>> >>>> -----Original Message----->>>> From: Bob Hinden <[email-masked]>>>>> Sent: Wednesday, May 22, 2019 9:34 PM>>>> To: Ron Bonica <[email-masked]>>>>> Cc: Bob Hinden <[email-masked]>; Darren Dukes (ddukes) <[email-masked]>; IPv6 List <[email-masked]>>>>> Subject: Re: 6man w.g. last call for <draft-ietf-6man-segment-routing-header-19.txt>>>>> >>>> Ron,>>>> >>>>> On May 22, 2019, at 8:25 PM, Ron Bonica <[email-masked]> wrote:>>>>> >>>>> Bob,>>>>> >>>>> All of the SID in draft-ietf-spring-srv6-nework-programming begin with the word "END". The following are examples:>>>>> >>>>> - END>>>>> - END.X>>>>> - END.DT4>>>>> >>>>> So, you are correct in saying that the word "END" doesn't do much to distinguish one SID from another. Maybe the naming convention should be:>>>>> >>>>> - SID>>>>> - SID.X>>>>> - SID.DT4>>>>> - etc>>>> >>>> I think that would be better.>>>> >>>>> >>>>> As long as we are consistent throughout the network programming draft, I am OK with the change.>>>>> >>>>> Also, we need a good collective noun for SIDs of all types. Neither SID nor SRv6 SID work well. If we use the word "SID", it becomes overloaded. The term "SRv6 SID" is a little too close to "SID" to prevent confusion.>>>> >>>> Perhaps when meaning all SIDs, just say “all SIDs”.  When one specific SID, by it’s name SID, SID.X, etc.>>>> >>>> Bob>>>> >>>> >>>>> >>>>>                                                                                                        Ron>>>>> >>>>> >>>>> Juniper Internal>>>>> >>>>> -----Original Message----->>>>> From: Bob Hinden <[email-masked]>>>>>> Sent: Wednesday, May 22, 2019 7:29 PM>>>>> To: Ron Bonica <[email-masked]>>>>>> Cc: Bob Hinden <[email-masked]>; Darren Dukes (ddukes) <[email-masked]>; IPv6 List <[email-masked]>>>>>> Subject: Re: 6man w.g. last call for <draft-ietf-6man-segment-routing-header-19.txt>>>>>> >>>>> Ron,>>>>> >>>>>> On May 22, 2019, at 1:06 PM, Ron Bonica <[email-masked]> wrote:>>>>>> >>>>>> Darren,>>>>>> >>>>>> We may have made life more difficult for the following reasons:>>>>> >>>>> How can anything be more difficult than it already is :-)>>>>> >>>>>> >>>>>> - Customers are already talking about "The END SID”.>>>>>> - At least two other drafts refer to "The END SID".  In the future, will they refer to "the otherwise nameless SID defined in draft-ietf-6man-segment-routing-header”.>>>>>> - The naming conventions that the chairs suggest introduces ambiguity. Does the term "SID" refer to all SIDs (END.X, END.DT4, etc.) collectively? Or does the term "SID" refer to one particular SID that is defined in draft-ietf-6man-segment-routing-header.>>>>> >>>>> SID would refer to the SID defined in the SRH draft.   I note that in RFC 8402, this appears to be called SRv6 SID.  That seems to be consistent.>>>>> >>>>> When we reviewed the changes in what became the -19 draft, we found the use of “END SID” confusing.  We went back to see if there were other kinds of SIDs defined (for example is there a START SID, MIDDLE SID, etc.), but there isn’t.   We thought it would be better to just say SID.   If new SIDs are later defined elsewhere they can have different names that distinguish them from the SID defined in the SRH draft.>>>>> >>>>>> If the chairs insist on changing the name of the END SID, let's at least give it a new name.>>>>> >>>>> To be clear, we didn’t insist, we made a suggestion that Darren adopted:>>>>> >>>>> “We think calling it “END SID” makes it harder to understand, we had to go back to see if there were other SIDs defined that would have different behavior.   Since there is only one kind of SID defined, like FIRST SID.  We wonder if it can be just called “SID” and if in the future other SIDs are defined they can be called something else, for example "FOO SID”, or "SID 2”.  This is not a showstopper, but might make the document clearer.”>>>>> >>>>> Bob>>>>> >>> >>> -------------------------------------------------------------------->>> IETF IPv6 working group mailing list>>> [email-masked]>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6>>> -------------------------------------------------------------------->> -------------------------------------------------------------------->> IETF IPv6 working group mailing list>> [email-masked]>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6>> --------------------------------------------------------------------

---

From: Tom Herbert <[email-masked]>
Date: Fri, 24 May 2019 19:26:17 -0700

Bob,

The consensus was (from your email):
1) The SRH draft should clearly specific which SRH fields are mutable,
non-mutable, and/or predictable to be consistent with RFC8200.
2) We don’t think the document needs to specify how AH should work with SRH.
> Would it help to change the language to make it clearer that mutability is not tied to a single SID definition?   Or that future SID definitions need to specify their mutability?

The changes in version -19 are very are confusing to me. If version
-19 had just clarified mutability requirements and deferred AH to
other documents then there wouldn't be an issue, *but* this version
introduces additional text in this area, namely the text in section
2.0 and similar text in section 4.3.1 that makes mutability
requirements of SRH conditional on SID type, as well as the second
paragraph in section 7.5 that attempts to to rationalize why AH is
unneeded with segment routing. AFAICT, none of this content was
previously discussed and I don't believe any of this is pertinent to
meet the directives in the consensus call.

Also, I'm very sorry to complain, but I was bit surprised by a couple
of procedural happenings with this:

1) I received email that the draft was going to WGLC even before
seeing the posting of version -19. Mutability was a major issue and we
have been waiting on the draft that fixes the issue, it would have
been nice to have at least a little chance to see if draft actually
addressed the issue.
2) Ticket #69 "Adding/Deleting TLVs", which was created based on an
email I sent, was closed on the basis of the changes in -19 which
again we had no time to review. Looking again at this issue, and in
light of the new text in section 2.0 and 4.3.1, it is still not clear
to me that TLV insertion and deletion is really prohibited in SRH. I
do not believe this ticket should be closed.

Tom

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Sat, 25 May 2019 11:27:28 +0000

Bob. This text is functionally identical to the current text. This editorial change can be made but we would replace the word option with type.

Darren

> On May 24, 2019, at 7:38 PM, Bob Hinden <[email-masked]> wrote:
> 
> Tom,
>

---

From: Bob Hinden <[email-masked]>
Date: Sat, 25 May 2019 07:43:35 -0400

Darren,

> On May 25, 2019, at 7:27 AM, Darren Dukes (ddukes) <[email-masked]> wrote:
> 

Looking back at the doc, that sounds right to me.  The T in TLV, is of course "Type".  So it would be:

  The highest-order bit of the TLV type specifies whether or not the
  TLV data of that type can change en route to the packet's final
  destination.

Thanks,
Bob

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Sat, 25 May 2019 11:54:51 +0000

The Sr source node knows fully what sids it adds to a segment list and how they are processed. This is the point of source routing in general and segment routing specifically. The source has full knowledge and control always. 

The mutability of the srh is fully and correctly defined in this version of the text. 

Darren

> On May 24, 2019, at 10:26 PM, Tom Herbert <[email-masked]> wrote:
>

---

From: Joel Halpern Direct <[email-masked]>
Date: Sat, 25 May 2019 11:56:07 -0400

Darren, I do not understand how the source node knowing what it puts on 
is relevant.

Suppose we have a packet with an SRH.  And suppose that the SRH uses 
three different SID types.  And suppose that, per the mutability section 
of this document, those three SID types have different mutability 
permissions.

What does this mean for who is allowed to modify what fields in the SRH 
when?  the reason mutability matters is that affects both how earlier 
nodes understand what will be delivered and how later nodes understand 
the relationship between what they received and what was sent. 
Unfortunately, a later node may well not know the SID types of the 
various SIDs in the list, or how those interact with the mutability.

Arguably, one could go even further.  From lots of discussions, we 
expect that SID lists will be provided by control systems.  At that 
point, while the control system presumably knows what the SID types are 
and how they affect mutability, there is NOT reason to expect the 
initial node to understand the SID types, much less their effect on 
mutability.

If we agree, as the chairs have said, taht we need to spell out the 
mutability, then we need to spell out the mutability.  If mutability 
depends upon the values in various entries in the SID list (what types 
of SIDs are used) then that mutability needsto be spelled out and 
explained how various constraints interact.

Yes, any IETF document can add exceptions, with working group agreement 
when it approves such a document, to a requirement.  But putting into 
the document that the spec doesn't actually tell you what the 
constraints are does not answer the mutability constraint.

Also, given that tLVs are tied to the entire SRH, not just to a given 
SID, there seems to be something very strange in a SID type changing the 
mutability constraints on the TLVs.

Yours,
Joel

---

From: <[email-masked]>
Date: Mon, 27 May 2019 09:02:34 +0000

Hi Bob, all,

I do still don't understand the intent of this field:  

   o  Tag: tag a packet as part of a class or group of packets, e.g.,
      packets sharing the same set of properties.  When tag is not used
      at source it MUST be set to zero on transmission.  When tag is not
      used during SRH Processing it SHOULD be ignored.  Tag is not used
      when processing the SID defined in Section 4.3.1.  It may be used
      when processing other SID types which are not defined in this
      document.  The allocation and use of tag is outside the scope of
      this document.

In the absence of a clear definition of this field, it is better to set these bits as unassigned. 

Cheers,
Med

> -----Message d'origine-----
> De : ipv6 [mailto:[email-masked]] De la part de Bob Hinden
> Envoyé : mercredi 22 mai 2019 15:40
> À : IPv6 List
> Cc : Bob Hinden
> Objet : 6man w.g. last call for <draft-ietf-6man-segment-routing-header-
> 19.txt>
> 
> Hello,
> 
> This document was in an extended last call that started in March of 2018.
> An issue tracker was set up, and eight new versions of the draft were
> produced and discussed on the list and at face to face 6man sessions.
> All of the issues in the tracker have been closed.  The chairs believe it
> is ready to advance, but given the number of changes and the time that
> elapsed, a new w.g. last call is warranted.  Please review the new
> document.
> 
> Substantive comments and statements of support for publishing this
> document should be directed to the mailing list. Editorial suggestions can
> be sent to the author.  This last call will
> end on 5 June 2019.
> 
> Thanks,
> Bob & Ole
> 
> 
> 
>

---

From: Lizhenbin <[email-masked]>
Date: Mon, 27 May 2019 11:52:11 +0000

I support the Last Call of the draft. The solution proposed in the draft has been discussed 
for a long time and there are already multiple commercial implementations and deployments. 
In addition all possible comments was closed and consensus for the last call was made in 
the IETF104. 
It is the right time for the last call. 

Best Regards,
Zhenbin (Robin)

> Envoyé : mercredi 22 mai 2019 15:40 À : IPv6 List Cc : Bob Hinden 
> All of the issues in the tracker have been closed.  The chairs believe 
> it is ready to advance, but given the number of changes and the time 
> that elapsed, a new w.g. last call is warranted.  Please review the 
> new document.
> 
> document should be directed to the mailing list. Editorial suggestions 
> can be sent to the author.  This last call will end on 5 June 2019.
> 
> Thanks,
> Bob & Ole
> 
> 
> 
>

---

From: "Chengli (Cheng Li)" <[email-masked]>
Date: Mon, 27 May 2019 12:41:33 +0000

Support. Many thanks to authors for their contributions! I agree that we should specify how the AH works with SRH in other drafts. 

But I can NOT find any text of describing Hdr Ext Len is not mutable in RFC8200. 
Hdr Ext Len SHOULD be mutable, otherwise, use cases like incremental SRv6 IOAM[1] can not work. 
All the use cases of inserting or deleting new TLV, or updating TLV with new length value are not allowed if Hdr Ext Len is not mutable. 

I think it is a limitation to SRv6 that we should avoid it definitely.

Best Regards,
Cheng

[1]. https://tools.ietf.org/html/draft-ali-6man-spring-srv6-oam-01#section-4.4.1

-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of Bob Hinden
Sent: Wednesday, May 22, 2019 9:40 PM
To: IPv6 List <[email-masked]>
Cc: Bob Hinden <[email-masked]>
Subject: 6man w.g. last call for <draft-ietf-6man-segment-routing-header-19.txt> 

Hello,

as a Proposed Standard.  

Thanks,
Bob & Ole

---

From: Tom Herbert <[email-masked]>
Date: Mon, 27 May 2019 08:41:08 -0700

> But I can NOT find any text of describing Hdr Ext Len is not mutable in RFC8200.

Chengli,

Extension headers are not inserted or deleted by any node along a
packet's delivery path per RFC8200. Changing the length of an
extension header is equivalent to deleting an extension header and
inserting a new one in its place.

> Hdr Ext Len SHOULD be mutable, otherwise, use cases like incremental SRv6 IOAM[1] can not work.

This topic has come up before in 6man list, in fact this is the
subject of draft-voyer-6man-extension-header-insertion-05. In those
discussions, issues in robustness, accountability and attribution
(both for operational and legal purposes), security, operations
(breaks ICMP for instance) have been brought up. The proponents of
extension header insertion have yet to adequately address those
issues.

> All the use cases of inserting or deleting new TLV, or updating TLV with new length value are not allowed if Hdr Ext Len is not mutable.

Adding and deleting TLVs is the topic in
"https://trac.ietf.org/trac/6man/ticket/69", please look at that. Note
that the ticket is closed, but it's pretty obvious that this it is not
resolved and the text in the latest draft seemingly creates a loophole
to do this by defining a "SID type" for that purpose.

> I think it is a limitation to SRv6 that we should avoid it definitely.

Then it's also a general limitation in IPv6. For instance, IOAM is
useful networks that don't use segment routing. So if Adding/Deleting
TLVs is needed for SR TLVs then there's also needed for Hop-by-Hop
options. But, rather this is necessary and sufficient has yet to be
proven. There are two alternatives to adding TLVs: 1) Use IP
encapsulation which properly allows "EH insertion" in the outer header
since the encapsulator is sourcing an IPv6 packet 2) Use a mutable TLV
type (defined for HBH, DO, and SR options) that includes sufficient
scratch space for intermediate nodes to write their data.

Tom

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Mon, 27 May 2019 17:22:16 +0000

Hi Cheng, thanks for the support, I have a couple comments inline.

> On May 27, 2019, at 8:41 AM, Chengli (Cheng Li) <[email-masked]> wrote:
> 

draft-ali-6man-spring-srv6-oam-01 actually reserves TLV at an SR Source node for use by segment endpoint nodes, so it doesn’t change the size of TLVs (see 4.4.2.1 and 4.4.2.2 of that draft).

> All the use cases of inserting or deleting new TLV, or updating TLV with new length value are not allowed if Hdr Ext Len is not mutable. 

Use cases you’re thinking of should be able to use a method similar to that in draft-ali-6man-spring-srv6-oam, I would be interested to hear about them.

Thanks
  Darren

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Tue, 28 May 2019 12:55:30 +0000

Hi Joel, the SR Source knowing what SIDs it adds is the whole point.

see inline...

> On May 25, 2019, at 11:56 AM, Joel Halpern Direct <[email-masked]> wrote:
> 
> Darren, I do not understand how the source node knowing what it puts on is relevant.
> 
> Suppose we have a packet with an SRH.  And suppose that the SRH uses three different SID types.  And suppose that, per the mutability section of this document, those three SID types have different mutability permissions.
> 
> What does this mean for who is allowed to modify what fields in the SRH when?

SIDs modify what it is defined to modify.

>  the reason mutability matters is that affects both how earlier nodes understand what will be delivered and how later nodes understand the relationship between what they received and what was sent. Unfortunately, a later node may well not know the SID types of the various SIDs in the list, or how those interact with the mutability.

The SID in this document decrements segments left and puts the next segment in the DA, other SIDs may do more than that.  The point is that the SR source knows what each SID does and builds its segment list accordingly.

> 
> Arguably, one could go even further.  From lots of discussions, we expect that SID lists will be provided by control systems.  At that point, while the control system presumably knows what the SID types are and how they affect mutability, there is NOT reason to expect the initial node to understand the SID types, much less their effect on mutability.
> 

The location of the process that computes a segment list is not relevant Joel, it obviously doesn’t matter if I place a path computation algorithm on the same CPU or physical piece of hardware as the SR Source node or somewhere else.

> If we agree, as the chairs have said, taht we need to spell out the mutability, then we need to spell out the mutability.  If mutability depends upon the values in various entries in the SID list (what types of SIDs are used) then that mutability needsto be spelled out and explained how various constraints interact.

Mutability is fully defined for the SRH and the SID defined in this document.  Other SIDs will have other processing definitions, and it is up to the SR Source node to order those SIDs in a segment list to achieve whatever functionality it requires from the segment list.

> 
> Yes, any IETF document can add exceptions, with working group agreement when it approves such a document, to a requirement.  But putting into the document that the spec doesn't actually tell you what the constraints are does not answer the mutability constraint.
> 
> Also, given that tLVs are tied to the entire SRH, not just to a given SID, there seems to be something very strange in a SID type changing the mutability constraints on the TLVs.

The TLV section clearly states what TLV Types Variable Length Data can change en route and those that do not.  The text in 4.3.1 on TLVs simply reiterates the same.

Darren

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 28 May 2019 09:46:35 -0400

You seem to be mixing the notion of whether something is mutable with 
whether a particular entity will change it.  Those are not the same.

Mutability is a general concept, and allows any entity (source, 
destination, or intermediate, to know what may have been changed.  While 
the most obvious application is applying AH, it is not the only case.

As far as I can tell, what the current text amounts to saying is that in 
terms of potential mutability any field (including TLV content for tLVs 
with the immutable bit set) may be changed at some time.  Specific SIDs 
have specific rules as to what changes the node processing that SID can 
make.  That is NOT the same notion as what is mutable in the particular 
extension header.

If you want to allow that future SIDs may change any field, then in 
terms of what may be considered mutable in the abstract (for example, 
for a separate AH document, or for attributing fields in the header to 
sources) then you need to write the text as "the entire SRH header is 
mutable."

Yours,
Joel

---

From: Tom Herbert <[email-masked]>
Date: Tue, 28 May 2019 09:46:26 -0700

> sources) then you need to write the text as "the entire SRH header is
And, if that is the actual intent, then it needs to be justified how
it is robust, secure, and interoperable (for instance the concerns of
ticket #69 need to be addressed). I don't believe there's any
precendent in IETF protocols where intermediate nodes in a network
have been given a blank check to write whatever contents they want in
packets that are sourced by and attributed to hosts.

Tom

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Thu, 30 May 2019 11:28:25 +0000

Dear Chairs and the WG:

I have read the draft a multiple time and find it ready for the publication.

The draft has multiple deployments in commercial/ live networks. The draft has multiple interoperable implementations, including:

  *   Cisco: Multiple hardware platforms and 3 OS
  *   Linux: Kernal and srext module
  *   FD.io: VPP
  *   Huawei: Multiple hardware platforms
  *   Apps: Snort, iptables and nftables, tcpdump and Wireshark
  *   Iliad: NodeBox
  *   Barefoot: Tofino NPU

Please see https://www.ietf.org/internet-drafts/draft-matsushima-spring-srv6-deployment-status-01.txt for details.

In summary, I support the last call.

Thanks

Regards … Zafar

From: ipv6 <[email-masked]> on behalf of Bob Hinden <[email-masked]>
Date: Wednesday, May 22, 2019 at 9:40 AM
To: IPv6 List <[email-masked]>
Cc: Bob Hinden <[email-masked]>
Subject: 6man w.g. last call for <draft-ietf-6man-segment-routing-header-19.txt>

Hello,

as a Proposed Standard.

Thanks,
Bob & Ole

---

From: "Voyer, Daniel" <[email-masked]>
Date: Thu, 30 May 2019 12:13:45 +0000

Hi,

thanks
Dan

> On May 22, 2019, at 09:39, Bob Hinden <[email-masked]> wrote:
> 
> Hello,
> 
> ------------------------------------------------------------------------------
> External Email: Please use caution when opening links and attachments / Courriel externe: Soyez prudent avec les liens et documents joints
>