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 |