The MPLS Working Group requests that
Shared-Ring protection (MSRP) mechanism for ring topology
draft-ietf-mpls-tp-shared-ring-protection-04
be published as a Standards Track RFC.
(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?
This Document should be published as a Standards Track RFC.
The document defines new protocol so Proposed Standard is the right RFC type.
This is clearly indicated on the title page.
(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.
Technical Summary
This document describes requirements, architecture and solutions for MPLS-TP
Shared Ring Protection (MSRP) in a ring topology for point-to-point (P2P)
services.
The MSRP mechanism is described to meet the ring protection requirements as
described in RFC 5654. This document defines the Ring Protection Switch
(RPS)
Protocol to be used for coordinating protection behavior of nodes on MPLS
ring.
As described in RFC 5654, MPLS-TP requirements, several service providers
have
expressed interest in operating MPLS-TP in ring topologies and require a
high-
level survivability function in these topologies. In operational transport
network
deployment, MPLS-TP networks are often constructed using ring topologies.
This
calls for an efficient and optimized ring protection mechanism to achieve
simple
operation and fast, sub 50 millisecond, recovery performance.
This document specifies an MPLS-TP Shared-Ring Protection mechanisms that
meets the criteria for ring protection and the ring protection requirements
described in section 2.5.6.1 of RFC 5654.
The basic concept and architecture of the Shared-Ring protection mechanism
are
specified in this document. This document also describes the solutions for
point-
to-point transport paths.
While the basic concept may also apply to point-to-multipoint transport
paths, the
solution for point-to-multipoint transport paths is out of the scope of this
document.
Working Group Summary
This document was first posted as an individual draft in October of 2012
(then
draft-cheng-mpls-tp-shared-ring-protection-00). Five additional versions
were
subsequently posted until version 6 (posted in August, 2015) was adopted by
the MPLS working group, becoming
draft-ietf-mpls-tp-shared-ring-protection-00,
in October of 2015.
Discussion of this draft has been very light since its adoption, owing to
the fact
that interest in this work has been fairly bi-polar (interested people
tended to
be very interested, contributing substantively to the document and therefore
becoming either authors or substantive contributors).
However, the document was thoroughly reviewed by at least five non-authors
and there were no objections or controversies once it was adopted by the
working group.
Support for the document in the working group is somewhat divided with a
fair number strongly supporting it and remaining participants not objecting to
it. Progression in the working group since its adoption has been smooth.
Document Quality
There is at least one implementation. We have started an implementation
poll and will update the Write-Up once we have further information.
The review of the document has been both good, and thorough. In addition to
review by the authors and contributors through 10 revisions, the draft has
been
reviewed by five non-authors, including the document shepherd.
The draft has been forwarded to ITU-T SG15 for review on several occasions (a
number of the authors and contributors are, or have been, active in SG15).
No
recent comments have been received (most ITU comments were handled prior
to adopting the draft as an MPLS Working Group Draft).
No further specialist reviews are necessary.
Personnel
Eric Gray is the Document Shepherd.
Deborah Brungard 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 has been involved in background discussion about this
document for several years, and reviewed the document thoroughly.
(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?
The Document Shepherd has no such concerns.
(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.
No further specialist reviews are necessary.
(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.
There are no such issues or concerns.
(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 and listed contributors have stated on the working group mailing
list either that they were unaware of any IPR that relates to this document,
or that the IPR they are aware of is subject to IPR disclosure listed at:
https://datatracker.ietf.org/ipr/2680/https://datatracker.ietf.org/ipr/2681/https://datatracker.ietf.org/ipr/2681/https://datatracker.ietf.org/ipr/2683/
(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.
There are four IPR disclosures filed against this document, at:
https://datatracker.ietf.org/ipr/2680/https://datatracker.ietf.org/ipr/2681/https://datatracker.ietf.org/ipr/2681/https://datatracker.ietf.org/ipr/2683/
This was pointed out to the working group when we polled the draft to see if
we had consensus to accept it as a working group document, and later while
the document was being review during WG Last Call.
The disclosure did not generate any discussion in the working group, after it
was adopted.
(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?
Support for this document is reasonably good.
(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarize 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.)
We are not aware of any such threats.
(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.
There are editorial NITs shown via idnits at:
https://tools.ietf.org/idnits?url=https://tools.ietf.org/id/draft-ietf-mpls-tp-shared-ring-protection-04.txt
The “copyright year” discrepancy is an artifact of the latest version having
been posted last year.
There is also a “Missed Reference” warning that is an artifact of the
“Notation” used (as defined in section 2).
IdNits calls out line 335, but the notation [LSP1] occurs very many times in
the document.
“Weird Spacing” warnings are specious.
The draft is otherwise NIT-free.
(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.
No such reviews were required.
(13) Have all references within this document been identified as
either normative or informative?
Yes - the references have been correctly split into normative and
informative references.
(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 references (both Normative and Informative) are to existing RFCs.
(15) Are there downward normative references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.
There are no downward references.
(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.
Publication of this document will not change the status of any other RFCs.
(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 5226).
The Document Shepherd review of the IANA Considerations section led to
comments about the authors wording choices (the section includes IANA
considerations, it does not summarize them). Those comments have been
addressed.
The IANA Considerations (section 6) is relatively simple; it includes two
subsections 6.1 and 6.2.
6.1 requests an IANA allocation of a code point from the “PW Associated
Channel Type” registry (defined by RFC 4446).
6.2 requests IANA to establish a new sub-registry under the
“Multiprotocol Label Switching (MPLS) Operations, Administration, and
Management (OAM) Parameters”
registry – to be called “MPLS RPS Request Code Registry” and provides an
initial allocation (requested) for 13 values (0-6, 11-15 and 255). The rest
of the range (7-10 and 16-254) are unassigned and shall be allocated by
“Standards Action.”
(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.
The one new (sub) registry specifies allocation via “Standards Action.”
There are no other new IANA registries, so no new experts needed.
(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.
No such automated reviews were applicable or necessary.