Requirements for MPLS Transport Profile (MPLS-TP) Shared Mesh Protection
RFC 7412
Revision differences
Document history
| Date | Rev. | By | Action |
|---|---|---|---|
|
2015-10-14
|
09 | (System) | Notify list changed from mpls-chairs@ietf.org, draft-ietf-mpls-smp-requirements@ietf.org to (None) |
|
2014-12-12
|
09 | (System) | RFC published |
|
2014-12-08
|
09 | (System) | RFC Editor state changed to <a href="http://www.rfc-editor.org/auth48/rfc7412">AUTH48-DONE</a> from AUTH48 |
|
2014-11-24
|
09 | (System) | RFC Editor state changed to <a href="http://www.rfc-editor.org/auth48/rfc7412">AUTH48</a> from RFC-EDITOR |
|
2014-11-21
|
09 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
|
2014-10-13
|
09 | Amy Vezza | IESG state changed to RFC Ed Queue from Approved-announcement sent |
|
2014-10-10
|
09 | (System) | RFC Editor state changed to EDIT |
|
2014-10-10
|
09 | (System) | Announcement was received by RFC Editor |
|
2014-10-10
|
09 | (System) | IANA Action state changed to No IC from In Progress |
|
2014-10-10
|
09 | (System) | IANA Action state changed to In Progress |
|
2014-10-10
|
09 | Amy Vezza | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
|
2014-10-10
|
09 | Amy Vezza | IESG has approved the document |
|
2014-10-10
|
09 | Amy Vezza | Closed "Approve" ballot |
|
2014-10-10
|
09 | Adrian Farrel | IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup |
|
2014-10-10
|
09 | Adrian Farrel | Ballot writeup was changed |
|
2014-10-10
|
09 | Adrian Farrel | Ballot approval text was generated |
|
2014-09-28
|
09 | Kathleen Moriarty | [Ballot comment] Thanks very much for addressing my discuss from the SecDir review and comments in the updated version. |
|
2014-09-28
|
09 | Kathleen Moriarty | [Ballot Position Update] Position for Kathleen Moriarty has been changed to No Objection from Discuss |
|
2014-09-27
|
09 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
|
2014-09-27
|
09 | Jeong-dong Ryoo | IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed |
|
2014-09-27
|
09 | Jeong-dong Ryoo | New version available: draft-ietf-mpls-smp-requirements-09.txt |
|
2014-08-18
|
08 | Gunter Van de Velde | Closed request for Last Call review by OPSDIR with state 'No Response' |
|
2014-08-11
|
08 | Meral Shirazipour | Request for Telechat review by GENART Completed: Ready. Reviewer: Meral Shirazipour. |
|
2014-08-07
|
08 | Cindy Morgan | IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation |
|
2014-08-07
|
08 | Joel Jaeggli | [Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli |
|
2014-08-07
|
08 | Stephen Farrell | [Ballot comment] I'm not sure I agree that there are no new security considerations here. Say if the path ABCDE has some security property (e.g. … [Ballot comment] I'm not sure I agree that there are no new security considerations here. Say if the path ABCDE has some security property (e.g. encrypted) then won't that also be a requirement that APQRE will also need to be able to meet? And doesn't that then impose some requirements on solutions? So wouldn't it be a good plan to add a requirement that solutions MUST be able to ensure/manage commensurate security for protection paths? (This is not a discuss because I'd be fine to raise such a discuss ballot for a solution document, and also because it overlaps with Kathleen's discuss with which I agree.) |
|
2014-08-07
|
08 | Stephen Farrell | [Ballot Position Update] New position, No Objection, has been recorded for Stephen Farrell |
|
2014-08-07
|
08 | Pete Resnick | [Ballot Position Update] New position, No Objection, has been recorded for Pete Resnick |
|
2014-08-07
|
08 | Kathleen Moriarty | [Ballot discuss] I didn't see a response to the SecDir review and think there was a good catch in the review that is worth discussing … [Ballot discuss] I didn't see a response to the SecDir review and think there was a good catch in the review that is worth discussing to see if some text should be added to the Security Considerations section. The request was to put more into the security considerations since this is a requirements draft. The problems would be addressed in the specific solution drafts, but it would be good to call these issues out as security considerations for those solutions. Possible text: Security considerations for any proposed solution should consider exhaustion of resources related to preemption, especially by a malicious actor as a threat vector to protect against. Protections should also be considered to prevent a malicious actor from attempting to cause an alternate path to force traffic by a sensor/device, thereby enabling pervasive monitoring [RFC7258]. Here is the SecDir review for reference: https://www.ietf.org/mail-archive/web/secdir/current/msg04864.html |
|
2014-08-07
|
08 | Kathleen Moriarty | Ballot discuss text updated for Kathleen Moriarty |
|
2014-08-07
|
08 | Kathleen Moriarty | [Ballot discuss] I didn't see a response to the SecDir review and think there was a good catch in the review that is worth discussing … [Ballot discuss] I didn't see a response to the SecDir review and think there was a good catch in the review that is worth discussing to see if some text should be added to the Security Considerations section. The request was to put more into the security considerations since this is a requirements draft. The problems would be addressed in the specific solution drafts, but it would be good to call these issues out as security considerations for those solutions. Possible text: Security considerations for any proposed solution should consider exhaustion of resources related to preemption, especially by a malicious actor as a threat vector to protect against. Protections should also be considered to prevent a malicious actor from attempting to cause an alternate path to force traffic by a sensor/device, thereby enabling pervasive monitoring [RFC7258]. |
|
2014-08-07
|
08 | Kathleen Moriarty | [Ballot comment] Could you add a small amount of text into the introduction so that it is clear that the term protection used in this … [Ballot comment] Could you add a small amount of text into the introduction so that it is clear that the term protection used in this draft is referring to survivability or availability? Or a reference to it would be helpful as was done in the second paragraph of the introduction of RFC6378. Text is preferred though since this should be very simple to address with a few words. As a security person, I was mapping out paths and trying to figure out if certain resources had special properties I didn't see described anywhere until I got a bit further into the draft to realize they were really just alternate paths. I am sure this wouldn't be an issue for those well-versed in MPLS, but could be helpful for the rest of us. |
|
2014-08-07
|
08 | Kathleen Moriarty | [Ballot Position Update] New position, Discuss, has been recorded for Kathleen Moriarty |
|
2014-08-06
|
08 | Jari Arkko | [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko |
|
2014-08-06
|
08 | Spencer Dawkins | [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins |
|
2014-08-05
|
08 | Martin Stiemerling | [Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling |
|
2014-07-31
|
08 | Jean Mahoney | Request for Telechat review by GENART is assigned to Meral Shirazipour |
|
2014-07-31
|
08 | Jean Mahoney | Request for Telechat review by GENART is assigned to Meral Shirazipour |
|
2014-07-30
|
08 | (System) | IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed |
|
2014-07-30
|
08 | Adrian Farrel | Ballot has been issued |
|
2014-07-30
|
08 | Adrian Farrel | [Ballot Position Update] New position, Yes, has been recorded for Adrian Farrel |
|
2014-07-30
|
08 | Adrian Farrel | Created "Approve" ballot |
|
2014-07-30
|
08 | Adrian Farrel | Placed on agenda for telechat - 2014-08-07 |
|
2014-07-30
|
08 | Adrian Farrel | IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead::AD Followup |
|
2014-07-30
|
08 | Adrian Farrel | Ballot writeup was changed |
|
2014-07-30
|
08 | Adrian Farrel | Changed consensus to Yes from Unknown |
|
2014-07-25
|
08 | Jeong-dong Ryoo | New version available: draft-ietf-mpls-smp-requirements-08.txt |
|
2014-07-22
|
07 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
|
2014-07-22
|
07 | Jeong-dong Ryoo | IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed |
|
2014-07-22
|
07 | Jeong-dong Ryoo | New version available: draft-ietf-mpls-smp-requirements-07.txt |
|
2014-06-26
|
06 | Tero Kivinen | Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Christopher Inacio. |
|
2014-06-23
|
06 | Meral Shirazipour | Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Meral Shirazipour. |
|
2014-06-23
|
06 | Adrian Farrel | IESG state changed to Waiting for AD Go-Ahead::Revised I-D Needed from Waiting for AD Go-Ahead |
|
2014-06-23
|
06 | (System) | IESG state changed to Waiting for AD Go-Ahead from In Last Call |
|
2014-06-13
|
06 | Jean Mahoney | Request for Last Call review by GENART is assigned to Meral Shirazipour |
|
2014-06-13
|
06 | Jean Mahoney | Request for Last Call review by GENART is assigned to Meral Shirazipour |
|
2014-06-12
|
06 | (System) | IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed |
|
2014-06-12
|
06 | Pearl Liang | IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-mpls-smp-requirements-05, which is currently in Last Call, and has the following comments: We understand that, upon approval of this … IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-mpls-smp-requirements-05, which is currently in Last Call, and has the following comments: We understand that, upon approval of this document, there are no IANA Actions that need completion. While it is helpful for the IANA Considerations section of the document to remain in place upon publication, if the authors prefer to remove it, IANA doesn't object. If this assessment is not accurate, please respond as soon as possible. |
|
2014-06-12
|
06 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Christopher Inacio |
|
2014-06-12
|
06 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Christopher Inacio |
|
2014-06-11
|
06 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Joe Abley |
|
2014-06-11
|
06 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Joe Abley |
|
2014-06-10
|
06 | Jeong-dong Ryoo | New version available: draft-ietf-mpls-smp-requirements-06.txt |
|
2014-06-09
|
05 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
|
2014-06-09
|
05 | Amy Vezza | The following Last Call announcement was sent out:<br><br>From: The IESG <iesg-secretary@ietf.org> To: IETF-Announce <ietf-announce@ietf.org> CC: <mpls@ietf.org> Reply-To: ietf@ietf.org Sender: … The following Last Call announcement was sent out:<br><br>From: The IESG <iesg-secretary@ietf.org> To: IETF-Announce <ietf-announce@ietf.org> CC: <mpls@ietf.org> Reply-To: ietf@ietf.org Sender: <iesg-secretary@ietf.org> Subject: Last Call: <draft-ietf-mpls-smp-requirements-05.txt> (Requirements for MPLS-TP Shared Mesh Protection) to Informational RFC The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'Requirements for MPLS-TP Shared Mesh Protection' <draft-ietf-mpls-smp-requirements-05.txt> as Informational RFC 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 2014-06-23. 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 presents the basic network objectives for the behavior of shared mesh protection (SMP) which are not based on control plane support. This is an expansion of the basic requirements presented in RFC 5654 "Requirements for the Transport Profile of MPLS" and RFC 6372 "MPLS Transport Profile (MPLS-TP) Survivability Framework". This document is to be used as a basis for the definition of any mechanism that would be used to implement SMP for MPLS-TP data paths, in networks that delegate executive action for resiliency to the data plane. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-mpls-smp-requirements/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-mpls-smp-requirements/ballot/ No IPR declarations have been submitted directly on this I-D. |
|
2014-06-09
|
05 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
|
2014-06-08
|
05 | Adrian Farrel | Last call was requested |
|
2014-06-08
|
05 | Adrian Farrel | Ballot approval text was generated |
|
2014-06-08
|
05 | Adrian Farrel | IESG state changed to Last Call Requested from AD Evaluation |
|
2014-06-08
|
05 | Adrian Farrel | Last call announcement was changed |
|
2014-06-08
|
05 | Adrian Farrel | Last call announcement was generated |
|
2014-06-08
|
05 | Adrian Farrel | Last call announcement was generated |
|
2014-06-08
|
05 | Adrian Farrel | AD review ========= Hi authors, I have done my usual review of your document having received the publication request. The purpose of my review is … AD review ========= Hi authors, I have done my usual review of your document having received the publication request. The purpose of my review is to improve the quality of the document and to catch any issues that might otherwise show up during IETF last call, Directorate reviews, or IESG evaluation. This is a pretty good document. Thanks for the effort you have put in, and thanks to Matt for working on the English. He deserves an acknowledgement somewhere in the document. I have only a few issues, and they don't merit a new revision now. So I will start the IETF last call and raise these points to be addressed at that time. Thanks, Adrian --- Could you expand "p2p" where it is first used? --- The very first sentence is hard to parse MPLS transport networks can be characterized as being a network of connections between nodes within a mesh of nodes and the links between them. Maybe try The MPLS Transport Profile (MPLS-TP) provides tools to construct and operate a set of connections between nodes in an MPLS network. The MPLS network is a mesh comprising nodes and the links between them. --- I understand that you want to use RFC 2119 language to clarify the requirements, but RFC 2119 was developed for specifying protocols, so the direct reference and boilerplate quote is incongruous. I suggest you use the language as found in RFC 5654, viz.: The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Although this document is not a protocol specification, the use of this language clarifies the instructions to protocol designers producing solutions that satisfy the requirements set out in this document. --- In Section 5.1 you have the control protocol SHOULD NOT be used as the primary resilience mechanism. I agree, but I think that the term "primary resilience mechanism" may be under defined. Can you do anything to clarify this? Maybe... the control protocol SHOULD NOT be used as the primary mechanism for detecting or reporting network failures, or for initiating or coordinating protection switch-over. That is, it SHOULD NOT be used as the primary resilience mechanism. |
|
2014-06-07
|
05 | Adrian Farrel | IESG state changed to AD Evaluation from Publication Requested |
|
2014-06-07
|
05 | Adrian Farrel | Ballot writeup was changed |
|
2014-06-07
|
05 | Adrian Farrel | Ballot writeup was generated |
|
2014-06-07
|
05 | Adrian Farrel | The MPLS working group requests that Requirements for MPLS-TP Shared Mesh Protection … The MPLS working group requests that Requirements for MPLS-TP Shared Mesh Protection draft-ietf-mpls-smp-requirements-05.txt Is published as an Informational RFC with IETF consensus. (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 is a requirement specification and should be published as an Informational RFC with IETF consensus. The document header says "Informational". (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary This document presents the basic objectives of shared mesh protection (SMP) that can be utilized without dependence on a control plane. The document expands the requirements of RFC 5654 "Requirements for the Transport Profile of MPLS" and RFC 6372 "MPLS Transport Profile (MPLS-TP) Survivability Framework". The intention is that this document shall be used when defining mechanisms that use SMP to implement protection for MPLS-TP data paths, in networks that delegate executive action for resiliency to the data plane. Working Group Summary Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? The history of MPLS-TP SMP includes starting out with a number of solution drafts, some which were fairly quickly merged, but we failed to merge all solutions into a single document. The advice from the working group chairs at this point was to start with a requirement specification. The current document is the result of that process and includes authors from across the solutions drafts. The document has been well discussed in the part of the MPLS WG that is interested in MPLS-TP style protection. The only "out of the ordinary" thing that has happened is that at one point in time some of the authors told me that "the document is ready for wglc". In preparation for the wglc the shepherd started an IPR poll saying: "The authors of draft-ietf-mpls-smp-requirements have told the working group chairs that the draft is ready to be working group last called. Before starting the the wglc we need to do an IPR poll." Resulting in that one author and one contributor notified the shepherd that they did not believe the document was ready to go! Well - this was sorted out and all comments addressed. Document Quality This document is a requirement specification, and as such is not possible to implement. It has been claimed in the discussion that led up to merging solutions documents and requirement that some of the existing MPLS-TP protection implementations fulfill the requirements in this draft. The discussion on implementations will be revisited if and when we see solutions addressing the requirements in this document being put forward. Personnel Who is the Document Shepherd? Who is the Responsible Area Director? Loa Andersson is the Document Shepherd. Adrian Farrel 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 believes this document is ready for publication as an Informational RFC. Since the ITU-T SG15 is interested to use it as a reference, it should go through IETF Last Call. The document shepherd has reviewed this and related documents several times since the discussion on MPLS-TP shared mesh protection started in 2010. The Shepherd has also been participating in the efforts to merge the solutions document and establish requirement document. The Shepherd has the impression that there is a strong vendor and operator interest in this area, and that this set of requirements represents a least common denominator. The Document Shepherd reviewed the document prior to the WG Adoption poll and prior to wglc. When preparing the Shepherd Write-up for version -04, the document shepherd decided that a langue review were needed and version -05 is the result of this review performed by Matt Hartley.The language review has very much improved the document. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? 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 such review needed. (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. No real concerns, the only thing is that the document need to go through an full IETF Last Call in order to be possible for ITU-T to use it as a reference. (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 contributors have stated on the working group mailing list that they are unaware of any IPR against this document. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No IPR disclosures filed against this document. (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? In the part of the working group that is interested in MPLS-TP protection the consensus is very strong, in the part of the working group more interested IP/MPLS FRR and by-pass, the document is less well reviewed but I'd say that based on the checks I've done no issues with progressing the document have emerged. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No such threats! (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. The nits tools points gives on warning, an unexpected double-space on line 154. I think that this can be updated by the RFC Editor or if new revisions are needed down the line. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. No formal reviews required. (13) Have all references within this document been identified as either normative or informative? There are only normative 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 (normative) references are to existing RFC or to stable ITU-T Recommendations. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No 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. There are no documents for which the status will be changed. (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). There are no IANA allocations in this document. (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. No such registries. (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 reviews performed. |
|
2014-06-07
|
05 | Adrian Farrel | The MPLS working group requests that Requirements for MPLS-TP Shared Mesh Protection … The MPLS working group requests that Requirements for MPLS-TP Shared Mesh Protection draft-ietf-mpls-smp-requirements-05.txt Is published as an Informational RFC with IETF consensus. (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 is a requirement specification and should be published as an Informational RFC with IETF consensus. The document header says "Informational". (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary This document presents the basic objectives of shared mesh protection (SMP) that can be utilized without dependence on a control plane. The document expands the requirements of RFC 5654 "Requirements for the Transport Profile of MPLS" and RFC 6372 "MPLS Transport Profile (MPLS-TP) Survivability Framework". The intention is that this document shall be used when defining mechanisms that use SMP to implement protection for MPLS-TP data paths, in networks that delegate executive action for resiliency to the data plane. Working Group Summary Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? The history of MPLS-TP SMP includes starting out with a number of solution drafts, some which were fairly quickly merged, but we failed to merge all solutions into a single document. The advice from the working group chairs at this point was to start with a requirement specification. The current document is the result of that process. The document has been well discussed in the part of the MPLS WG that is interested in MPLS-TP style protection. Document Quality This document is a requirement specification, and as such is not possible to implement. It has been claimed in the discussion that led up to merging solutions documents and requirement that some of the existing MPLS-TP protection implementations fulfill the requirements in this draft. The discussion on implementations will be revisited if and when we see solutions addressing the requirements in this document being put forward. Personnel Who is the Document Shepherd? Who is the Responsible Area Director? Loa Andersson is the Document Shepherd. Adrian Farrel 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 believes this document is ready for publication as an Informational RFC. Since the ITU-T SG15 is interested to use it as a reference, it should go through IETF Last Call. The document shepherd have reviewed this and related documents several times since the discussion on MPLS-TP shared mesh protection started in 2010. The Shepherd has also been participating in the efforts to merge the solutions document and establish requirement document. The Shepherd has the impression that there is a strong vendor and operator interest in this area, and that this set of requirements represents a least common denominator. The Document Shepherd reviewed the document prior to the WG Adoption poll and prior to wglc. When preparing the Shepherd Write-up for version -04, the document shepherd decided that a langue review were needed and version -05 is the result of this review performed by Matt Hartley.The language review have very much improved the document. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? 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 such review needed. The only "out of the ordinary" thing that has happened is that at one point in time some of the authors told me that "the document is ready for wglc". In preparation for the wglc the shepherd started an IPR poll saying: "The authors of draft-ietf-mpls-smp-requirements has told the working group chairs that the draft is ready to be working group last called. Before starting the the wglc we need to do an IPR poll." Resulting in that one author and one contributor notified the shepherd that they did not believe the document was ready to go! Well - this was sorted out and all comments addressed. (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. No real concerns, the only thing is that the document need to go through an full IETF Last Call in order to be possible for ITU-T to use it as a reference. (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 contributors have stated on the working group mailing list that they are unaware of any IPR against this document. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No IPR disclosures filed against this document. (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? In the part of the working group that is interested in MPLS-TP protection the consensus is very strong, in the part of the working group more interested IP/MPLS FRR and by-pass, the document is less well reviewed but I'd say that based on the checks I've done no issues with progressing the document have emerged. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No such threats! (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. The nits tools points gives on warning, an unexpected double-space on line 154. I think that this can be updated by the RFC Editor or if new revisions are needed down the line. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. No formal reviews required. (13) Have all references within this document been identified as either normative or informative? There are only normative 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 (normative) references are to existing RFC or to stable ITU-T Recommendations. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No 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. There are no documents for which the status will be changed. (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). There are no IANA allocations in this document. (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. No such registries. (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 reviews performed. |
|
2014-06-04
|
05 | Loa Andersson | Document shepherd changed to Loa Andersson |
|
2014-06-03
|
05 | Loa Andersson | The MPLS working group requests that Requirements for MPLS-TP Shared Mesh Protection … The MPLS working group requests that Requirements for MPLS-TP Shared Mesh Protection draft-ietf-mpls-smp-requirements-05.txt Is published as an Informational RFC with IETF consensus. (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 is a requirement specification and should be published as an Informational RFC with IETF consensus. The document header says "Informational". (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary This document presents the basic objectives of shared mesh protection (SMP) that can be utilized without dependence on a control plane. The document expands the requirements of RFC 5654 "Requirements for the Transport Profile of MPLS" and RFC 6372 "MPLS Transport Profile (MPLS-TP) Survivability Framework". The intention is that this document shall be used when defining mechanisms that use SMP to implement protection for MPLS-TP data paths, Working Group Summary Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? The history of MPLS-TP SMP includes starting out with a number of solution drafts, some which were fairly quickly merged, but we failed to merge all solutions into a single document. The advice from the working group chairs at this point was to start with a requirement specification. The current document is the result of that process. The document has been well discussed in the part of the MPLS WG that is interested in MPLS-TP style protection. Document Quality This document is a requirement specification, and as such is not possible to implement. It has been claimed in the discussion that led up to merging solutions documents and requirement that some of the existing MPLS-TP protection implementations fulfill the requirements in this draft. The discussion on implementations will be revisited if and when we see solutions addressing the requirements in this document being put forward. Personnel Who is the Document Shepherd? Who is the Responsible Area Director? Loa Andersson is the Document Shepherd. Adrian Farrel 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 believes this document is ready for publication as an Informational RFC. Since the ITU-T SG15 is interested to use it as a reference, it should go through IETF Last Call. The document shepherd have reviewed this and related documents several times since the discussion on MPLS-TP shared mesh protection started in 2010. The Shepherd has also been participating in the efforts to merge the solutions document and establish requirement document. The Shepherd has the impression that there is a strong vendor and operator interest in this area, and that this set of requirements represents a least common denominator. The Document Shepherd reviewed the document prior to the WG Adoption poll and prior to wglc. When preparing the Shepherd Write-up for version -04, the document shepherd decided that a langue review were needed and version -05 is the result of this review performed by Matt Hartley.The language review have very much improved the document. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? 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 such review needed. The only "out of the ordinary" thing that has happened is that at one point in time some of the authors told me that "the document is ready for wglc". In preparation for the wglc the shepherd started an IPR poll saying: "The authors of draft-ietf-mpls-smp-requirements has told the working group chairs that the draft is ready to be working group last called. Before starting the the wglc we need to do an IPR poll." Resulting in that one author and one contributor notified the shepherd that they did not believe the document was ready to go! Well - this was sorted out and all comments addressed. (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. No real concerns, the only thing is that the document need to go through an full IETF Last Call in order to be possible for ITU-T to use it as a reference. (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 contributors have stated on the working group mailing list that they are unaware of any IPR against this document. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No IPR disclosures filed against this document. (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? In the part of the working group that is interested in MPLS-TP protection the consensus is very strong, in the part of the working group more interested IP/MPLS FRR and by-pass, the document is less well reviewed but I'd say that based on the checks I've done no issues with progressing the document have emerged. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No such threats! (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. The nits tools points gives on warning, an unexpected double-space on line 154. I think that this can be updated by the RFC Editor or if new revisions are needed down the line. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. No formal reviews required. (13) Have all references within this document been identified as either normative or informative? There are only normative 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 (normative) references are to existing RFC or to stable ITU-T Recommendations. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No 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. There are no documents for which the status will be changed. (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). There are no IANA allocations in this document. (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. No such registries. (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 reviews performed. |
|
2014-06-03
|
05 | Loa Andersson | State Change Notice email list changed to mpls-chairs@tools.ietf.org, draft-ietf-mpls-smp-requirements@tools.ietf.org |
|
2014-06-03
|
05 | Loa Andersson | Responsible AD changed to Adrian Farrel |
|
2014-06-03
|
05 | Loa Andersson | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
|
2014-06-03
|
05 | Loa Andersson | IESG state changed to Publication Requested |
|
2014-06-03
|
05 | Loa Andersson | IESG process started in state Publication Requested |
|
2014-06-03
|
05 | Loa Andersson | Changed document writeup |
|
2014-06-02
|
05 | Loa Andersson | Changed document writeup |
|
2014-06-01
|
05 | Loa Andersson | Changed document writeup |
|
2014-06-01
|
05 | Loa Andersson | Changed document writeup |
|
2014-06-01
|
05 | Loa Andersson | Changed document writeup |
|
2014-06-01
|
05 | Loa Andersson | Tag Revised I-D Needed - Issue raised by WG cleared. |
|
2014-06-01
|
05 | Loa Andersson | Changed document writeup |
|
2014-05-30
|
05 | Sam Aldrin | New version available: draft-ietf-mpls-smp-requirements-05.txt |
|
2014-04-30
|
04 | Loa Andersson | Tag Revised I-D Needed - Issue raised by WG set. |
|
2014-03-14
|
04 | Sam Aldrin | New version available: draft-ietf-mpls-smp-requirements-04.txt |
|
2014-01-31
|
03 | Loa Andersson | Tag Revised I-D Needed - Issue raised by WGLC cleared. |
|
2014-01-31
|
03 | Loa Andersson | IETF WG state changed to WG Consensus: Waiting for Write-Up from Waiting for WG Chair Go-Ahead |
|
2014-01-31
|
03 | Sam Aldrin | New version available: draft-ietf-mpls-smp-requirements-03.txt |
|
2014-01-05
|
02 | Loa Andersson | Tag Revised I-D Needed - Issue raised by WGLC set. |
|
2014-01-05
|
02 | Loa Andersson | IETF WG state changed to Waiting for WG Chair Go-Ahead from In WG Last Call |
|
2013-12-12
|
02 | Loa Andersson | IETF WG state changed to In WG Last Call from WG Document |
|
2013-12-12
|
02 | Loa Andersson | Annotation tag Revised I-D Needed - Issue raised by WG cleared. |
|
2013-12-09
|
02 | Sam Aldrin | New version available: draft-ietf-mpls-smp-requirements-02.txt |
|
2013-11-07
|
01 | Loa Andersson | Annotation tag Revised I-D Needed - Issue raised by WG set. |
|
2013-11-07
|
01 | Loa Andersson | Intended Status changed to Informational from None |
|
2013-09-27
|
01 | Martin Vigoureux | Document shepherd changed to Loa Andersson |
|
2013-09-23
|
01 | Sam Aldrin | New version available: draft-ietf-mpls-smp-requirements-01.txt |
|
2013-03-26
|
00 | Sam Aldrin | New version available: draft-ietf-mpls-smp-requirements-00.txt |