Document Shepard Write up for draft-ietf-6man-segment-routing-header-21.txt
Bob Hinden
18 June 2019
(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
Standard, Informational, Experimental, or Historic)? Why is this the
proper type of RFC? Is this type of RFC indicated in the title page
header?
Proposed Standard.
Header indicates Standards Track.
(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:
Technical Summary:
Relevant content can frequently be found in the abstract and/or
introduction of the document. If not, this may be an indication that
there are deficiencies in the abstract or introduction.
Segment Routing is designed to be applied to the IPv6 data plane using
a new type of Routing Extension Header (SRH) in this document. This
document describes the Segment Routing Extension Header and how it is
used by Segment Routing capable nodes.
The Segment Routing Architecture [RFC8402] describes Segment Routing
and its instantiation in two data planes MPLS and IPv6. The encoding
of IPv6 segments in the Segment Routing Extension Header is defined in
this document.
Working Group Summary:
Was there anything in WG process that is worth noting? For example, was
there controversy about particular points or were there decisions where
the consensus was particularly rough?
The work on SRH has been underway for a long time. The first working
group version of the draft was published in December 2015, the first
working group call started on March 2018. Given the number of issues
that were raised the chairs started an issue tracker. Fifty issues
were tracked. After further discussion, many new drafts, and
confirmation at IETF 104, the chairs started a second working group
last call in May 2019. After further discussion two new drafts were
published and the chairs concluded the last call and declared that
there is consensus to advance this document on 14 June 2019. See:
https://mailarchive.ietf.org/arch/msg/ipv6/_9OrqvZYpDB0lJEE8jxB0a0N44M
The chairs believe there is a strong consensus to advance this
document, but it was not unanimous.
There remains a desire by a few people to add more clarity on
mutability of segment lists and other fields. The chairs conclusion
is that the text added since the last call closes this topic, but a
few would like to see more.
Document Quality:
Are there existing implementations of the protocol? Have a significant
number of vendors indicated their plan to implement the specification?
Are there any reviewers that merit special mention as having done a
thorough review, e.g., one that resulted in important changes or a
conclusion that the document had no substantive issues? If there was a
MIB Doctor, Media Type or other expert review, what was its course
(briefly)? In the case of a Media Type review, on what date was the
request posted?
Section 9 lists current implementations, these include:
Linux Kernel v4.14
Cisco Systems IOS XR and IOS XE
FD.io VPP/Segment Routing for IPv6
Barefoot Networks Tofino NPU
Detailed reviews were done in the course of review this document in
the 6man working group. Several people did extensive reviews, they
include Joel Halpern, Ron Bonica, Mark Smith, and Tom Herbert. The
6man chairs have also reviewed this document. These reviews resulted
in many improvements to the document.
No MIBs or other media types to be reviewed.
Personnel:
Who is the Document Shepherd? Who is the Responsible Area Director?
Bob Hinden is the Document Shepherd.
Suresh Krishnan is the Responsible AD.
(3) Briefly describe the review of this document that was performed by
the Document Shepherd. If this version of the document is not ready for
publication, please explain why the document is being forwarded to the
IESG.
The document shepherd reviewed the draft (actually 21 versions since
it became a w.g. draft), followed and participated in the discussion
on the mailing list and at 6man sessions. The chairs put a lot of
effort into determining where there was consensus on issues and in
several cases proposed text changes to resolve issues. This was
accepted pretty well by the working group and the authors.
The document shepherd believes this document is ready to be advanced
to the IESG.
(4) Does the Document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?
The shepherd has no concerns about the reviews done in 6man, any
issues remaining will require wider review as part of the next steps
in the process. SRH as part of the Spring architecture has broader
implications than just a routing protocol (that is, beyond the routing
area where the Spring w.g. Is located). The 6man review was very
thorough, but there are not many 6man working group participants that
are also Spring architecture experts.
(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that took
place.
The chairs think a thorough review by the security area for issues like
the HMAC, the use of AH with SRH, and the security of source routing in
general is warranted.
(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the IESG
should be aware of? For example, perhaps he or she is uncomfortable with
certain parts of the document, or has concerns whether there really is a
need for it. In any event, if the WG has discussed those issues and has
indicated that it still wishes to advance the document, detail those
concerns here.
This document has six authors, one over the limit. Much earlier,
there were about 12 authors, the chairs were able to have the authors
reduce it to five. We noticed later in the process, that Darren Dukes
who was clearly acting a document editor, was not listed as an author.
We asked him to add his name. The chairs think an exception is
reasonable in this case.
(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why?
All authors have confirmed this.
stefano@previdi.net Confirmed 16 June 2019
cfilsfil@cisco.com Confirmed 18 June 2018
ddukes@cisco.com Confirmed 17 June 2019
john@leddy.net Confirmed 17 June 2019
satoru.matsushima@g.softbank.co.jp Confirmed 17 June 2019
daniel.voyer@bell.ca Confirmed 17 June 2019
(8) Has an IPR disclosure been filed that references this document? If
so, summarize any WG discussion and conclusion regarding the IPR
disclosures.
There is one IPR disclosure from Cisco filed for an earlier draft, see:
https://datatracker.ietf.org/ipr/2421/
Summary is:
“If technology in this document is included in a standard adopted by
IETF and any claims of any Cisco patents are necessary for practicing
the standard, any party will have the right to use any such patent
claims under reasonable, non-discriminatory terms, with reciprocity,
to implement and fully comply with the standard.”
(9) How solid is the WG consensus behind this document? Does it represent
the strong concurrence of a few individuals, with others being silent, or
does the WG as a whole understand and agree with it?
The consensus is strong to advance. It is not unanimous however.
There has been a very active discussion on this document over a long
period of time, the current draft is significantly improved and the
chairs think the 6man working group would like to see it advanced.
(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)
No appeals threatened.
(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.
ID nits of the current draft is good.
(12) Describe how the document meets any required formal review criteria,
such as the MIB Doctor, media type, and URI type reviews.
N/A
(13) Have all references within this document been identified as either
normative or informative?
Yes.
(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?
All Normative reference point to published RFCs.
(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in the
Last Call procedure.
All Normative reference point to published RFCs.
(16) Will publication of this document change the status of any existing
RFCs? Are those RFCs listed on the title page header, listed in the
abstract, and discussed in the introduction? If the RFCs are not listed
in the Abstract and Introduction, explain why, and point to the part of
the document where the relationship of this document to the other RFCs is
discussed. If this information is not in the document, explain why the WG
considers it unnecessary.
This document does not change the status of any existing RFC.
(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA
registries. Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a detailed
specification of the initial contents for the registry, that allocations
procedures for future registrations are defined, and a reasonable name
for the new registry has been suggested (see RFC 8126).
The Document Shepherd reviewed the IANA considerations section and
thinks the text in the current version is good. Earlier, changes were
requested, these are in the current version.
(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find useful
in selecting the IANA Experts for these new registries.
This is described in Section 8. “IANA Considerations” in detail.
(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.
N/A