Use of Multipath with MPLS and MPLS Transport Profile (MPLS-TP)
RFC 7190
Revision differences
Document history
| Date | Rev. | By | Action |
|---|---|---|---|
|
2018-12-20
|
04 | (System) | Received changes through RFC Editor sync (changed abstract to 'Many MPLS implementations have supported multipath techniques, and many MPLS deployments have used multipath techniques, particularly … Received changes through RFC Editor sync (changed abstract to 'Many MPLS implementations have supported multipath techniques, and many MPLS deployments have used multipath techniques, particularly in very high-bandwidth applications, such as provider IP/MPLS core networks. MPLS Transport Profile (MPLS-TP) has strongly discouraged the use of multipath techniques. Some degradation of MPLS-TP Operations, Administration, and Maintenance (OAM) performance cannot be avoided when operating over many types of multipath implementations. Using MPLS Entropy Labels (RFC 6790), MPLS Label Switched Paths (LSPs) can be carried over multipath links while also providing a fully MPLS-TP-compliant server layer for MPLS-TP LSPs. This document describes the means of supporting MPLS as a server layer for MPLS-TP. The use of MPLS-TP LSPs as a server layer for MPLS LSPs is also discussed.') |
|
2015-10-14
|
04 | (System) | Notify list changed from mpls-chairs@ietf.org, draft-ietf-mpls-multipath-use@ietf.org to (None) |
|
2014-03-31
|
04 | (System) | RFC published |
|
2014-03-27
|
04 | (System) | RFC Editor state changed to <a href="http://www.rfc-editor.org/auth48/rfc7190">AUTH48-DONE</a> from AUTH48 |
|
2014-03-24
|
04 | (System) | RFC Editor state changed to <a href="http://www.rfc-editor.org/auth48/rfc7190">AUTH48</a> from RFC-EDITOR |
|
2014-03-22
|
04 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
|
2014-01-31
|
04 | Cindy Morgan | IESG state changed to RFC Ed Queue from Approved-announcement sent |
|
2014-01-31
|
04 | (System) | RFC Editor state changed to EDIT |
|
2014-01-31
|
04 | (System) | Announcement was received by RFC Editor |
|
2014-01-31
|
04 | (System) | IANA Action state changed to No IC from In Progress |
|
2014-01-31
|
04 | (System) | IANA Action state changed to In Progress |
|
2014-01-30
|
04 | Tero Kivinen | Closed request for Last Call review by SECDIR with state 'No Response' |
|
2014-01-30
|
04 | Amy Vezza | State changed to Approved-announcement sent from Approved-announcement to be sent |
|
2014-01-30
|
04 | Amy Vezza | IESG has approved the document |
|
2014-01-30
|
04 | Amy Vezza | Closed "Approve" ballot |
|
2014-01-30
|
04 | Amy Vezza | State changed to Approved-announcement to be sent from IESG Evaluation::AD Followup |
|
2014-01-30
|
04 | Adrian Farrel | Ballot writeup was changed |
|
2014-01-30
|
04 | Adrian Farrel | Ballot approval text was generated |
|
2014-01-30
|
04 | Stewart Bryant | [Ballot comment] Thank you for addressing my concerns. |
|
2014-01-30
|
04 | Stewart Bryant | [Ballot Position Update] Position for Stewart Bryant has been changed to Yes from Discuss |
|
2014-01-28
|
04 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
|
2014-01-28
|
04 | Curtis Villamizar | IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed |
|
2014-01-28
|
04 | Curtis Villamizar | New version available: draft-ietf-mpls-multipath-use-04.txt |
|
2014-01-23
|
03 | Cindy Morgan | State changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation |
|
2014-01-23
|
03 | Joel Jaeggli | [Ballot comment] This needs to get held up until the proposed update associated with David Black's review is out. Stewart's dicuss is sufficient for that, … [Ballot comment] This needs to get held up until the proposed update associated with David Black's review is out. Stewart's dicuss is sufficient for that, I would otherwise hold one if I felt it were necessary. Thanks |
|
2014-01-23
|
03 | Joel Jaeggli | [Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli |
|
2014-01-23
|
03 | Stephen Farrell | [Ballot comment] - What is a "server layer"? I think I can guess but a ref/definition would be good. - Section 8: I would have … [Ballot comment] - What is a "server layer"? I think I can guess but a ref/definition would be good. - Section 8: I would have thought that a layering like this could introduce new (or perhaps make obvious previously unrecognised) security issues if the layers are actually operated by/for different entities. Is that a potential deployment here? Or if this layering descruption is designed to only be used within a single administrative domain, then saying that would seem to be relevant. |
|
2014-01-23
|
03 | Stephen Farrell | [Ballot Position Update] New position, No Objection, has been recorded for Stephen Farrell |
|
2014-01-23
|
03 | Gonzalo Camarillo | [Ballot Position Update] New position, No Objection, has been recorded for Gonzalo Camarillo |
|
2014-01-23
|
03 | Richard Barnes | [Ballot Position Update] New position, No Objection, has been recorded for Richard Barnes |
|
2014-01-23
|
03 | Gunter Van de Velde | Request for Last Call review by OPSDIR Completed: Has Issues. Reviewer: David Black. |
|
2014-01-22
|
03 | Brian Haberman | [Ballot Position Update] New position, No Objection, has been recorded for Brian Haberman |
|
2014-01-22
|
03 | Stewart Bryant | [Ballot discuss] I have a number of Discuss point on this text which I think will be easily addressed. "The ability to completely exclude MPLS-TP … [Ballot discuss] I have a number of Discuss point on this text which I think will be easily addressed. "The ability to completely exclude MPLS-TP LSPs from the multipath hash and load split SHOULD be supported. " Surely this has to be a MUST since if it is not supported it breaks the MPLS-TP invariants on mis-ordering and fate sharing. "For those client LSP that are MPLS-TP LSP, a single EL value must be chosen. " This sounds like all MPLS-TP must use a single common value of EL. Thus is surely not the case. The requirement is that all packets for a particular MPLS-TP LSP must use a common EL value, but other MPLS-TP LSP may use a different value, and indeed there is good reason to encourage them to do so. I think that you later get to this point, but I find the text that you are using to build the case for the ELI quite confusing. "MPLS-TP LSPs can be carried as client LSPs within an MPLS server LSP if an Entropy Label Indicator (ELI) and Entropy Label (EL) is pushed below the server layer LSP label(s) in the label stack, just above the MPLS-TP LSP label entry [RFC6790]." I think that you need to clarify that this does not mean that the client needs to do this, the server can and should do it. "An MPLS-TP LSP must not traverse a server layer MPLS LSP which traverses any form of multipath not supporting termination of the entropy search at the EL label." Surely that is a protocol correctness MUST NOT? Then I think in the next sentence "the ingress LSR MUST be aware." There surely needs to be a requirements and some discussion on bi-directional co-routing, since this is not natural in MPLS. "however a change in path should not occur solely for load balancing." Since this is saying - please don't do it because you will break MPLS-TP's invariant, I think that needs SHOULD NOT with appropriate sentence rewording if needed. |
|
2014-01-22
|
03 | Stewart Bryant | [Ballot comment] I am wondering if it would be useful to discuss the case where it is desired to get MPLS-TP over MPLS, but load … [Ballot comment] I am wondering if it would be useful to discuss the case where it is desired to get MPLS-TP over MPLS, but load balancing is not needed. At first thought one might believe that all that is needed is to defeat ECMP with an intermediate control word. However the presence of L13 will be a problem. However a CW and a direct mapping of the MPLS-TP OAM to the PW-ACH would be a stateless mapping. I raise this point in response to the note that their are few networks that support ELI end to end, in which case the alternative mapping described above might be useful. I notice that Curtis is the sole author and yet is noted as editor, is this intentional. |
|
2014-01-22
|
03 | Stewart Bryant | [Ballot Position Update] New position, Discuss, has been recorded for Stewart Bryant |
|
2014-01-21
|
03 | Spencer Dawkins | [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins |
|
2014-01-21
|
03 | Jari Arkko | [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko |
|
2014-01-21
|
03 | Benoît Claise | [Ballot comment] - 2. Definitions Please refer to the terminology related to multipath introduced in [I-D.ietf-rtgwg-cl-requirement]. I trust that draft-ietf-rtgwg-cl-requirement, which is … [Ballot comment] - 2. Definitions Please refer to the terminology related to multipath introduced in [I-D.ietf-rtgwg-cl-requirement]. I trust that draft-ietf-rtgwg-cl-requirement, which is work in progress, is quite stable, right? - IPFRR should be expanded, and I need a reference. Below is David Black's OPS DIR review I have reviewed this document as part of the operations directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the operations area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Summary: This draft is on the right track but has open issues, described in the review. I apologize for this review showing up a couple of days after the end of IETF Last Call. This draft discusses considerations for what are effectively MPLS-in-MPLS tunnels for multipathing - an LSP carries another LSP, with the inner (client) LSPs being distributed across multiple outer (server) LSPs that use different paths. This draft is motivated by considerations specific to MPLS-TP that complicate multipathing when one of the two MPLS instances is MPLS-TP. I consider the following to be open issues that need attention (each letter is used to tag the issue in the text that follows - [B] occurs multiple times, as there are multiple aspect to that issue): [A] Summary text in Introduction appears to be wrong. [B] Section 3.2 needs a summary. [C] Entropy label "sandwich" seems peculiar and at least needs an explanation. [D] Discussion of multipath impacts on MPLS OAM should be added to Section 4. --- Comments on draft text [A] Section 1 (Introduction) 2nd paragraph: RFC 5654 requirement 33 requires the capability to carry a client MPLS-TP or MPLS layer over a server MPLS-TP or MPLS layer [RFC5654]. This is possible in all cases with one exception. When an MPLS LSP exceeds the capacity of any single component link it MAY be carried by a network using multipath techniques, but MAY NOT be carried by a single MPLS-TP LSP due to the inherent MPLS-TP capacity limitation imposed by MPLS-TP Operations, Administration, and Maintenance (OAM) fate sharing constraints and MPLS-TP LM OAM packet ordering constraints (see Section 3.1). Section 3.1 concerns carrying MPLS-TP over MPLS, whereas the above exception appears to concern the reverse, and Section 4 on carrying MPLS over MPLS-TP allows for MPLS LSPs that exceed component link capacity. Was the exception intended to be for an MPLS-TP LSP that exceeds the capacity of any single component link? Also, "MAY NOT" is not an RFC 2119 term (for good reason - it's equivalent to "MAY OR MAY NOT"). I think "cannot" was intended her, but "MUST NOT" is another possibility. [B] Section 3.2 contains a lot of useful details, but it could really use a summary at the end on the options and recommendations for meeting the four requirements (this summary could be a new Section 3.3). It's a bit difficult to discern what's going on, as I had to read this section more than once in order to discern the following: [C] In Section 3.2, use of an MPLS entropy label to meet requirement MP#1 requires that it be "below the MPLS-TP label" whereas, to meet requirement MP#2, the MPLS entropy label needs to be "just above the MPLS-TP LSP label". This combination appears to suggest "sandwiching" the MPLS-TP label between two entropy labels that effectively carry the same information (albeit, applied and removed at different places in the network) - was that intended? This is important, as there seems to be no reasonable alternative to the entropy label for meeting requirement MP#2, and the draft's alternative to the entropy label for meeting requirement MP#1 is "some form of configuration" - the entropy label would seem to be preferred to that based on my reading of this draft and the comment in RFC 5706 section 2.2 that "Anything that can be configured can be misconfigured." [B] A summary of requirements for implementation and deployment at the end of Section 3.2 would have made this much more obvious. That should be provided in addition to addressing the above question about duplicate use of the MPLS entropy label. --- Relevant Q&A based on RFC 5706 Appendix A I'm omitting management concerns, as both MPLS and MPLS-TP have extensive management infrastructure, and this draft's notion of stacking LSPs so that one instance of MPLS (or MPLS-TP) can be a server to (i.e., carry) another is not novel to this draft. A.1.1. Has deployment been discussed? [B] Yes, although Section 3.2 is weak on deployment requirements (some of which are implementation requirements) and could use a summary. A.1.2. Has installation and initial setup been discussed? No, although because this draft reuses existing functionality in different configurations, this really reduces to the A.1.9 configuration question below. In practice, quite a bit of operator knowledge and insight is required to get initial setup right, e.g., as traffic engineering LSPs to avoid congestion problems (needed to meet requirement MP#3) requires significant knowledge of network structure and expected traffic flows. This should be obvious to anyone who works w/MPLS, but it's probably worth stating for completeness. A.1.6. Have suggestions for verifying correct operation been discussed? Yes and no. Section 3.2 discusses OAM, and contains this important requirement for OAM traffic: An Entropy Label must be used to insure that all of the MPLS-TP payload and OAM traffic are carried on the same component, except during very infrequent transitions due to load balancing. [D] OTOH, there is no discussion of OAM traffic for the MPLS LSP in Section 4; that should be added. A.1.9. Is configuration discussed? [B] Not much. Configuration is required to meet requirements MP#3 and MP#4, and is one of the options for MP#1. A summary of what has to be configured as part of the summary at the end of Section 3.2 would be a good idea. A.2.* [skipped, see above] A.3 Documentation There's quite a bit of operational material contained in this draft; a separate section on operations and management considerations would not be appropriate. There is a useful implementation status section which appears to imply that MPLS-TP over MPLS is not currently deployable due to absence of entropy label support, and because deployed MPLS equipment does not generally support multipathing. Nonetheless, data center experience indicates significant value and widespread use of multipathing based on link aggregation and ECMP; corresponding benefits can be expected for use of multipathing in the Internet beyond data centers. --- Editorial comments/nits: - Section 3.1, after RFC 5960 quotes: [RFC5960] paragraph 3 requires that packets within a specific ordered Insert "Section 3.1.1., before "paragraph 3" and likewise for "paragraph 6" later in the same paragraph in the draft. - Section 3.2, requirement MP#3: MP#3 It SHOULD be possible to insure that MPLS-TP LSPs will not be "insure" -> "ensure" or "assure". Surely this draft does not envision operators taking out insurance policies on MPLS TP LSP behavior . - Section 3.2, last paragraph on p.8: An MPLS-TP LSP may not traverse multipath links on the path where MPLS-TP forwarding requirements cannot be met. "may not" is meaningless - I believe "MUST NOT" was intended here. - Section 4, middle of 3rd para: Editorial suggestions for clarity: OLD For those LSP that are larger than component link capacity, their capacity are not integer multiples of convenient capacity increments such as 10Gb/s. NEW For those LSPs that are larger than a component link capacity, the LSP capacities need not be (and often are not) integer multiples of convenient capacity increments such as 10Gb/s. In particular, "are not" seems wrong, as the "integer multiples" case is possible, so I changed "are not" to "need not be (and often are not)" in the suggested new text. |
|
2014-01-21
|
03 | Benoît Claise | [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise |
|
2014-01-21
|
03 | Martin Stiemerling | [Ballot comment] No objection from my side, but idnits is rightfully yelling: == The expression 'MAY NOT', while looking like RFC 2119 requirements text, … [Ballot comment] No objection from my side, but idnits is rightfully yelling: == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: RFC 5654 requirement 33 requires the capability to carry a client MPLS-TP or MPLS layer over a server MPLS-TP or MPLS layer [RFC5654]. This is possible in all cases with one exception. When an MPLS LSP exceeds the capacity of any single component link it MAY be carried by a network using multipath techniques, but MAY NOT be carried by a single MPLS-TP LSP due to the inherent MPLS-TP capacity limitation imposed by MPLS-TP Operations, Administration, and Maintenance (OAM) fate sharing constraints and MPLS-TP LM OAM packet ordering constraints (see Section 3.1). |
|
2014-01-21
|
03 | Martin Stiemerling | [Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling |
|
2014-01-21
|
03 | Barry Leiba | [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba |
|
2014-01-18
|
03 | Peter Yee | Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Peter Yee. |
|
2014-01-17
|
03 | Adrian Farrel | Ballot has been issued |
|
2014-01-17
|
03 | Adrian Farrel | [Ballot Position Update] New position, Yes, has been recorded for Adrian Farrel |
|
2014-01-17
|
03 | Adrian Farrel | Created "Approve" ballot |
|
2014-01-17
|
03 | Adrian Farrel | State changed to IESG Evaluation from Waiting for AD Go-Ahead |
|
2014-01-17
|
03 | Adrian Farrel | Changed consensus to Yes from Unknown |
|
2014-01-17
|
03 | (System) | State changed to Waiting for AD Go-Ahead from In Last Call (ends 2014-01-17) |
|
2014-01-12
|
03 | Adrian Farrel | Placed on agenda for telechat - 2014-01-23 |
|
2014-01-09
|
03 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Alan DeKok |
|
2014-01-09
|
03 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Alan DeKok |
|
2014-01-06
|
03 | (System) | IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed |
|
2014-01-06
|
03 | Amanda Baber | IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-mpls-multipath-use, which is currently in Last Call, and has the following comments: We understand that this document doesn't require … IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-mpls-multipath-use, which is currently in Last Call, and has the following comments: We understand that this document doesn't require any IANA actions. IANA requests that the IANA Considerations section of the document remain in place upon publication. If this assessment is not accurate, please respond as soon as possible. |
|
2014-01-02
|
03 | Jean Mahoney | Request for Last Call review by GENART is assigned to Peter Yee |
|
2014-01-02
|
03 | Jean Mahoney | Request for Last Call review by GENART is assigned to Peter Yee |
|
2014-01-02
|
03 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to David Black |
|
2014-01-02
|
03 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to David Black |
|
2014-01-02
|
03 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
|
2014-01-02
|
03 | 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-multipath-use-03.txt> (Use of Multipath with MPLS and MPLS-TP) to Informational RFC The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'Use of Multipath with MPLS and MPLS-TP' <draft-ietf-mpls-multipath-use-03.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-01-17. 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 Many MPLS implementations have supported multipath techniques and many MPLS deployments have used multipath techniques, particularly in very high bandwidth applications, such as provider IP/MPLS core networks. MPLS-TP has strongly discouraged the use of multipath techniques. Some degradation of MPLS-TP OAM performance cannot be avoided when operating over many types of multipath implementations. Using MPLS Entropy label, MPLS Label Switched Paths (LSPs) can be carried over multipath links while also providing a fully MPLS-TP compliant server layer for MPLS-TP LSPs. This document describes the means of supporting MPLS as a server layer for MPLS-TP. The use of MPLS-TP LSPs as a server layer for MPLS LSPs is also discussed. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-mpls-multipath-use/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-mpls-multipath-use/ballot/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/1593/ |
|
2014-01-02
|
03 | Amy Vezza | State changed to In Last Call from Last Call Requested |
|
2013-12-30
|
03 | Adrian Farrel | Last call was requested |
|
2013-12-30
|
03 | Adrian Farrel | Ballot approval text was generated |
|
2013-12-30
|
03 | Adrian Farrel | State changed to Last Call Requested from AD Evaluation |
|
2013-12-30
|
03 | Adrian Farrel | Last call announcement was changed |
|
2013-12-30
|
03 | Adrian Farrel | Last call announcement was generated |
|
2013-12-30
|
03 | Adrian Farrel | Ballot writeup was changed |
|
2013-12-30
|
03 | Adrian Farrel | Ballot writeup was generated |
|
2013-12-30
|
03 | Adrian Farrel | State changed to AD Evaluation from Publication Requested |
|
2013-11-16
|
03 | Loa Andersson | The MPLS working group request that: Use of Multipath with MPLS and MPLS-TP … The MPLS working group request that: Use of Multipath with MPLS and MPLS-TP draft-ietf-mpls-multipath-use-03 Is published as an Informational RFC As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 24 February 2012. (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? The requested type of RFC is Informational. This document does not specify any protocol or mechanisms, but discusses some mechanisms we have, how they have been used and gives recommendations on how they could and should be used. The type of RFC is clearly indicated in the document header. (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 Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. Many MPLS implementations have supported multipath techniques and many MPLS deployments have used multipath techniques, particularly in very high bandwidth applications, such as provider IP/MPLS core networks. MPLS-TP has strongly discouraged the use of multipath techniques. Some degradation of MPLS-TP OAM performance cannot be avoided when operating over many types of multipath implementations. Using MPLS Entropy label, MPLS Label Switched Paths (LSPs) can be carried over multipath links while also providing a fully MPLS-TP compliant server layer for MPLS-TP LSPs. This document describes the means of supporting MPLS as a server layer for MPLS-TP. The use of MPLS-TP LSPs as a server layer for MPLS LSPs is also discussed. 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? Nothing in particular to note, no controversies and the working is solidlybehind this document. Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? This is an Informational document that has been well reviewed in the working, but not external reviews have been necessary. As part of the working group reviews it has also been reviewed by the MPLS review team (MPLS-RT) prior to adoption as a working group document. No specific implementation review has been done on this document since we don't expect any direct vendor implementations of the document; instead the document discusses how the mechanisms that have been implemented can be use. We know of operators that has deployed the techniques discussed in the document. The MPLS-RT reviewers has been Mach Chen, Markus Jork, David Allan and Carlos Pignataro. Personnel Who is the Document Shepherd? Who is the Responsible Area Director? Loa Andersson is the Document Shepherd Adrian Farrel is the Responsible Area Director (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 reviewed the document in full three times, prior to that the document were accepted as a working group document, in preparation for working group last cal and the updated document after working group last call. (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 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. No such concerns. The working group is behind this document. (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. The author has stated that he is unaware of any IPRs related to 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 IPRs has been filed against this document. The data-tracker list one potential IPR; however this is not correct. This document in a very wide sense "replaced" an earlier document that addressed the same issues. This document is not a direct successor of the earlier document but has been re-worked in such away that the IPR disclosure is no relevant for this document. The party that filed the first IPR has not re-disclosed for 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? This document is pretty much mainstream MPLS, and there is a very good support for the document. (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 tool says that this document use RFC 2119 language, but does not have a reference to RFC 2119. The reference is in the document. The nits tool also correctly says that "MAY NOT" is not RFC 2119 language; this will be updated to proper RFC 2119 language if a revised ID is needed for other reasons of through an RFC Editors note. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. No formal review needed. (13) Have all references within this document been identified as either normative or informative? Yes - all the references has been correctly identified. (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 RFCs. (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. No other RFC will be changed when this document is published. (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). This document include no request for IANA actions. (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. There are no new registries that require expert review. (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 checks necessary. |
|
2013-11-14
|
03 | Loa Andersson | IETF WG state changed to Submitted to IESG for Publication |
|
2013-11-14
|
03 | Loa Andersson | IESG state changed to Publication Requested |
|
2013-11-14
|
03 | Loa Andersson | The MPLS working group request that: Use of Multipath with MPLS and MPLS-TP … The MPLS working group request that: Use of Multipath with MPLS and MPLS-TP draft-ietf-mpls-multipath-use-03 Is published as an Informational RFC As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 24 February 2012. (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? The requested type of RFC is Informational. This document does not specify any protocol or mechanisms, but discusses some mechanisms we have, how they have been used and gives recommendations on how they could and should be used. The type of RFC is clearly indicated in the document header. (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 Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. Many MPLS implementations have supported multipath techniques and many MPLS deployments have used multipath techniques, particularly in very high bandwidth applications, such as provider IP/MPLS core networks. MPLS-TP has strongly discouraged the use of multipath techniques. Some degradation of MPLS-TP OAM performance cannot be avoided when operating over many types of multipath implementations. Using MPLS Entropy label, MPLS Label Switched Paths (LSPs) can be carried over multipath links while also providing a fully MPLS-TP compliant server layer for MPLS-TP LSPs. This document describes the means of supporting MPLS as a server layer for MPLS-TP. The use of MPLS-TP LSPs as a server layer for MPLS LSPs is also discussed. 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? Nothing in particular to note, no controversies and the working is solidlybehind this document. Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? This is an Informational document that has been well reviewed in the working, but not external reviews have been necessary. As part of the working group reviews it has also been reviewed by the MPLS review team (MPLS-RT) prior to adoption as a working group document. No specific implementation review has been done on this document since we don't expect any direct vendor implementations of the document; instead the document discusses how the mechanisms that have been implemented can be use. We know of operators that has deployed the techniques discussed in the document. Personnel Who is the Document Shepherd? Who is the Responsible Area Director? Loa Andersson is the Document Shepherd Adrian Farrel is the Responsible Area Director (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 reviewed the document in full three times, prior to that the document were accepted as a working group document, in preparation for working group last cal and the updated document after working group last call. (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 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. No such concerns. The working group is behind this document. (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. The author has stated that he is unaware of any IPRs related to 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 IPRs has been filed against this document. The data-tracker list one potential IPR; however this is not correct. This document in a very wide sense "replaced" an earlier document that addressed the same issues. This document is not a direct successor of the earlier document but has been re-worked in such away that the IPR disclosure is no relevant for this document. The party that filed the first IPR has not re-disclosed for 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? This document is pretty much mainstream MPLS, and there is a very good support for the document. (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 tool says that this document use RFC 2119 language, but does not have a reference to RFC 2119. The reference is in the document. The nits tool also correctly says that "MAY NOT" is not RFC 2119 language; this will be updated to proper RFC 2119 language if a revised ID is needed for other reasons of through an RFC Editors note. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. No formal review needed. (13) Have all references within this document been identified as either normative or informative? Yes - all the references has been correctly identified. (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 RFCs. (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. No other RFC will be changed when this document is published. (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). This document include no request for IANA actions. (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. There are no new registries that require expert review. (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 checks necessary. |
|
2013-11-14
|
03 | Loa Andersson | State Change Notice email list changed to mpls-chairs@tools.ietf.org, draft-ietf-mpls-multipath-use@tools.ietf.org |
|
2013-11-14
|
03 | Loa Andersson | Responsible AD changed to Adrian Farrel |
|
2013-11-14
|
03 | Loa Andersson | Working group state set to Submitted to IESG for Publication |
|
2013-11-14
|
03 | Loa Andersson | IESG state set to Publication Requested |
|
2013-11-14
|
03 | Loa Andersson | IESG process started in state Publication Requested |
|
2013-11-14
|
03 | Loa Andersson | Annotation tag Revised I-D Needed - Issue raised by WGLC cleared. |
|
2013-11-14
|
03 | Loa Andersson | Changed document writeup |
|
2013-11-14
|
03 | Loa Andersson | Changed document writeup |
|
2013-11-14
|
03 | Loa Andersson | Intended Status changed to Informational from None |
|
2013-11-13
|
03 | Curtis Villamizar | New version available: draft-ietf-mpls-multipath-use-03.txt |
|
2013-10-25
|
02 | Loa Andersson | IETF WG state changed to Waiting for WG Chair Go-Ahead from In WG Last Call |
|
2013-10-25
|
02 | Loa Andersson | Annotation tag Revised I-D Needed - Issue raised by WGLC set. Annotation tag Other - see Comment Log cleared. |
|
2013-10-12
|
02 | Loa Andersson | The data-tracker identifies one IPR disclosure (# 1593), but this IPR was disclosed against an earlier document that this document replaces; the author has indicated … The data-tracker identifies one IPR disclosure (# 1593), but this IPR was disclosed against an earlier document that this document replaces; the author has indicated that one reason why the earlier document were replaced was to avoid the IPR. |
|
2013-10-12
|
02 | Loa Andersson | IETF WG state changed to In WG Last Call from WG Document |
|
2013-10-10
|
02 | Loa Andersson | IPR poll is running! |
|
2013-10-10
|
02 | Loa Andersson | IETF WG state changed to WG Document from WG Document |
|
2013-10-10
|
02 | Loa Andersson | Annotation tag Other - see Comment Log set. |
|
2013-10-09
|
02 | Loa Andersson | Document shepherd changed to Loa Andersson |
|
2013-10-09
|
02 | Curtis Villamizar | New version available: draft-ietf-mpls-multipath-use-02.txt |
|
2013-09-11
|
01 | Curtis Villamizar | New version available: draft-ietf-mpls-multipath-use-01.txt |
|
2013-02-25
|
00 | Stephanie McCammon | New version available: draft-ietf-mpls-multipath-use-00.txt |