Network Working Group                                         E. Osborne
Internet-Draft
Updates: 6378 (if approved)                               March 25,                               April 21, 2014
Intended status: Standards Track
Expires: September 26, October 23, 2014

          Updates to MPLS Transport Profile Linear Protection
                     draft-ietf-mpls-psc-updates-03
                     draft-ietf-mpls-psc-updates-04

Abstract

   This document contains four a number of updates to the Protection State
   Coordination (PSC) logic defined in RFC6378, "MPLS Transport Profile
   (MPLS-TP) Linear Protection" . Two of the Protection".  These updates correct existing
   behavior.  The third clarifies a behavior which was not explained in
   the RFC, and the fourth adds provide some rules and
   recommendations around handling capabilities
   mismatches. the use of TLVs in PSC, address some issues
   raised in an ITU-T liaision statement, and clarify

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on September 26, October 23, 2014.

Copyright Notice

   Copyright (c) 2014 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Message Formatting and Error Handling . . . . . . . . . . . .   3
     2.1.  Format on the wire  . . . . . . . . . . . . . . . . . . .   3
     2.2.  PSC TLV Format  . . . . . . . . . . . . . . . . . . . . .   3
     2.3.  Error handling  . . . . . . . . .   3
   3.  Incorrect local status after failure . . . . . . . . . . . .   3
   4.  Reversion deadlock due to a race condition
       2.3.1.  Malformed messages  . . . . . . . . . . . . . . . . .   4
   5.  Clarifying PSC's behavior in the face of multiple inputs
       2.3.2.  Well-formed but unexpected TLV  . .   5
   6. . . . . . . . . .   4
   3.  Incorrect local status after failure  . . . . . . . . . . . .   4
   4.  Handling a capabilities mismatch  . . . . . . . . . . . . . .   7
     6.1.   5
     4.1.  Protection Type mismatch  . . . . . . . . . . . . . . . .   7
     6.2.   5
     4.2.  R mismatch  . . . . . . . . . . . . . . . . . . . . . . .   7
     6.3.   6
     4.3.  Unsupported modes . . . . . . . . . . . . . . . . . . . .   6
   5.  Reversion deadlock due to a race condition  . . . . . . . . .   6
   6.  Clarifying PSC's behavior in the face of multiple inputs  . .   7
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   8   9
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8   9
   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   8   9
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .   8   9
     10.1.  Normative References . . . . . . . . . . . . . . . . . .   8   9
     10.2.  Informative References . . . . . . . . . . . . . . . . .   9  10
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   9  10

1.  Introduction

   This document contains firve a number of updates to PSC [RFC6378].  The first
   clarifies  One
   provides some rules and recommendations around the use of TLVs in
   PSC.  Three of them address issues #2, #7 and #8 as identified in the
   ITU's liaison statement "Recommendation ITU-T G.8131/Y.1382 revision
   - Linear protection switching for MPLS-TP networks" [LIAISON].  The fifth
   Another clears up a behavior which was not well explained in RFC6378.
   These updates are not changes to the protocol's packet format or to
   PSC's design, but are corrections and clarifications to specific
   aspects of the protocol's procedures.

   This document assumes familiarity with RFC6378 and its terms,
   conventions and acronyms.  Any term used in this document but not
   defined herein can be found in RFC6378.  In particular, this document
   shares the acronyms defined in RFC6378 section 2.1.

2.  Message Formatting and Error Handling

   This section covers message formatting, as well as some recommended
   error checking.

2.1.  Format on the wire

   All integer fields in the PSC TLV are encoded as unsigned integers in
   network bit order.

2.2.  PSC TLV Format

   [RFC6378] defines provides the capability to carry TLVs in the PSC messages.
   This section defines the format to be used by all such TLVs.  All
   fields are encoded in network byte order.

   Type field (T):

   A two octet field that encodes a type value in network byte order. value.  The type values are
   recorded in the IANA registry "MPLS PSC TLV Registry".

   Length field (L) :

   A two octet field that encodes the length in octets of the Value
   field in network byte order.
   field.

   The value TLV Length is the sum of the lengths of all TLVs in the message.
   The length of a TLV is the sum of the lengths of the three TLV
   fields, i.e., the the length of the value field + 4.

   The value of this field MUST be a multiple of 4.

   Value field (V) :

   The contents of the TLV.  This field MUST be a multiple of 4 octets
   and so may contain explicit padding.

2.3.  Error handling

   It is recommended to implement error and bounds checking to ensure
   that received messages, if improperly formatted, are handled in such
   a way to minimize the impact of this formatting on the behavior of
   the network and its devices.  This section covers two such areas -
   malformed messages and well-formed but unexpected TLVs.

   Neither of these sections is intended to limit the error or bounds
   checking a device performs.  The recommendations here should be taken
   as a starting point.

2.3.1.  Malformed messages

   A implementation SHOULD:

   o  Ensure any fields prior to TLV Length are consistent with RFC
      6378, particularly Section 4.2.

   o  Ensure the overall length of the message matches the value in the
      TLV Length + 12.

   o  Check that the sum of the lengths of all TLVs matches the value in
      the TLV Length.

   If an implementation receives a message which fails any malformed
   message checks, it MUST drop the message and SHOULD alert the
   operator to the malformed message.  The method(s) used to alert the
   operator are outside the scope of this document, but may include
   things like syslog or console messages.

2.3.2.  Well-formed but unexpected TLV

   If a message is deemed to be properly formed, an implementation
   SHOULD check all TLVs to ensure that it knows what to do with them.
   A well-formed but unknown TLV value MUST be ignored, and the rest of
   the message processesed as if the ignored TLV did not exist.  An
   implementation detecting a malformed TLV SHOULD alert the operator as
   described in Section 2.3.1.

3.  Incorrect local status after failure

   Issue #2 in the liaison identifies a case where a strict reading of
   RFC6378 leaves a node reporting an inaccurate status:

   A node can end up sending incorrect status - NR(0,1) - despite the
   failure of the protection LSP (P-LSP).  This is clearly not correct,
   as a node should not be sending NR if it has a local failure.  To
   address this issue, the fourth bullet in section 4.3.3.3 of RFC6378
   is replaced with the following three bullets:

   o  If the current state is due to a local or remote Manual Switch, a
      local Signal Fail indication on the protection path SHALL cause
      the LER to enter local Unavailable state and begin transmission of
      an SF(0,0) message.

   o  If the LER is in local Protecting Administrative state due to a
      local Forced Switch, a local Signal Fail indication on the
      protection path SHALL be ignored.

   o  If the LER is in remote Protecting Administrative state due to a
      remote Forced Switch, a local Signal Fail indication on the
      protection path SHALL cause the LER to remain in remote Protecting
      administrative state and transmit an SF(0,1) message.

4.  Reversion deadlock due to a race condition

   Issue #8 in the liaison identifies  Handling a deadlock case where each node
   can end up sending NR(0,1) when it should instead be in the process capabilities mismatch

   PSC has no explicit facility to negotiate any properties of recovering from the failure (i.e. entering into WTR or DNR, as
   appropriate for the
   protection domain).  The root domain.  It does, however, have the ability to signal two
   properties of that domain, via the issue is Protection Type (PT) and Revertive
   (R) bits.  RFC6378 specifies that a pair of nodes can simultaneously enter WTR state, receive if these bits do not match an
   out
   operator "SHALL [be notified]" (PT, section 4.2.3) or "SHOULD be
   notified" (R, section 4.2.4).  However, there is no text which
   specifies the behavior of date SF-W indication and transition into a remotely triggered
   WTR, and remain in remotely triggered WTR waiting for the other end
   to trigger nodes of a change protection domain in status.

   In the
   case identified in issue #8, each node can end up sending
   NR(0,1), which is an indication that the transmitting node has no
   local failure, but is instead reacting to the remote SF-W. If a node
   which receives NR(0,1) is in fact not indicating of a local error, the
   receive node can take the received NR(0,1) as an indication mismatch.  This section provides that
   there is no error text, as requested by
   issue #7 in the protection domain, and recovery procedures
   (WTR or DNR) should begin.

   This is addressed by adding liaison.

4.1.  Protection Type mismatch

   The behavior of the following text as protection domain depends on the penultimate
   bullet in section 4.3.3.4 exact Protection
   Type (PT) mismatch.  Section 4.2.3 of RFC6378:

   o  If RFC6378 specifies three
   protection types - bidirectional switching using a node is in Protecting Failure state due to permanent bridge,
   bidirectional switching using a remote SF-W selector bridge, and
      receives NR(0,1), this SHALL cause the node to begin recovery
      procedures.  If the LER is configured for revertive behavior, it
      enters into Wait-to-Restore state, starts the WTR timer, unidirectional
   switching using a permanent bridge.  They are abbreviated here as BP,
   BS and
      begins transmitting WTR(0,1). UP.

   There are three possible mismatches: {BP, UP}, {BP, BS}, and {UP,
   BS}. The priority is:

   UP > BS > BP

   In other words:

   o  If the LER PT mismatch is configured for non-
      revertive behavior, it enters into Do-Not-Revert state and begins
      transmitting a DNR(0,1) message.

   Additionally, {BP, UP}, the final bullet in section 4.3.3.3 node transmitting BP MUST
      switch to UP mode if it is changed from supported.

   o  A remote NR(0,0) message SHALL be ignored if in local Protecting
      administrative state.  If the PT mismatch is {BP, BS}, the node transmitting BP MUST
      switch to

   o  A remote No Request message SHALL be ignored BS mode if in local
      Protecting administrative state.

   This indicates that a remote NR triggers it is supported.

   o  If the same behavior regardless
   of PT mismatch is {UP, BS}, the value of FPath and Path.  This change node transmitting BS MUST
      switch to UP mode if it is supported.

   If a node does not directly
   address issue #8, but fixes a similar issue - if support a mode to which it is required to switch
   then that node receives NR
   while MUST behave as in Remote administrative state, the value of FPath and Path
   have no bearing on Section 4.3.

4.2.  R mismatch

   The R bit indicates whether the node's reaction to this NR.

5.  Clarifying PSC's behavior protection domain is in Revertive or
   Non-Revertive behavior.  If the face of multiple inputs

   RFC6378 describes R bits do not match, the PSC state machine.  Figure 1 in section 3 shows
   two inputs into the PSC Control logic - Local Request logic and
   Remote PSC Request.  When there node
   indicating Non-Revertive MUST switch to Revertive if it is supported.
   If it is only one input into the PSC
   Control logic - a local request or a remote request but not both -
   the PSC Control logic decides what that input signifies and then
   takes one or more actions, supported a node must behave as necessary.  This is what the PSC State
   Machine in section Section 4.3 describes.

   RFC6378 does

4.3.  Unsupported modes

   An implementation may not sufficiently describe the behavior in the face of
   multiple inputs into the PSC Control Logic (one Local Request support all three PT modes and/or both R
   modes, and one
   Remote Request). thus a pair of nodes may be unable to converge on a common
   mode.  This section clarifies creates a permanent mismatch, resolvable only by operator
   intervention.  An implementation SHOULD alert the expected behavior.

   There are two cases operator to think about when considering dual inputs into
   the PSC Control logic.  The first an
   irreconcilable mismatch.

   It is when desirable to allow the same request protection domain to function in a non-
   failure mode even if there is
   presented from both local and remote sources.  One example a mismatch, as the mismatches of this
   case is PT or
   R have to do with how nodes recover from a Forced Switch (FS) configured failure.  An
   implementation SHOULD allow traffic to be sent on both ends of an LSP.  This
   will result in the PSC Control logic receiving both a local FS and
   remove FS.  For convenience, this scenario is written Working LSP as [L(FS),
   R(FS))] - that is, Local(Forced Switch) and Remote(Forced Switch).

   The second case, which
   long as there is handled in exactly no failure (e.g. NR state) regardless of any PT or R
   mismatch.

   If there is a trigger which would cause the same way protection LSP to be
   used, such as SF or MS, a node MUST NOT use the
   first, is protection LSP to
   carry traffic.

5.  Reversion deadlock due to a race condition

   Issue #8 in the liaison identifies a deadlock case where each node
   can end up sending NR(0,1) when it should instead be in the two inputs process
   of recovering from the failure (i.e. entering into WTR or DNR, as
   appropriate for the PSC Control logic describe
   different events.  There are a number protection domain).  The root of variations on this case.
   One example is when there the issue is
   that a Lockout pair of Protection from the Local
   request logic nodes can simultaneously enter WTR state, receive an
   out of date SF-W indication and transition into a Signal Fail on the Working parh from remotely triggered
   WTR, and remain in remotely triggered WTR waiting for the Remote
   PSC Request.  This is shortened other end
   to [L(LO), R(SF-W)].

   In both cases the question is not how trigger a change in status.

   In the PSC Control logic decides case identified in issue #8, each node can end up sending
   NR(0,1), which of these is an indication that the one it acts upon.  Section 4.3.2 of RFC6378
   lists the priority order, and prioritizes the transmitting node has no
   local input over failure, but is instead reacting to the remote input SF-W. If a node
   which receives NR(0,1) is in case both inputs are of fact not indicating a local error, the same priority.  So in
   correct behavior for the
   first example it receiving node is to take the local SF received
   NR(0,1) as an indication that drives the PSC Control logic,
   and there is no error in the second example it protection
   domain, and recovery procedures (WTR or DNR) should begin.

   This is addressed by adding the local Lockout which drives following text as the
   PSC Control logic.

   The point that this penultimate
   bullet in section clears up 4.3.3.4 of RFC6378:

   o  If a node is around what happens when in Protecting Failure state due to a remote SF-W and
      receives NR(0,1), this SHALL cause the
   highest priority input goes away.  Consider node to begin recovery
      procedures.  If the first case.
   Initially, LER is configured for revertive behavior, it
      enters into Wait-to-Restore state, starts the PSC Control logic has [L(FS), R(FS)] WTR timer, and L(FS)
      begins transmitting WTR(0,1).  If the LER is
   driving PSC's behavior.  When L(FS) configured for non-
      revertive behavior, it enters into Do-Not-Revert state and begins
      transmitting a DNR(0,1) message.

   Additionally, the final bullet in section 4.3.3.3 is removed but R(FS) remains,
   what does PSC do? changed from

   o  A remote NR(0,0) message SHALL be ignored if in local Protecting
      administrative state.

   to

   o  A strict reading remote No Request message SHALL be ignored if in local
      Protecting administrative state.

   This indicates that a remote NR triggers the same behavior regardless
   of the FSM would suggest that PSC
   transition from PA:F:L into N, value of FPath and at some future time (perhaps after
   the remote request refreshes) PSC would transition from N to PA:F:R. Path.  This is an unreasonable behavior, as there is no sensible
   justification for change does not directly
   address issue #8, but fixes a node behaving as similar issue - if things were normal (i.e. N
   state) when it is clear that they are not.

   The second case is similar.  If a node starts with [L(LO), R(SF-W)]
   and receives NR
   while in Remote administrative state, the local lockout is removed, a strict reading value of the state
   machine would suggest that the node transition from UA:LO:L to N, FPath and
   then at some future time presumably notice Path
   have no bearing on the R(SF-W) and transition
   from N node's reaction to PF:W:R. As with the first case, this is clearly not a
   useful behavior.

   In both cases the request which was driving NR.

6.  Clarifying PSC's behavior was
   removed.  What should happen is that in the PSC Control logic should,
   upon removal face of an input, immediately reevaluate all other multiple inputs to
   decide on the next course of action.  This requires an implementation
   to store

   RFC6378 describes the most recent local and remote PSC state machine.  Figure 1 in section 3 shows
   two inputs regardless of their
   eventual use as triggers for into the PSC Control logic - Local Request logic and
   Remote PSC Request.  When there is only one input into the PSC
   Control Logic.

   There is logic - a third case.  Consider local request or a node with [L(FS), R(LO)].  At some
   point in time the remote node replaces its Lockout request with a
   Signal Fail on Working, so but not both -
   the PSC Control logic decides what that input signifies and then
   takes one or more actions, as necessary.  This is what the PSC State
   Machine in section 4.3 describes.

   RFC6378 does not sufficiently describe the behavior in the face of
   multiple inputs into the PSC Control logic
   on Logic (one Local Request and one
   Remote Request).  This section clarifies the receiving node go to [L(FS), R(SF-W)].  Similar expected behavior.

   There are two cases to think about when considering dual inputs into
   the PSC Control logic.  The first
   two cases, is when the node should immediately reevaluate same request is
   presented from both its local and remote inputs to determine sources.  One example of this
   case is a Forced Switch (FS) configured on both ends of an LSP.  This
   will result in the highest priority among them, PSC Control logic receiving both a local FS and act
   on
   remove FS.  For convenience, this scenario is written as [L(FS),
   R(FS)] - that input accordingly.  That is, Local(Forced Switch) and Remote(Forced Switch).

   The second case, which is handled in fact what happens, exactly the same way as defined
   in Section 4.3.3:

   "When a LER the
   first, is in when the two inputs into the PSC Control logic describe
   different events.  There are a remote state, i.e., state transition in reaction
   to number of variations on this case.
   One example is when there is a PSC message received Lockout of Protection from the far-end LER, Local
   request logic and receives a new
   PSC message Signal Fail on the Working path from the far-end LER that indicates a contradictory
   state, e.g., in remote Unavailable state receiving a remote FS(1,1)
   message, then Remote
   PSC Request.  This is shortened to [L(LO), R(SF-W)].

   In both cases the question is not how the PSC Control logic SHALL reevaluate all inputs (both decides
   which of these is the one it acts upon.  Section 4.3.2 of RFC6378
   lists the priority order, and prioritizes the local input and over the
   remote message) as if the LER is input in case both inputs are of the
   Normal state."

   This section extends that paragraph to handle same priority.  So in the
   first two cases.
   The essence of the quoted paragraph example it is the local SF that when faced with multiple
   inputs, drives the PSC must reevaluate any changes as if it was Control logic,
   and in Normal state.
   So the quoted paragraph second example it is replaced with the following text:

   "The local Lockout which drives the
   PSC Control logic may simultaneously have Local and Remote
   requests, and logic.

   The point that this section clears up is around what happens when the
   highest priority of these requests ultimately
   drives input goes away.  Consider the behavior of first case.
   Initially, the PSC Control logic. logic has [L(FS), R(FS)] and L(FS) is
   driving PSC's behavior.  When this highest
   priority L(FS) is removed but R(FS) remains,
   what does PSC do?  A strict reading of the FSM would suggest that PSC
   transition from PA:F:L into N, and at some future time (perhaps after
   the remote request refreshes) PSC would transition from N to PA:F:R.
   This is an unreasonable behavior, as there is no sensible
   justification for a node behaving as if things were normal (i.e., N
   state) when it is removed or clear that they are not.

   The second case is replaced similar.  If a node starts with another input, then
   the PSC Control logic SHALL immediately reevaluate all inputs (both
   the local input [L(LO), R(SF-W)]
   and the remote message), transitioning into a new
   state only upon reevaluation of all inputs".

6.  Handling local lockout is removed, a capabilities mismatch

   PSC has no explicit facility to negotiate any properties strict reading of the
   protection domain.  It does, however, have state
   machine would suggest that the ability node transition from UA:LO:L to signal two
   properties of that domain, via N, and
   then at some future time presumably notice the Protection Type (PT) R(SF-W) and Revertive
   (R) bits.  RFC6378 specifies that if these bits do not match an
   operator "SHALL [be notified]" (PT, section 4.2.3) or "SHOULD be
   notified" (R, section 4.2.4).  However, there transition
   from N to PF:W:R. As with the first case, this is no text which
   specifies clearly not a
   useful behavior.

   In both cases the request that was driving PSC's behavior of the end nodes of a protection domain in
   case of a mismatch.  This section provides was
   removed.  What should happen is that text, as requested by
   issue #7 in the liaison.

6.1.  Protection Type mismatch

   The behavior PSC Control logic should,
   upon removal of the protection domain depends an input, immediately reevaluate all other inputs to
   decide on the exact Protection
   Type (PT) mismatch.  Section 4.2.3 next course of RFC6378 specifies three
   protection types - bidirectional switching using a permanent bridge,
   bidirectional switching using a selector bridge, action.  This requires an implementation
   to store the most recent local and unidirectional
   switching using a permanent bridge.  They are abbreviated here remote inputs regardless of their
   eventual use as BP,
   BS and UP.

   There are three possible mismatches: {BP, UP}, {BP, BS}, and {UP,
   BS}. The priority is:

   UP > BS > BP

   In other words:

   o  If triggers for the PT mismatch PSC Control Logic.

   There is {BP, UP}, a third case.  Consider a node with [L(FS), R(LO)].  At some
   point in time the remote node transmitting BP MUST
      switch to UP mode if it is supported.

   o  If replaces its Lockout request with a
   Signal Fail on Working, so that the PT mismatch is {BP, BS}, inputs into the PSC Control logic
   on the receiving node transmitting BP MUST
      switch go to [L(FS), R(SF-W)].  Similar to BS mode if it is supported.

   o  If the PT mismatch is {UP, BS}, first
   two cases, the node transmitting BS MUST
      switch should immediately reevaluate both its local and
   remote inputs to UP mode if it determine the highest priority among them, and act
   on that input accordingly.  That is supported.

6.2.  R mismatch

   The R bit in fact what happens, as defined
   in Section 4.3.3:

   "When a LER is in a remote state, i.e.,, state transition in reaction
   to a PSC message received from the far-end LER, and receives a new
   PSC message from the far-end LER that indicates whether a contradictory
   state, e.g., in remote Unavailable state receiving a remote FS(1,1)
   message, then the protection domain PSC Control logic SHALL reevaluate all inputs (both
   the local input and the remote message) as if the LER is in Revertive or
   Non-Revertive behavior.  If the R bits do not match, the node
   indicating Non-Revertive MUST switch
   Normal state."

   This section extends that paragraph to Revertive handle the first two cases.
   The essence of the quoted paragraph is that when faced with multiple
   inputs, PSC must reevaluate any changes as if it was in Normal state.
   So the quoted paragraph is supported.

6.3.  Unsupported modes

   An implementation replaced with the following text:

   "The PSC Control logic may not support all three PT modes and/or both R
   modes, simultaneously have Local and Remote
   requests, and thus a pair of nodes may be unable to converge on a common
   mode.  This creates a permanent mismatch, resolvable only by operator
   intervention.  An implementation SHOULD alert the operator to an
   irreconcilable mismatch.

   It is desirable to allow the protection domain to function in a non-
   failure mode even if there is a mismatch, as highest priority of these requests ultimately
   drives the mismatches behavior of PT or
   R have to do with how nodes recover from a failure.  An
   implementation SHOULD allow traffic to be sent on the Working LSP as
   long as there PSC Control logic.  When this highest
   priority request is no failure (e.g. NR state) regardless of any PT removed or R
   mismatch.

   If there is a trigger which would cause replaced with another input, then
   the protection LSP to be
   used, such as SF or MS, a node MUST NOT use PSC Control logic SHALL immediately reevaluate all inputs (both
   the protection LSP to
   carry traffic. local input and the remote message), transitioning into a new
   state only upon reevaluation of all inputs".

7.  Security Considerations

   These changes and clarifications raise no new security concerns.

8.  IANA Considerations

   IANA is requested to mark the value 0 in the "MPLS PSC TLV Registry"
   as "Reserved, not to be allocated" and to update the references to
   show [RFC6378] and [RFC-ietf-mpls-psc-updates-03]. [RFC-ietf-mpls-psc-updates-04].  Note that this
   action provides documentation of an action already taken by IANA but
   not recorded in RFC 6378.

9.  Acknowledgements

   The author of this document thanks Taesik Cheung, Alessandro
   D'Alessandro, Annamaria Fulignoli, Sagar Soni, George Swallow and
   Yaacov Weingarten for their contributions and review, and Adrian
   Farrel for the text of Section 2.

10.  References

10.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC6378]  Weingarten, Y., Bryant, S., Osborne, E., Sprecher, N., and
              A. Fulignoli, "MPLS Transport Profile (MPLS-TP) Linear
              Protection", RFC 6378, October 2011.

10.2.  Informative References

   [LIAISON]  ITU-T SG15, "Liaison Statement: Recommendation ITU-T
              G.8131/Y.1382 revision - Linear protection switching for
              MPLS-TP networks", <https://datatracker.ietf.org/liaison/
              1205/>.

Author's Address

   Eric Osborne

   Email: eric.osborne@notcom.com