Skip to main content

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