Shepherd writeup
rfc8986-28

Below is the earlier Shepherd writeup from Bruno Decraene.  The following updates are added by Joel Halpern.

The document authors have responded to the IESG Appeal report. 
 They have added examples of the SID values and usage.  This includes clarifying the meaning of the FUNC and LOC bits, as well as demonstrating some of the alternatives in the number of bits are needed or can be used for the SID prefix.
They have clarified the relationship of the SIDs defined here with the SDI defined in RFC 8754, to address concerns from the Internet ADs.
They have elaborated the description of PSP, including providing better description of some of the value of having the flavor available.

While this shepherd expects there to be objections raised during IETF last call, the document still has the same technical content as it had during the judgement of WG rough consensus, and the IESG report explicitly indicated that a new WG LC was not called for. 

 Joel M. Halpern

(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? 

Standard Track is requested and indicated in the title page header.
This is appropriate for a specification of data plane processing needing interoperability between the ingress/source and the egress/destination. The specific forwarding behaviors (aka SR Endpoint behaviors) also need to be advertised in control plane protocols.


(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:

   Segment Routing [RFC8402] leverages the source routing paradigm.  An
   ingress node steers a packet through an ordered list of instructions,
   called segments.  Each one of these instructions represents a
   function to be called at a specific location in the network.  A
   function is locally defined on the node where it is executed and may
   range from simply moving forward in the segment list to any complex
   user-defined behavior.  Network programming combines segment routing
   functions, both simple and complex, to achieve a networking objective
   that goes beyond mere packet routing.

   This document defines the SRv6 Network Programming concept and
   specifies the main segment routing behaviors to enable the creation
   of interoperable overlays with underlay optimization (Service Level
   Agreement).

Working Group Summary:

This document is a foundation for SRv6. It has been largely reviewed, commented and supported.
There is a strong controversy regarding the Penultimate Segment Pop (PSP) flavor which allows an IPv6 source node to instruct the penultimate SRv6 EndPoint (identified, in the IPv6 header, by its IPv6 address) to remove the SRH from the IPv6 packet before the packet reach the final IPv6 destination (the Ultimate SRv6 EndPoint). The consensus to keep that section was particularly rough.

Document Quality:

The specification has multiple implementations, deployments and interop tests.
In particular: 
- There are multiple hardware and software implementations. Some are reported in https://tools.ietf.org/html/draft-matsushima-spring-srv6-deployment-status-06#section-4
- There are multiple deployments. Some are reported in https://tools.ietf.org/html/draft-matsushima-spring-srv6-deployment-status-06#section-2
- There have been multiple public interoperability tests https://tools.ietf.org/html/draft-matsushima-spring-srv6-deployment-status-06#section-5

Personnel:

The Document Shepherd is Bruno Decraene
The Responsible Area Director is Martin Vigoureux.

(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 whole document has been reviewed before and after the WGLC. Comments sent and addressed by the editor.
The whole WGLC thread has been reviewed (about 424 emails according to the mailarchive)

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? 

No.
The WGLC has been sent to two WGs: SPRING & 6MAN.
There has been a lot of reviews and comments from both 6MAN & SPRING contributors.


(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 document uses the IPv6 SRH routing header. The Working Group Last Call has been copied to the 6MAN WG and the document has been reviewed and commented by 6MAN participants.

(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.

On a personnel side, I'm chair and listed as a co-author of the document, among 23 contributors and 6 authors. The reason for taking the shepherd role is that there was no other available co-chair and 29 persons are either contributors or authors which remove a lot of persons. Finally the WGLC was expected to be difficult on the 6MAN side given the SRv6 history and the WGLC on the SRH specification. So there was both a smaller pool of experienced SPRING shepherd and less candidates for the work with a difficult document.

On a technical side, the section "4.16.1 PSP: Penultimate Segment Pop of the SRH" has generated a lot of controversy from some 6MAN participants.

 6.0 Introduction

  The section 4.16.1 proposes that the Segment Routing Penultimate Endpoint, which receives the IPv6 packet since its IPv6 address is in the IPv6 header destination address, be instructed by the IPv6 source node to remove the SRH (routing header) as/when the SRH is not further useful (Segment Left will be zero when received by the Segment Routing Ultimate Endpoint).

 6.1 Concern 1 (violation of RFC 8200)
 
  The first concern is whether this behavior [1] violates RFC 8200 [2].

  More specifically
   " S14.4.      Remove the SRH from the IPv6 extension header chain" in [1]
  Vs
    "   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 [2]

  On this text, what is been discussed is "the node (or each of the set of nodes, in the case of multicast) identified in the Destination Address field of the IPv6 header."
  More specifically whether "Destination Address field of the IPv6 header" means the "final Destination Address" or the "Destination Address" as seen in the packet that the node received.

[1] https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming#section-4.16.1
[2] https://tools.ietf.org/html/rfc8200#section-4

 6.2 Concern 2 (letter vs spirit of RFC 8200)
 
  The second concern is whether the text in the section 4 of RFC 8200 really says what was meant.
  Two erratas have been submitted : https://www.rfc-editor.org/errata/eid5933 https://www.rfc-editor.org/errata/eid6003
  
  The responsible AD (Suresh) classified the first errata as "Held for Document Update" with the below note: 
   "Some people might interpret the text in RFC8200 to mean the replacement text provided above in the erratum but others might read the text exactly as written ("until the packet reaches the node identified in the Destination Address field of the IPv6 header”). Given that the text in RFC8200 had consensus and it is impossible to tell after the fact if the proposed replacement text would have achieved consensus, I believe this erratum falls under the above category.

  The change proposed by this erratum has to be evaluated for correctness and consensus if and when there is an update of RFC8200."
  [3] https://mailarchive.ietf.org/arch/msg/ipv6/tRn94-NlupHLcWdzo7O9BfHpiik/
  [4] https://mailarchive.ietf.org/arch/msg/ipv6/yVKxBF3VnJQkIRuM8lgWN4_G3-o/
  
 6.3 Concern 3 (technical issues with SRH removal)
 
  Two points have been raised regarding PMTUD and Authentication Header. The first one has been dismissed and the second is already called out of scope of SRH.
  
  It's also worth noted that with Segment Routing, the removal of the SRH is performed by the SR penultimate EndPoint at the _explicit_ request/instruction of the source node. Hence the final destination node receives the IP packet exactly as meant by the IP source node: there is no surprise/unexpected change from both the IP source and the final IP destination point of view.
   
   
 6.4 Shepherd opinion
  Regarding concern 1, based on comments received during the last call and my reading of the section 4 of RFC 8200, section 4 of RFC 8200 does seem to allow SRH removal by a node receiving an IPv6 packet with an IPv6 destination address identifying itself.
  Regarding concern 2, cf Suresh's note [3] [4]. Going beyond is probably up to IESG and/or the 6MAN WG in a longer term.
  Regarding concern 3, SRH removal does not create new technical issue.

  In summary, although the controversy was very significant with very strong opinions expressed, up to statements that appeal(s) will be made, from a SPRING WGLC standpoint, I don't believe that there is ground to block the progression of this draft toward the IESG. Quite the contrary, I think that the IESG should make the call by themselves with regards to concern 1 and 2, especially since the IESG had approved the document been debated (RFC 8200, in particular section 4.1.16).


(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?

Each author has replied to the IPR call on the mailing list.
Each contributor _except Gaurav Naik and  Milad Sharif_ has replied to the IPR call on the mailing list. Those two contributors (out of 23) could not be reached. Note that both had replied (no IPR) during the call for _adoption_.


(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. 

One IPR disclosure has been filed.
No WG discussion on this IPR.


(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? 

This document has been largely reviewed and received a large support, both from vendors and network operators. It has multiple implementations and deployments.
This document is a foundation of the SRv6 specification.

(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.) 

A few persons threatened for an appeal and I believe that such appeal is likely.
The strong controversy is related to section 4.16.1.  "PSP: Penultimate Segment Pop of the SRH" and whether it violates RFC 8200 (IPv6 specification) section 4.1.16.
Cf question "6" for more details.

(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. 

The document has 6 authors, beyond the 5 authors limit. An exception is requested given the significant work on this document: significant scope, importance (basis of SRv6), with multiple implementations and deployments.

Idnits has been run and error corrected.
Internet-Drafts Checklist done.
Shepherd has reviewed the draft and made comments. Those have been addressed by the editor.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. 

The document has no MIB, Yang model, media type or URI type.


(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?

No.


(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.

No.


(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. 

No.


(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). 

I confirm the points.
The largest part of the IANA section are the codepoints associated with SR EndPoints behaviors. In the document, the behaviors are referred to by "user friendly" names (e.g., End, End.X). The codepoints themselves are only defined in the IANA section, hence there is no risk of inconsistency between the body of the document and the IANA section. Given the number of codepoints, I think that this is better, especially since the codepoints are not used in this document but will be used by future documents (e.g. control planes extension).

(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. 

None.


(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, YANG modules, etc.

The document has not sections written in formal language.


(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

The document has no YANG module.
Back