Skip to main content

MPLS Transport Profile (MPLS-TP) Linear Protection
RFC 6378

Revision differences

Document history

Date Rev. By Action
2018-12-20
09 (System)
Received changes through RFC Editor sync (changed abstract to 'This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunications …
Received changes through RFC Editor sync (changed abstract to 'This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunications Union Telecommunications Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge (PWE3) architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T.

This document addresses the functionality described in the MPLS-TP Survivability Framework document (RFC 6372) and defines a protocol that may be used to fulfill the function of the Protection State Coordination for linear protection, as described in that document. [STANDARDS-TRACK]')
2015-10-14
09 (System) Notify list changed from mpls-chairs@ietf.org, draft-ietf-mpls-tp-linear-protection@ietf.org to (None)
2012-08-22
09 (System) post-migration administrative database adjustment to the No Objection position for Sean Turner
2012-08-22
09 (System) post-migration administrative database adjustment to the No Objection position for Dan Romascanu
2012-08-22
09 (System) post-migration administrative database adjustment to the No Objection position for Stephen Farrell
2012-08-22
09 (System) post-migration administrative database adjustment to the Yes position for Adrian Farrel
2011-11-01
09 Amy Vezza State changed to RFC Published from RFC Ed Queue.
2011-10-31
09 (System) RFC published
2011-08-26
09 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2011-08-26
09 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2011-08-26
09 (System) IANA Action state changed to In Progress from Waiting on Authors
2011-08-25
09 (System) IANA Action state changed to Waiting on Authors from In Progress
2011-08-25
09 (System) IANA Action state changed to In Progress from Waiting on Authors
2011-08-19
09 (System) IANA Action state changed to Waiting on Authors from In Progress
2011-08-11
09 Cindy Morgan State changed to RFC Ed Queue from Approved-announcement sent.
2011-08-10
09 (System) IANA Action state changed to In Progress
2011-08-10
09 Amy Vezza IESG state changed to Approved-announcement sent
2011-08-10
09 Amy Vezza IESG has approved the document
2011-08-10
09 Amy Vezza Closed "Approve" ballot
2011-08-10
09 Adrian Farrel Approval announcement text changed
2011-08-10
09 Adrian Farrel Approval announcement text regenerated
2011-08-10
09 Adrian Farrel Ballot writeup text changed
2011-08-09
09 Stephen Farrell
[Ballot comment]
The first part of the discuss was fixed - thanks.

Adrian now owes me a beer for not explaining something
or other to …
[Ballot comment]
The first part of the discuss was fixed - thanks.

Adrian now owes me a beer for not explaining something
or other to do with this draft and the 2nd part of my discuss
in Quebec - given that I'm sure he's right and I get a beer,
I've cleared :-)
2011-08-09
09 Stephen Farrell [Ballot Position Update] Position for Stephen Farrell has been changed to No Objection from Discuss
2011-08-04
09 Adrian Farrel [Ballot comment]
Thank you for your work to resolve Lou's concerns.
2011-08-04
09 Adrian Farrel [Ballot Position Update] Position for Adrian Farrel has been changed to Yes from Discuss
2011-08-03
09 (System) New version available: draft-ietf-mpls-tp-linear-protection-09.txt
2011-08-01
09 Dan Romascanu
[Ballot comment]
1. In Section 3.1:

OAM indication - OAM fault management or performance measurement 
      tools may detect a failure or degrade …
[Ballot comment]
1. In Section 3.1:

OAM indication - OAM fault management or performance measurement 
      tools may detect a failure or degrade condition on either the   
      working or protection transport path and this must input an 
      indication to the Local Request Logic.

better s/must/MUST/

2. In Section 4.1:

      The actual frequencies used may be 
      configurable, at the time of establishment, for each individual 
      protected LSP.  For management purposes, the operator should be able 
      to retrieve the current default frequency values as well as the 
      actual values for any specific LSP.

In the first sentence better s/may/MAY/
In the second sentence better s/should/SHOULD/
2011-08-01
09 Dan Romascanu
[Ballot comment]
1. In Section 3.1:

OAM indication - OAM fault management or performance measurement 
      tools may detect a failure or degrade …
[Ballot comment]
1. In Section 3.1:

OAM indication - OAM fault management or performance measurement 
      tools may detect a failure or degrade condition on either the   
      working or protection transport path and this must input an 
      indication to the Local Request Logic.

better s/must/MUST/

2. In Section 4.1:

      The actual frequencies used may be 
      configurable, at the time of establishment, for each individual 
      protected LSP.  For management purposes, the operator should be able 
      to retrieve the current default frequency values as well as the 
      actual values for any specific LSP.

In the first sentence better s/may/MAY/
In the second sentence better s/should/SHOULD/

3.
2011-08-01
09 Dan Romascanu [Ballot Position Update] Position for Dan Romascanu has been changed to No Objection from Discuss
2011-07-27
09 Sean Turner
[Ballot discuss]
This is an updated discuss (hoping I just missed this)

#1) cleared

#2) cleared

#3) cleared

#4) RFC 5586 says that the ACH …
[Ballot discuss]
This is an updated discuss (hoping I just missed this)

#1) cleared

#2) cleared

#3) cleared

#4) RFC 5586 says that the ACH is in network byte order, but doesn't say anything about the encoding for ACH TLVs.  Maybe this draft should explicitly state that the TLV is encoded in network byte order (or is this stated somewhere else in the MPLS suite of RFC+drafts)?
2011-07-27
09 Sean Turner [Ballot Position Update] Position for Sean Turner has been changed to No Objection from Discuss
2011-07-25
09 (System) Sub state has been changed to AD Follow up from New Id Needed
2011-07-25
08 (System) New version available: draft-ietf-mpls-tp-linear-protection-08.txt
2011-07-14
09 Cindy Morgan Removed from agenda for telechat
2011-07-14
09 Cindy Morgan State changed to IESG Evaluation::Revised ID Needed from IESG Evaluation.
2011-07-14
09 David Harrington [Ballot Position Update] New position, No Objection, has been recorded
2011-07-14
09 Stephen Farrell
[Ballot discuss]
(1) I can't find section 4.7 of [SurvivFwk] which is
where you promise a definition of linear protection.
Suggest fixing the ref but …
[Ballot discuss]
(1) I can't find section 4.7 of [SurvivFwk] which is
where you promise a definition of linear protection.
Suggest fixing the ref but also adding at least a
short description.

(2) I didn't have time to follow all the references
from the security considerations (sorry). Do those
provide a way to authenticate the messages from this
protocol so as to prevent a bad actor from switching
traffic to somewhere they want to monitor or somewhere
with less capacity (as part of a Dos)?
2011-07-14
09 Stephen Farrell [Ballot Position Update] New position, Discuss, has been recorded
2011-07-14
09 Jari Arkko [Ballot Position Update] New position, No Objection, has been recorded
2011-07-14
09 Adrian Farrel State changed to IESG Evaluation from Waiting for AD Go-Ahead.
2011-07-14
09 Sean Turner
[Ballot comment]
#1) Section 1.1: r/compared to other survivability mechanisms/, compared to other survivability mechanisms (e.g., ... ).

Isn't it kind of an empty claim …
[Ballot comment]
#1) Section 1.1: r/compared to other survivability mechanisms/, compared to other survivability mechanisms (e.g., ... ).

Isn't it kind of an empty claim otherwise?  The survivability draft only claims:

  In a mesh network, linear protection
  provides a very suitable protection mechanism because it can operate
  between any pair of points within the network.

#2) Expand P2P on first use.

#3) In Section 4.2.2, I think it would aid the reader greatly to add a pointer to registry in Section 5.2?  When I read 4.2.2, the first thought that popped in to my mind was: well what about all the other values are they reserved?  It's probably also worth point out that values are assigned by IANA.
2011-07-14
09 Sean Turner
[Ballot discuss]
Some more from the obviously uninformed reader...

#1) Section 4.2.2, I thought this section would also say something along the lines of "other …
[Ballot discuss]
Some more from the obviously uninformed reader...

#1) Section 4.2.2, I thought this section would also say something along the lines of "other values are ignored by this version of the protocol".

#2) Section 4.2.5 & 4.2.6: Shouldn't there be a registry for FPath and Path values?

#3) In Section 4.2.7, should it also say that the reserved fields "MUST be ignored on receipt"?

#4) RFC 5586 says that the ACH is in network byte order, but doesn't say anything about the encoding for ACH TLVs.  Maybe this draft should explicitly state that the TLV is encoded in network byte order (or is this stated somewhere else in the MPLS suite of RFC+drafts)?
2011-07-14
09 Sean Turner [Ballot Position Update] New position, Discuss, has been recorded
2011-07-14
09 Pete Resnick [Ballot Position Update] New position, No Objection, has been recorded
2011-07-13
09 Gonzalo Camarillo [Ballot Position Update] New position, No Objection, has been recorded
2011-07-13
09 Peter Saint-Andre [Ballot Position Update] New position, No Objection, has been recorded
2011-07-13
09 Wesley Eddy [Ballot Position Update] New position, No Objection, has been recorded
2011-07-13
09 Robert Sparks [Ballot Position Update] New position, No Objection, has been recorded
2011-07-13
09 Ron Bonica [Ballot Position Update] New position, No Objection, has been recorded
2011-07-13
09 Dan Romascanu
[Ballot discuss]
The DISCUSS and COMMENT is partially based on the OPS-DIR review performed by Bert Wijnen:

1. in section 3.1:


  o  OAM indication …
[Ballot discuss]
The DISCUSS and COMMENT is partially based on the OPS-DIR review performed by Bert Wijnen:

1. in section 3.1:


  o  OAM indication - OAM fault management or performance measurement
      tools may detect a failure or degrade condition on either the
      working or protection transport path and this SHOULD input an
      indication to the Local Request Logic.

Why is this only a SHOULD and not a MUST? If there are exception cases I suggest to detail them.

2. Same question about the next bullet:

o  WTR expires - The Wait-to-Restore timer is used in conjunction
      with recovery from failure conditions on the working path in
      revertive mode.  The timer SHALL signal the PSC control process
      when it expires and the end point SHOULD revert to the normal
      transmission of the user data traffic.

3. in section 4.1:

    The frequency of the three rapid messages and the separate frequency
    of the continual transmission SHOULD be configurable by the operator.
    For protection switching within 50ms, it is RECOMMENDED that the
    default interval of the first three PSC messages SHOULD be no larger
    than 3.3ms.  The subsequent messages SHOULD be continuously
    transmitted with an interval of 5 seconds.

It might be good to explain the rationale for the RECOMMENDED intervals and maybe some explanation as to what considerations need to be taken into account when configuring these values. Has the WG considered to standardize the configurability of these frequencies? Or is it left (intentionally?) to each implementation how this is done?
Can an operator (or an NMS) easily see what the values are at the various LERs?

4. In section 4.3.3.1 and 4.3.3,2 the description of the transitions of the Normal State and Unavailable State end by 'All other local inputs SHALL be ignored.' and 'All other remote messages SHALL be ignored'. In 4.3.3.3 'Protecting administrative state' we have 'All other local inputs SHALL be ignored.' but 'All other remote messages SHOULD be ignored.' In 4.3.3.4.  Protecting failure state, 4.3.3.5.  Wait-to-restore state, and 4.3.3.6.  Do-not-revert state the lists of transitions end with 'All other local inputs SHOULD be ignored.' and 'All other remote messages SHOULD be ignored.' Why SHOULD and not SHALL, what are the exception cases and the recommended behavior?
2011-07-13
09 Dan Romascanu [Ballot Position Update] New position, Discuss, has been recorded
2011-07-12
09 Russ Housley [Ballot Position Update] New position, No Objection, has been recorded
2011-07-12
09 Stewart Bryant [Ballot Position Update] New position, Recuse, has been recorded
2011-07-11
09 Adrian Farrel [Ballot discuss]
Significant Routing Directorate review comments from Lou Berger need to be resolved before this document can be approved
2011-07-11
09 Adrian Farrel [Ballot Position Update] Position for Adrian Farrel has been changed to Discuss from Yes
2011-07-11
09 Adrian Farrel [Ballot Position Update] New position, Yes, has been recorded for Adrian Farrel
2011-07-11
09 Adrian Farrel Ballot has been issued
2011-07-11
09 Adrian Farrel Created "Approve" ballot
2011-07-06
09 Amanda Baber
IANA understands that, upon approval of this document, there are two
IANA actions which must be completed.

First, in the Pseudowire Associated Channel Types Registry …
IANA understands that, upon approval of this document, there are two
IANA actions which must be completed.

First, in the Pseudowire Associated Channel Types Registry located in
the Pseudowire Name Spaces located at:

http://www.iana.org/assignments/pwe3-parameters/pwe3-parameters.xml

a new registration will be added as follows:

Value Description TLV Follows Reference
----- ----------------------- ----------- ---------------
0xHH Protection State no [this document]
Coordination Protocol -
Channel Type (PSC-CT)

Second, IANA will create a new registry in the Multiprotocol Label
Switching Architecture (MPLS) Identifier Types registry located at:

http://www.iana.org/assignments/mpls-id-type/mpls-id-type.xml

as follows:

Registry name: "MPLS PSC Request Registry"
Registration procedure: Standards action
Values: the field is four bits in length
Reference: [ RFC-to-be ]

The initial registrations in this new registry are as follows:

Value Description Reference
------------- --------------------- ---------------
b0000 No Request [ RFC-to-be ]
b0001 Do not revert [ RFC-to-be ]
b0010 - b0011 Unassigned
b0100 Wait to restore [ RFC-to-be ]
b0101 Manual switch [ RFC-to-be ]
b0110 Unassigned
b0111 Signal Degrade [ RFC-to-be ]
b1000 - b1001 Unassigned
b1010 Signal Fail [ RFC-to-be ]
b1011 Unassigned
b1100 Forced switch [ RFC-to-be ]
b1101 Unassigned
b1110 Lockout of protection [ RFC-to-be ]
b1111 Unassigned

IANA understands that these are the only actions required to be
completed upon approval of this document.
2011-07-05
09 (System) State changed to Waiting for AD Go-Ahead from In Last Call.
2011-06-23
09 Samuel Weiler Request for Last Call review by SECDIR is assigned to Larry Zhu
2011-06-23
09 Samuel Weiler Request for Last Call review by SECDIR is assigned to Larry Zhu
2011-06-21
09 Amy Vezza Last call sent
2011-06-21
09 Amy Vezza
State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: …
State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (MPLS-TP Linear Protection) to Proposed Standard


The IESG has received a request from the Multiprotocol Label Switching WG
(mpls) to consider the following document:
- 'MPLS-TP Linear Protection'
  as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2011-07-05. 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


  The Transport Profile for Multiprotocol Label Switching (MPLS-TP) is
  being specified jointly by IETF and ITU-T.  This document addresses
  the functionality described in the MPLS-TP Survivability Framework
  document [SurvivFwk] and defines a protocol that may be used to
  fulfill the function of the Protection State Coordination for linear
  protection, as described in that document.

  This document is a product of a joint Internet Engineering Task Force
  (IETF) / International Telecommunications Union Telecommunications
  Standardization Sector (ITU-T) effort to include an MPLS Transport
  Profile within the IETF MPLS and PWE3 architectures to support the
  capabilities and functionalities of a packet transport network as
  defined by the ITU-T.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-linear-protection/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-linear-protection/


No IPR declarations have been submitted directly on this I-D.


2011-06-21
09 Adrian Farrel Placed on agenda for telechat - 2011-07-14
2011-06-21
09 Adrian Farrel Last Call was requested
2011-06-21
09 Adrian Farrel State changed to Last Call Requested from AD Evaluation.
2011-06-21
09 Adrian Farrel Last Call text changed
2011-06-21
09 (System) Ballot writeup text was added
2011-06-21
09 (System) Last call text was added
2011-06-21
09 (System) Ballot approval text was added
2011-06-21
09 Adrian Farrel Ballot writeup text changed
2011-06-20
09 Adrian Farrel State changed to AD Evaluation from Publication Requested.
2011-06-14
09 Loa Andersson submitted 2011-06-14
2011-06-14
09 Loa Andersson IETF state changed to Submitted to IESG for Publication from Waiting for WG Chair Go-Ahead
2011-06-13
09 Cindy Morgan
PROTO writeup for  draft-ietf-mpls-tp-linear-protection-07.txt

  (1.a) Who is the Document Shepherd for this document? Has the
        Document Shepherd personally reviewed this …
PROTO writeup for  draft-ietf-mpls-tp-linear-protection-07.txt

  (1.a) Who is the Document Shepherd for this document? Has the
        Document Shepherd personally reviewed this version of the
        document and, in particular, does he or she believe this
        version is ready for forwarding to the IESG for publication?

Ross Callon is the Document Shepherd. He has reviewed the document and believes that it is ready to be forwarded to the IESG for publication.

  (1.b) Has the document had adequate review both from key WG members
        and from key non-WG members? Does the Document Shepherd have
        any concerns about the depth or breadth of the reviews that
        have been performed? 

The document has been extensively reviewed by MPLS WG experts as well as by ITU-T. The document has been updated to reflect the comments received and an email summarizing the status of last call comments has been posted to the MPLS WG email list.

  (1.c) Does the Document Shepherd have concerns that the document
        needs more review from a particular or broader perspective,
        e.g., security, operational complexity, someone familiar with
        AAA, internationalization or XML?

No concerns. The review has been very thorough.

  (1.d) Does the Document Shepherd have any specific concerns or
        issues with this document that the Responsible Area Director
        and/or the IESG should be aware of?

No concerns.

  (1.e) 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? 
Consensus is solid. This document describes mechanisms that are quite important for MPLS-TP networks.

  (1.f) Has anyone threatened an appeal or otherwise indicated extreme
        discontent?
No.


  (1.g) Has the Document Shepherd personally verified that the
        document satisfies all ID nits? (See the Internet-Drafts Checklist
        and http://tools.ietf.org/tools/idnits/).

It passes IDnits with 0 errors, and 4 warnings (for example there are 3 outdated references – the references will need to be updated immediately prior to final publication in any case).

  (1.h) Has the document split its references into normative and
        informative?

References are split. Both normative references are RFCs, one (RFC2119) is a BCP, the other is standards track.

  (1.i) Has the Document Shepherd verified that the document IANA
        consideration section exists and is consistent with the body
        of the document?

IANA section exists, and looks correct to the document shepherd.

  (1.j) Has the Document Shepherd verified that sections of the
        document that are written in a formal language, such as XML
        code, BNF rules, MIB definitions, etc., validate correctly in
        an automated checker?

Not applicable (no formal language used)

  (1.k) 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

  The Transport Profile for Multiprotocol Label Switching (MPLS-TP) is
  being specified jointly by IETF and ITU-T.  This document addresses
  the functionality described in the MPLS-TP Survivability Framework
  document  and defines a protocol that may be used to fulfill the
  function of the Protection State Coordination for linear protection.

  Linear protection provides rapid and simple protection
  switching.  In a mesh network, linear protection provides a very
  suitable protection mechanism because it can operate between any pair
  of points within the network.  It can protect against a defect in an
  intermediate node, a span, a transport path segment, or an end-to-end
  transport path.

Working Group Summary

  This document has been carefully reviewed by the MPLS WG as well as by ITU-T. A summary
  of the resolution of the many comments received has been posted to the MPLS WG email list.

Document Quality

  Multiple implementations are in progress.


2011-06-13
09 Cindy Morgan Draft added in state Publication Requested
2011-06-13
09 Cindy Morgan [Note]: 'Ross Callon (rcallon@juniper.net) is the Document Shepherd' added
2011-06-07
09 Loa Andersson In call to verify resolution of WGLC comments
2011-06-07
09 Loa Andersson IETF state changed to Waiting for WG Chair Go-Ahead from WG Document
2011-06-03
07 (System) New version available: draft-ietf-mpls-tp-linear-protection-07.txt
2011-03-13
06 (System) New version available: draft-ietf-mpls-tp-linear-protection-06.txt
2011-03-13
05 (System) New version available: draft-ietf-mpls-tp-linear-protection-05.txt
2011-01-27
04 (System) New version available: draft-ietf-mpls-tp-linear-protection-04.txt
2010-10-24
03 (System) New version available: draft-ietf-mpls-tp-linear-protection-03.txt
2010-07-26
02 (System) New version available: draft-ietf-mpls-tp-linear-protection-02.txt
2010-03-07
01 (System) New version available: draft-ietf-mpls-tp-linear-protection-01.txt
2010-02-04
00 (System) New version available: draft-ietf-mpls-tp-linear-protection-00.txt