Subject: I-D Action: draft-ietf-6man-segment-routing-header-13.txt

From: [email-masked]
Date: Wed, 23 May 2018 06:54:57 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IPv6 Maintenance WG of the IETF.

        Title           : IPv6 Segment Routing Header (SRH)
        Authors         : Stefano Previdi
                          Clarence Filsfils
                          John Leddy
                          Satoru Matsushima
                          Daniel Voyer
	Filename        : draft-ietf-6man-segment-routing-header-13.txt
	Pages           : 29
	Date            : 2018-05-23

Abstract:
   Segment Routing can be applied to the IPv6 data plane using a new
   type of Routing Extension Header.  This document describes the
   Segment Routing Extension Header and how it is used by Segment
   Routing capable nodes.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-6man-segment-routing-header/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-13
https://datatracker.ietf.org/doc/html/draft-ietf-6man-segment-routing-header-13

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-segment-routing-header-13

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Wed, 23 May 2018 15:05:13 +0000

Hello Working Group participants.

As per the guideline received from the 6man chairs before London, we have been improving the document in terms of focus, structure and clarity.

The first step accomplished with rev12 is now complemented with rev13.

- Simplify the introduction and avoid duplication by relying on the definition of key terms from the Segment Routing Architecture
- Define the SRH immediately following the introduction
- Define SR node roles
- Group packet processing into a single section
‑ END.X SRv6 SID is removed for definition in future document
- Group packet processing into a single section
- Added an illustrations section for example processing.
- The remaining sections were left relatively untouched, with some small edits for consistent terminology.

The authors believe this revision 13 gives us the right structure to tackle the remaining open issues in revision 14.

Thanks for your continued review, constructive feedback and help.

Darren and Clarence

On May 23, 2018, at 9:54 AM, [email-masked]<mailto:[email-masked]> wrote:

Abstract:

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

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 25 May 2018 09:06:00 +1200

> END.X SRv6 SID is removed for definition in future document

In general I think that essentially removing the SID function
details from this document is a good idea. However:

> 4.3.1.  FIB Entry Is Locally Instantiated SRv6 END SID
> 
>    This document, and section, defines a single SRv6 SID called END.

It's very unclear to me what that definition actually is.
The text describes how an END SID is processed, but not
how a node *knows* that an incoming SID is an END SID.
Is there some magic in the FIB? If so, who put that magic there?

Regards
   Brian

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Fri, 25 May 2018 18:50:46 +0000

> On May 24, 2018, at 5:06 PM, Brian E Carpenter <[email-masked]> wrote:
> 

Read the Segment Routing Architecture mentioned in the introduction.

Darren

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 26 May 2018 08:38:15 +1200

> Read the Segment Routing Architecture mentioned in the introduction.

Fair enough, but I think you need a few breadcrumbs in this draft.
It seems to me that you say that the document "defines" something
that is actually defined somewhere else. What you define is the 
processing of the END SID, not how to identify it. Since that is
explained in the other document, a cross-reference would help the
reader a lot.

(Using an address as a processing instruction is a strange enough
concept that most readers will need some assistance.)

Rgds
   Brian