Shepherd writeup
rfc8227-06

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