Subject: draft-ietf-6man-segment-routing-header-17

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Mon, 25 Mar 2019 08:37:01 +0000

I’ve had issues publishing this version of the draft (some stale state is on the submission tool is blocking the upload of the xml).  I’ve provided a temporary link to view until that issue is resolved.
https://drive.google.com/file/d/10zVfrYFebbheEhRJaa1HSlV8uPP9zEyZ/view?usp=sharing

Changes in this version include...

Network Programming: Remove reference
TLV processing limits: When length of TLVs exceeding hdr ext len, say what to do
Pad TLV: Minor description updates
HMAC: Cover destination address matching first segment
Extension header processing order: Process in the order received
Flow label/ECMP: Set for intra-domain and inter-domain packets

Thanks
  Darren

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 25 Mar 2019 09:55:06 +0100

Darren, there are a number of subtle interactions and lack of clarity 
regarding the processing of different kinds of extension headers in 
order that have been pointed out.  You say below that you have clarified 
this.  I hope so, but looking at the google docs link, it appears taht 
many of the ambiguities remain.

Yours,
Joel

On 3/25/19 9:37 AM, Darren Dukes (ddukes) wrote:
> I’ve had issues publishing this version of the draft (some stale state 
> is on the submission tool is blocking the upload of the xml).  I’ve 
> provided a temporary link to view until that issue is resolved.
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: "Voyer, Daniel" <[email-masked]>
Date: Mon, 25 Mar 2019 09:03:57 +0000

Hi Joel,

Can you be more specific about the "many of the ambiguities remain" ? Can you highlight the text and if it requires adjust it will be clearer.

Thanks
dan

On 2019-03-25, 9:55 AM, "ipv6 on behalf of Joel M. Halpern" <[email-masked] on behalf of [email-masked]> wrote:

    Yours,
    Joel

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 25 Mar 2019 09:15:26 -0000

Thanks Darren,

And I see you have now resolved the posting issues.

I really appreciate the (sudden ;-) effort to advance this draft. And, obviously, IETF week is a great time to get discussions to resolve open issues. However, it is also pretty tough refreshing context and following the discussions when there is so much else going on.

I wanted to raise one point that I also raised in SPRING during the adoption call for draft-filsfils-spring-srv6-network-programming. My concern was that that latter draft makes clear that the value that can be placed in the DA field is routable, but goes beyond the definition in 4291 and 8200…

RFC 4291 has…

   IPv6 addresses are 128-bit identifiers for interfaces and sets of

   interfaces (where "interface" is as defined in Section 2 of [IPV6]).

And RFC 8200 has…

      interface    a node's attachment to a link.

and

      Destination Address 128-bit address of the intended recipient of

                          the packet (possibly not the ultimate

                          recipient, if a Routing header is present).

                          See [RFC4291] and Section 4.4.

The response I got to my comment in SPRING was “The draft-6man-segment-routing-header has already defined the processing of a segment.  And this document, as it evolves as a WG document, should follow that processing.“

I think that is true, but not necessarily the full story. I see that the SRH document tells us how to copy from a SID list to the DA field. I see that the definition of a segment is largely achieved by reference (which is good). I do not believe that we have clearly exposed to 6man the intention to place in the DA field something that is not simply an identifier of an interface. In fact, the SRH draft uses the term “IPv6 address” quite freely and might lead to confusion for people who are familiar with 4291.

As I said in SPRING, I don’t take a position on whether this is the right or wrong thing to do, but perhaps a way forward would be to add a line of text to the SRH document to make it abundantly clear that the processing o the SRH means that the value placed in the DA field may end up being different from what 4291 and 8200 imply. With that change we would be clear that we have consensus to do this and could move forward smoothly.

Thanks,

Adrian

From: ipv6 <[email-masked]> On Behalf Of Darren Dukes (ddukes)
Sent: 25 March 2019 08:37
To: [email-masked]
Subject: draft-ietf-6man-segment-routing-header-17

 

Thanks

  Darren