Skip to main content

MPLS-TP Shared-Ring Protection (MSRP) Mechanism for Ring Topology
draft-ietf-mpls-tp-shared-ring-protection-06

Revision differences

Document history

Date Rev. By Action
2017-08-28
06 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2017-08-21
06 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2017-08-18
06 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2017-07-24
06 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2017-07-21
06 (System) IANA Action state changed to Waiting on RFC Editor from Waiting on Authors
2017-07-21
06 (System) IANA Action state changed to Waiting on Authors from In Progress
2017-07-20
06 (System) IANA Action state changed to In Progress from Waiting on WGC
2017-07-20
06 (System) IANA Action state changed to Waiting on WGC from In Progress
2017-07-20
06 (System) IANA Action state changed to In Progress from Waiting on WGC
2017-07-10
06 (System) IANA Action state changed to Waiting on WGC
2017-07-10
06 (System) RFC Editor state changed to EDIT
2017-07-10
06 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2017-07-10
06 (System) Announcement was received by RFC Editor
2017-07-10
06 Cindy Morgan IESG state changed to Approved-announcement sent from IESG Evaluation::AD Followup
2017-07-10
06 Cindy Morgan IESG has approved the document
2017-07-10
06 Cindy Morgan Closed "Approve" ballot
2017-07-10
06 Cindy Morgan Ballot writeup was changed
2017-07-05
06 Eric Rescorla [Ballot Position Update] Position for Eric Rescorla has been changed to No Objection from Discuss
2017-06-29
06 Deborah Brungard Ballot approval text was changed
2017-06-20
06 Spencer Dawkins [Ballot comment]
Thanks for working through my Discuss.
2017-06-20
06 Spencer Dawkins [Ballot Position Update] Position for Spencer Dawkins has been changed to No Objection from Discuss
2017-06-12
06 (System) Sub state has been changed to AD Followup from Revised ID Needed
2017-06-12
06 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2017-06-12
06 Weiqiang Cheng New version available: draft-ietf-mpls-tp-shared-ring-protection-06.txt
2017-06-12
06 (System) New version approved
2017-06-12
06 (System) Request for posting confirmation emailed to previous authors: Jie Dong , Huub van Helvoort , Weiqiang Cheng , Lei Wang , Han Li
2017-06-12
06 Weiqiang Cheng Uploaded new revision
2017-05-30
05 Gunter Van de Velde Closed request for Last Call review by OPSDIR with state 'No Response'
2017-05-25
05 Cindy Morgan IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation
2017-05-24
05 Terry Manderson [Ballot Position Update] New position, No Objection, has been recorded for Terry Manderson
2017-05-24
05 Spencer Dawkins
[Ballot discuss]
I want to thank the authors for a very readable draft. It was a pleasure to review, and that's a high bar for …
[Ballot discuss]
I want to thank the authors for a very readable draft. It was a pleasure to review, and that's a high bar for the subject.

I have loads of questions, but my first set of questions is an expansion of Alvaro's comment that I think rises to the level of a Discuss. Please note that I'm asking questions, not proposing text changes, so I really do want to discuss it.

---------- my first set of questions

In this text,

  Three typical ring protection mechanisms are described in this
  section: wrapping, short wrapping and steering.  All nodes on the
  same ring MUST use the same protection mechanism.

I would like to understand what happens if they aren't - and I'm asking, mostly as a way of encouraging guidance for operators in debugging cases where they're not all using the same mechanism. I'm not asking for a full mesh of possible misconfigurations, only for a sentence or two ("If they aren't all using the same protection mechanism, the following things may happen").

More broadly, I'd like to understand why wrapping and short wrapping are both defined. It seems like the only functional difference is that short wrapping doesn't give you as much latency. Is that right?

24 pages in, I see this:

  o  In rings utilizing the wrapping protection, each node detects the
      failure or receives the RPS request as the destination node MUST
      perform the switch from/to the working ring tunnels to/from the
      protection ring tunnels if it has no higher priority active RPS
      request.

  o  In rings utilizing the short wrapping protection, each node
      detects the failure or receives the RPS request as the destination
      node MUST perform the switch only from the working ring tunnels to
      the protection ring tunnels.

so I'm pretty sure there are differences beyond what I was seeing, earlier in the document.

And, of course, I'm not sure what the effect of choosing steering over wrapping/short wrapping would be, for my users, but that can wait until we talk about wrapping and short wrapping ...

At a minimum, I'd like to see guidance for operators in choosing among the three protection mechanisms. Why would they choose any one of the three?

I also note that this MUST seems to be repeated using different words in section 5.1, as

  All nodes in the same ring MUST use the same protection mechanism,
  Wrapping, steering or short-wrapping.

If that's saying the same thing, one MUST is all you need.
2017-05-24
05 Spencer Dawkins
[Ballot comment]
---------- all the other questions

In this text,

  When the service LSP passes through the interconnected rings, the
  direction of the …
[Ballot comment]
---------- all the other questions

In this text,

  When the service LSP passes through the interconnected rings, the
  direction of the working ring tunnels used on both rings SHOULD be
  the same.  For example, if the service LSP uses the clockwise working
  ring tunnel on Ring1, when the service LSP leaves Ring1 and enters
  Ring2, the working ring tunnel used on Ring2 SHOULD also follow the
  clockwise direction.

I'm not understanding why this is a SHOULD, and not a MUST. If the direction of the working ring tunnels used on both rings is not the same, does this still work?

If it still works, why does this matter? But, either way, you might usefully say something about why this isn't always the right thing to do, even if you just give one example. The point of SHOULD is that implementers make their own informed decisions, so providing information that will inform those decisions seems important.

I wanted to call out

  Ring switches MUST be preempted by higher priority RPS requests.  For
  example, consider a protection switch that is active due to a manual
  switch request on the given link, and another protection switch is
  required due to a failure on another link.  Then an RPS request MUST
  be generated, the former protection switch MUST be dropped, and the
  latter protection switch established.

  MSRP mechanism SHOULD support multiple protection switches in the
  ring, resulting in the ring being segmented into two or more separate
  segments.  This may happen when several RPS requests of the same
  priority exist in the ring due to multiple failures or external
  switch commands.

as really good examples of the kind of text I think would help the places in this document ("For example", "This may happen when") where no examples are given. Thanks for providing those examples!

Ouch. Do I understand from

  o  Protection Switching Mode (M): This 2-bit field indicates the
      protection switching mode used by the sending node of the RPS
      message.  This can be used to check that the ring nodes on the
      same ring use the same protection switching mechanism.  The
      defined values of the M field are listed as below:

            +------------------+-----------------------------+
            |  Bits (MSB-LSB)  |  Protecton Switching Mode  |
            +------------------+-----------------------------+
            |      0 0        |        Reserved            |
            |      0 1        |        Wrapping            |
            |      1 0        |      Short Wrapping        |
            |      1 1        |        Steering            |
            +------------------+-----------------------------+

that you already have three protection mechanisms, and have only one possible codepoint to allocate for any future optimizations? Assuming that "0 0" can be unReserved ...

Could you clarify what "anyway" means in this text?

  When multiple MS RPS requests exist at the same time addressing
  different links and there is no higher priority request on the ring,
  no switch SHOULD be executed and existing switches MUST be dropped.
  The nodes MUST signal, anyway, the MS RPS request code.

I'm seeing that the commands like LP described in section 5.2.1.1  are used in the document before these (I'm serious) helpful and clear explanations appear. If it's possible to move section 5.2.1.1 up in the document, that would be great, but if it isn't possible, a forward pointer would be helpful to readers who don't already know what the command abbreviations mean.

I'm really confused by this SHOULD:

  The PSC protocol [RFC6378] is designed for point-to-point LSPs, on
  which the protection switching can only be performed on one or both
  of the end points of the LSP.  The RPS protocol is designed for ring
  tunnels, which consist of multiple ring nodes, and the failure could
  happen on any segment of the ring, thus RPS SHOULD be capable of
  identifying and handling the different failures on the ring, and
  coordinating the protection switching behavior of all the nodes on
  the ring.

I suspect that's because it's not a 2119 SHOULD, but if people think it is, I wouldn't mind understanding why.

Section 5.3, "RPS and PSC Comparison on Ring Topology" is really helpful, but it appears 43 pages in. Given that I'd expect people to be asking why they should implement a new protection switching protocol when they've already implemented PSC, I'd think this would be much more useful, early in the document.

I'm somewhat confused about the code point allocation strategy in this text:

  The RPS Request Field is 8 bits, the allocated values are as follows:

      Value      Description              Reference
      -------  --------------------------- ---------------
        0    No Request (NR)            this document
        1    Reverse Request (RR)        this document
        2    unassigned
        3    Exercise (EXER)            this document
        4    unassigned
        5    Wait-To-Restore (WTR)      this document
        6    Manual Switch (MS)          this document
        7-10  unassigned
        11    Signal Fail (SF)            this document
        12    unassigned
        13    Forced Switch (FS)          this document
        14    unassigned
        15    Lockout of Protection (LP)  this document
      16-254  unassigned
        255    Reserved

My first question is, why the highest priority RPS value is 15, given that the field is 8 bits wide. If anyone ever needs to add a code point higher than the highest priority code point, will that work well? I can imagine code that says "if operation_priority is greater than highest_priority, it's an error", for example.

I may have other questions depending on your answer, but let's start there.
2017-05-24
05 Spencer Dawkins [Ballot Position Update] New position, Discuss, has been recorded for Spencer Dawkins
2017-05-24
05 Alia Atlas [Ballot Position Update] New position, No Objection, has been recorded for Alia Atlas
2017-05-24
05 Alissa Cooper [Ballot comment]
I'd like to see the discussion with gen-art reviewer conclude and the associated changes folded into the next version of the document.
2017-05-24
05 Alissa Cooper [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper
2017-05-24
05 Alvaro Retana
[Ballot comment]
This document describes 3 different protection mechanisms and it specifies that all nodes "MUST use the same protection mechanism".  When should these mechanisms …
[Ballot comment]
This document describes 3 different protection mechanisms and it specifies that all nodes "MUST use the same protection mechanism".  When should these mechanisms be used?  What are the conditions that an operator should take into account when selecting between them?  I would like to see operational considerations explained.
2017-05-24
05 Alvaro Retana [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana
2017-05-24
05 Mirja Kühlewind
[Ballot comment]
Two technical comments that I think are important to address but do not warrant a discuss:

1) section 5.2: "As shown in Figure …
[Ballot comment]
Two technical comments that I think are important to address but do not warrant a discuss:

1) section 5.2: "As shown in Figure 14, when no protection switching is active on the
  ring, each node MUST send RPS requests with No Request (NR) to its
  two adjacent nodes periodically."
What does periodically mean here? Can you maybe give a number or even a normative statement like "and MUST NOT send more often than every X seconds" to avoid unnecessary congestion...?

2) section 5.1.1: "A ring node which is not the
  destination of the received RPS message MUST forward it to the next
  node along the ring immediately."
Why would you forward these? I thought you only send messages to your neighbors? Maybe I missed this but is there a use case for this scenario? Otherwise it might be safer to not forward to avoid that messages with a wrong destination node ID circle around forever. If you forward maybe you also need a hop-count to decrease or at least say that messages that are received and have the own node ID as source node ID MUST be dropped...?

Further, as mentioned by Ben for a couple of case, some of the uses of normative language in section 5 seems not to be appropriate as they don't specify a concrete implementation action. Please check carefully and change some to lower case instead, e.g.
"The MSRP protection operation MUST be controlled with the help of the
  Ring Protection Switch protocol (RPS). "
"The RPS protocol MUST carry the ring status information and RPS
  requests,.." (this sounds like a requirement on the protocol design but when you implement the protocol as specified there is no way to not do it, so this MUST is unnecessary)
"Each node on the ring MUST be uniquely identified by assigning it a
  node ID." (also requirement-like; the MUST in the next sentence is the important one)
"When a node detects a failure and determines
  that protection switching is required, it MUST send the appropriate
  RPS request in both directions to the destination node."
"MSRP mechanism SHOULD support multiple protection switches in the
  ring, resulting in the ring being segmented into two or more separate
  segments. "
"The first three RPS protocol messages carrying new RPS request SHOULD
  be transmitted as fast as possible." (Again the later SHOULD is the more important one)
There may be more…
2017-05-24
05 Mirja Kühlewind [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind
2017-05-23
05 Eric Rescorla
[Ballot discuss]
The security considerations of this document seem unacceptably
incomplete, as they basically just point to other documents.

  The RPS protocol defined in …
[Ballot discuss]
The security considerations of this document seem unacceptably
incomplete, as they basically just point to other documents.

  The RPS protocol defined in this document is carried in the G-ACh
  [RFC5586], which is a generalization of the Associated Channel
  defined in [RFC4385].  The security considerations specified in these
  documents apply to the proposed RPS mechanism.

The security considerations of those documents don't seem that great
either. However, I believe that they miss a new security issue raised
by the mechanism in this draft, which is that a member of the ring
appears to be able to forge reports of errors at other parts of the
ring. Specifically, S 5.1.3.3 says:

  When a node is in a pass-through state, it MUST transfer the received
  RPS Request in the same direction.

  When a node is in a pass-through state, it MUST enable the traffic
  flow on protection ring tunnels in both directions.

This seems not to involve any filtering, which suggests that node B
can send a forged SF from C->D and from D->C, which at least potentially
temporarily breaks the link there, causing traffic diversion.

More generally, this system assumes that every node trusts every
other node completely. That must at least be stated.

Incidentally, the text above appears to contain a bug in that it
doesn't talk about processing incoming RPS requests intended for
the receiving node, but I may just have missed the section where
it says that.
2017-05-23
05 Eric Rescorla
[Ballot comment]
S 4.1.1.
  protect these LSPs that traverse the ring, a clockwise working ring
  tunnel (RcW_D) via E->F->A->B->C->D, and its anticlockwise protection …
[Ballot comment]
S 4.1.1.
  protect these LSPs that traverse the ring, a clockwise working ring
  tunnel (RcW_D) via E->F->A->B->C->D, and its anticlockwise protection
  ring tunnel (RaP_D) via D->C->B->A->F->E->D are established, Also, an
  anti-clockwise working ring tunnel (RaW_D) via C->B->A->F->E->D, and
  its clockwise protection ring tunnel (RcP_D) via D->E->F->A->B->C->D

Why does the protection tunnel include D on both ends whereas the working
tunnel does not?


S 4.2.
  packets are periodically exchanged between each pair of MEPs to
  monitor the link health.  Three consecutive lost CC packets will be
  interpreted as a link failure.

Is this a normative statement (i.e., does it need a MUST).


S 4.3.2.1.
Why do you ever not use short wrapping?


S 5.1.4.1
  A node MUST revert from pass-through state to the idle state when it
  detects NR codes incoming from both directions.  Both directions
  revert simultaneously from the pass-through state to the idle state.

incoming within what time frame?
2017-05-23
05 Eric Rescorla [Ballot Position Update] New position, Discuss, has been recorded for Eric Rescorla
2017-05-23
05 Suresh Krishnan [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan
2017-05-23
05 Ben Campbell
[Ballot comment]
Substantive:

- The abbreviation "MSRP" is already used by RFC 4975.  Please avoid overloading it if at all possible. (And you probably …
[Ballot comment]
Substantive:

- The abbreviation "MSRP" is already used by RFC 4975.  Please avoid overloading it if at all possible. (And you probably want to collide with "Manufacturer's Suggested Retail Price" even less.)

-4.4.2: "When the service LSP passes through the interconnected rings, the
  direction of the working ring tunnels used on both rings SHOULD be
  the same. "
Would it ever make sense for the directions to be different? (That is, why not MUST?) If so, a few words about that would be helpful.

-5.1, 3rd bullet: "Determination of the affected
      traffic SHOULD be performed by examining the RPS requests
      (indicating the nodes adjacent to the failure or failures) and the
      stored ring map (indicating the relative position of the failure
      and the added traffic destined towards that failure)."

Would it ever make sense to violate that SHOULD? (That is, why not MUST?)

-6.2: Why "standards action"? That's a high bar. Are there reasons why a lower bar like "specification required" would not be appropriate? For example, are we in danger of running out of code points? Is this registry at unusual risk for poor quality registrations?

Editorial:

-3: Is this section expected to be useful to implementors? It reads more like evidence to the WG that this meets the requirements. I suspect people won't much care about that once this is published as an RFC. Please consider moving it to an appendix, or even removing it entirely.

-4.4.2: "For example, if the service LSP uses the clockwise working
  ring tunnel on Ring1, when the service LSP leaves Ring1 and enters
  Ring2, the working ring tunnel used on Ring2 SHOULD also follow the
  clockwise direction."
Please avoid repeating the 2119 "SHOULD" in the example.

- 5.1: "The MSRP protection operation MUST be controlled with the help of the
  Ring Protection Switch protocol (RPS)."
That seems like a statement of fact, rather than an implementation requirement.

Starting around 5.1, I notice several uses of the word "source" as a verb, where from context it seems like you mean "to send" or "to originate". Is that a term of art? I usually think of "source" as a verb to mind "acquire","find" or "find a source for"

-5.3: "... thus RPS SHOULD be capable of
  identifying and handling the different failures on the ring ..."
That seems like a statement of fact.
2017-05-23
05 Ben Campbell [Ballot Position Update] New position, No Objection, has been recorded for Ben Campbell
2017-05-23
05 Kathleen Moriarty [Ballot Position Update] New position, No Objection, has been recorded for Kathleen Moriarty
2017-05-22
05 Alexey Melnikov [Ballot Position Update] New position, No Objection, has been recorded for Alexey Melnikov
2017-05-22
05 Warren Kumari
[Ballot comment]
Some nits and a question:

3.  MPLS-TP Ring Protection Criteria and Requirements
a.  The number of OAM entities...

"Each ring-node requires only one …
[Ballot comment]
Some nits and a question:

3.  MPLS-TP Ring Protection Criteria and Requirements
a.  The number of OAM entities...

"Each ring-node requires only one instance of the RPS protocol. " --- not super important, but is this "Each ring-node requires only one instance of the RPS protocol (regardless of the number of rings)" or "Each ring-node requires only one instance of the RPS protocol per ring"? -- if a node participates in multiple rings, does it need an instance for each ring? (I suspect that this is somewhat of an implementation choice, but am not sure).


4.  Shared Ring Protection Architecture
4.1.  Ring Tunnel
"... ring tunnels which provides a server layer
  for the LSPs traverse the ring."
I think "for the LSP's traversing the ring." (or perhaps "which traverse the ring.")
2017-05-22
05 Warren Kumari [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari
2017-05-20
05 Deborah Brungard IESG state changed to IESG Evaluation from Waiting for Writeup
2017-05-18
05 Deborah Brungard Ballot has been issued
2017-05-18
05 Deborah Brungard [Ballot Position Update] New position, Yes, has been recorded for Deborah Brungard
2017-05-18
05 Deborah Brungard Created "Approve" ballot
2017-05-18
05 Deborah Brungard Ballot writeup was changed
2017-05-18
05 Deborah Brungard Ballot writeup was changed
2017-05-17
05 Christer Holmberg Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Christer Holmberg.
2017-05-12
05 (System) IESG state changed to Waiting for Writeup from In Last Call
2017-05-11
05 Jean Mahoney Request for Last Call review by GENART is assigned to Christer Holmberg
2017-05-11
05 Jean Mahoney Request for Last Call review by GENART is assigned to Christer Holmberg
2017-05-11
05 Jouni Korhonen Assignment of request for Last Call review by GENART to Jouni Korhonen was rejected
2017-05-11
05 Tero Kivinen Request for Last Call review by SECDIR Completed: Ready. Reviewer: Paul Hoffman.
2017-05-09
05 (System) IANA Review state changed to IANA OK - Actions Needed from IANA - Review Needed
2017-05-09
05 Sabrina Tanamal
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has completed its review of draft-ietf-mpls-tp-shared-ring-protection-05.txt. If any part of this review is inaccurate, please let …
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has completed its review of draft-ietf-mpls-tp-shared-ring-protection-05.txt. If any part of this review is inaccurate, please let us know.

The IANA Services Operator understands that, upon approval of [ RFC-to-be ], there are two actions which we must complete.

First, in the MPLS Generalized Associated Channel (G-ACh) Types (including Pseudowire Associated Channel Types) registry of the Generic Associated Channel (G-ACh) Parameters registry page located at:

https://www.iana.org/assignments/g-ach-parameters/

a single, new entry is to be registered as follows:

Value: [ TBD-at-registration ]
Description: Ring Protection Switching Protocol (RPS)
Reference: [ RFC-to-be ]

Second, a new registry is to be created called the MPLS RPS Request Code Registry. This new registry will be a part of the Generic Associated Channel (G-ACh) Parameters registry page.

https://www.iana.org/assignments/g-ach-parameters/

The new registry will be managed via Standards Action as defined by RFC 5226.

There are initial values in the new registry as follows:

Value Description Reference
------- --------------------------- ---------------
0 No Request (NR) [ RFC-to-be ]
1 Reverse Request (RR) [ RFC-to-be ]
2 unassigned
3 Exercise (EXER) [ RFC-to-be ]
4 unassigned
5 Wait-To-Restore (WTR) [ RFC-to-be ]
6 Manual Switch (MS) [ RFC-to-be ]
7-10 unassigned
11 Signal Fail (SF) [ RFC-to-be ]
12 unassigned
13 Forced Switch (FS) [ RFC-to-be ]
14 unassigned
15 Lockout of Protection (LP) [ RFC-to-be ]
16-254 unassigned
255 Reserved

The IANA Services Operator understands that these two actions are the only ones required to be completed upon approval of [ RFC-to-be ].

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.


Thank you,

Sabrina Tanamal
IANA Services Specialist
PTI
2017-05-05
05 Tero Kivinen Request for Last Call review by SECDIR is assigned to Paul Hoffman
2017-05-05
05 Tero Kivinen Request for Last Call review by SECDIR is assigned to Paul Hoffman
2017-05-05
05 Tero Kivinen Assignment of request for Last Call review by SECDIR to Dan Harkins was rejected
2017-05-04
05 Tero Kivinen Request for Last Call review by SECDIR is assigned to Dan Harkins
2017-05-04
05 Tero Kivinen Request for Last Call review by SECDIR is assigned to Dan Harkins
2017-05-01
05 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Tim Wicinski
2017-05-01
05 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Tim Wicinski
2017-04-28
05 Jean Mahoney Request for Last Call review by GENART is assigned to Jouni Korhonen
2017-04-28
05 Jean Mahoney Request for Last Call review by GENART is assigned to Jouni Korhonen
2017-04-28
05 Cindy Morgan IANA Review state changed to IANA - Review Needed
2017-04-28
05 Cindy Morgan
The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC: mpls@ietf.org, db3546@att.com, mpls-chairs@ietf.org, draft-ietf-mpls-tp-shared-ring-protection@ietf.org, Eric Gray , …
The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC: mpls@ietf.org, db3546@att.com, mpls-chairs@ietf.org, draft-ietf-mpls-tp-shared-ring-protection@ietf.org, Eric Gray , Eric.Gray@Ericsson.com
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Shared-Ring protection (MSRP) mechanism for ring topology) to Proposed Standard


The IESG has received a request from the Multiprotocol Label Switching WG
(mpls) to consider the following document:
- 'Shared-Ring protection (MSRP) mechanism for ring topology'
  as Proposed
Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2017-05-12. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  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 that is used to
  coordinate the protection behavior of the nodes on MPLS ring.





The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-mpls-tp-shared-ring-protection/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-mpls-tp-shared-ring-protection/ballot/

The following IPR Declarations may be related to this I-D:

  https://datatracker.ietf.org/ipr/2680/
  https://datatracker.ietf.org/ipr/2681/
  https://datatracker.ietf.org/ipr/2682/
  https://datatracker.ietf.org/ipr/2683/





2017-04-28
05 Cindy Morgan IESG state changed to In Last Call from Last Call Requested
2017-04-28
05 Deborah Brungard Placed on agenda for telechat - 2017-05-25
2017-04-28
05 Deborah Brungard Last call was requested
2017-04-28
05 Deborah Brungard Ballot approval text was generated
2017-04-28
05 Deborah Brungard Ballot writeup was generated
2017-04-28
05 Deborah Brungard IESG state changed to Last Call Requested from Expert Review
2017-04-28
05 Deborah Brungard Last call announcement was generated
2017-03-27
05 Weiqiang Cheng New version available: draft-ietf-mpls-tp-shared-ring-protection-05.txt
2017-03-27
05 (System) New version approved
2017-03-27
05 (System) Request for posting confirmation emailed to previous authors: Jie Dong , Huub van Helvoort , Weiqiang Cheng , Lei Wang , Han Li
2017-03-27
05 Weiqiang Cheng Uploaded new revision
2017-02-27
04 Min Ye Request for Last Call review by RTGDIR Completed: Has Nits. Reviewer: Mach Chen.
2017-02-09
04 Min Ye Request for Last Call review by RTGDIR is assigned to Mach Chen
2017-02-09
04 Min Ye Request for Last Call review by RTGDIR is assigned to Mach Chen
2017-02-09
04 Min Ye Closed request for Early review by RTGDIR with state 'Withdrawn'
2017-02-09
04 Min Ye Requested Last Call review by RTGDIR
2017-02-09
04 Deborah Brungard Routing Area Directorate review - Mach will do.
2017-02-09
04 Deborah Brungard IESG state changed to Expert Review from Publication Requested
2017-02-08
04 Min Ye Request for Early review by RTGDIR is assigned to Mach Chen
2017-02-08
04 Min Ye Request for Early review by RTGDIR is assigned to Mach Chen
2017-02-08
04 Min Ye Request for Early review by RTGDIR is assigned to Patrice Brissette
2017-02-08
04 Min Ye Request for Early review by RTGDIR is assigned to Patrice Brissette
2017-02-08
04 Min Ye Requested Early review by RTGDIR
2017-01-30
04 Loa Andersson
The MPLS Working Group requests that



        Shared-Ring protection (MSRP) mechanism for ring topology

                …
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.
2017-01-30
04 Loa Andersson Responsible AD changed to Deborah Brungard
2017-01-30
04 Loa Andersson IETF WG state changed to Submitted to IESG for Publication from Waiting for WG Chair Go-Ahead
2017-01-30
04 Loa Andersson IESG state changed to Publication Requested
2017-01-30
04 Loa Andersson IESG process started in state Publication Requested
2017-01-30
04 Loa Andersson Notification list changed to "Eric Gray" <Eric.Gray@Ericsson.com> loa@pi.nu from "Eric Gray" <Eric.Gray@Ericsson.com>
2017-01-30
04 Loa Andersson Changed document writeup
2016-12-13
04 Weiqiang Cheng New version available: draft-ietf-mpls-tp-shared-ring-protection-04.txt
2016-12-13
04 (System) New version approved
2016-12-13
04 (System) Request for posting confirmation emailed to previous authors: "Weiqiang Cheng" , "Jie Dong" , "Lei Wang" , "Han Li" , "Huub van Helvoort"
2016-12-13
04 Weiqiang Cheng Uploaded new revision
2016-10-06
03 Loa Andersson IETF WG state changed to Waiting for WG Chair Go-Ahead from In WG Last Call
2016-10-01
03 Weiqiang Cheng New version available: draft-ietf-mpls-tp-shared-ring-protection-03.txt
2016-10-01
03 Weiqiang Cheng New version approved
2016-10-01
03 Weiqiang Cheng
Request for posting confirmation emailed to previous authors: "Junfang Wang" , "He Jia" , mpls-chairs@ietf.org, "Kai Liu" , "Yang Jian" , "Lei Wang" , …
Request for posting confirmation emailed to previous authors: "Junfang Wang" , "He Jia" , mpls-chairs@ietf.org, "Kai Liu" , "Yang Jian" , "Lei Wang" , "Han Li" , "Fang Li" , "Huub van Helvoort" , "Weiqiang Cheng" , "Jie Dong"
2016-10-01
03 (System) Uploaded new revision
2016-08-16
02 Loa Andersson The wg last call is palnned to end August 29. 2016.
2016-08-16
02 Loa Andersson IETF WG state changed to In WG Last Call from WG Document
2016-08-16
02 Loa Andersson Changed consensus to Yes from Unknown
2016-08-16
02 Loa Andersson Intended Status changed to Proposed Standard from None
2016-07-19
02 Loa Andersson Notification list changed to "Eric Gray" <Eric.Gray@Ericsson.com>
2016-07-19
02 Loa Andersson Document shepherd changed to Eric Gray
2016-06-14
02 Jie Dong New version available: draft-ietf-mpls-tp-shared-ring-protection-02.txt
2016-03-21
01 Jie Dong New version available: draft-ietf-mpls-tp-shared-ring-protection-01.txt
2015-10-14
00 (System) Notify list changed from "Ross Callon"  to (None)
2015-10-09
00 Ross Callon Notification list changed to "Ross Callon" <rcallon@juniper.net>
2015-10-09
00 Ross Callon Document shepherd changed to Ross Callon
2015-10-09
00 Loa Andersson This document now replaces draft-cheng-mpls-tp-shared-ring-protection instead of None
2015-10-09
00 Weiqiang Cheng New version available: draft-ietf-mpls-tp-shared-ring-protection-00.txt