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/eid5933https://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.