doc: Add RFC documents

1 files changed, 619 insertions, 0 deletions

diff --git a/doc/rfc/rfc7324.txt b/doc/rfc/rfc7324.txt
new file mode 100644
index 0000000..6a6a6b9
--- /dev/null
+++ b/doc/rfc/rfc7324.txt
@@ -0,0 +1,619 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                        E. Osborne
+Request for Comments: 7324                                     July 2014
+Updates: 6378
+Category: Standards Track
+ISSN: 2070-1721
+
+
+          Updates to MPLS Transport Profile Linear Protection
+
+Abstract
+
+   This document contains a number of updates to the Protection State
+   Coordination (PSC) logic defined in RFC 6378, "MPLS Transport Profile
+   (MPLS-TP) Linear Protection".  These updates provide some rules and
+   recommendations around the use of TLVs in PSC, address some issues
+   raised in an ITU-T liaison statement, and clarify PSC's behavior in a
+   case not well explained in RFC 6378.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc7324.
+
+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.
+
+
+
+
+
+Osborne                      Standards Track                    [Page 1]
+
+RFC 7324                       PSC Updates                     July 2014
+
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
+     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
+   2.  Message Formatting and Error Handling . . . . . . . . . . . .   3
+     2.1.  PSC TLV Format  . . . . . . . . . . . . . . . . . . . . .   3
+     2.2.  Error Handling  . . . . . . . . . . . . . . . . . . . . .   4
+       2.2.1.  Malformed Messages  . . . . . . . . . . . . . . . . .   4
+       2.2.2.  Well-Formed but Unknown or Unexpected TLV . . . . . .   4
+   3.  Incorrect Local Status after Failure  . . . . . . . . . . . .   5
+   4.  Handling a Capabilities Mismatch  . . . . . . . . . . . . . .   5
+     4.1.  Protection Type Mismatch  . . . . . . . . . . . . . . . .   5
+     4.2.  R Mismatch  . . . . . . . . . . . . . . . . . . . . . . .   6
+     4.3.  Unsupported Modes . . . . . . . . . . . . . . . . . . . .   6
+   5.  Reversion Deadlock Due to a Race Condition  . . . . . . . . .   7
+   6.  Clarifying PSC's Behavior in the Face of Multiple Inputs  . .   8
+   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
+   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
+   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  10
+   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
+     10.1.  Normative References . . . . . . . . . . . . . . . . . .  10
+     10.2.  Informative References . . . . . . . . . . . . . . . . .  10
+
+1.  Introduction
+
+   This document contains a number of updates to PSC [RFC6378].  One
+   provides some rules and recommendations around the use of TLVs in
+   PSC.  Three of the updates 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].  Another clears up a behavior that was not well
+   explained in RFC 6378.  These updates are not changes to the
+   protocol's packet format or to PSC's design; they are corrections and
+   clarifications to specific aspects of the protocol's procedures.
+   This document does not introduce backward compatibility issues with
+   implementations of RFC 6378.
+
+   It should be noted that [RFC7271] contains protocol mechanisms for an
+   alternate mode of operating MPLS-TP PSC.  Those modes are built on
+   the message structures and procedures of [RFC6378], and so, while
+   this document does not update [RFC7271], it has an impact on that
+   work through its update to [RFC6378].
+
+   This document assumes familiarity with RFC 6378 and its terms,
+   conventions, and acronyms.  Any term used in this document but not
+   defined herein can be found in RFC 6378.  In particular, this
+   document shares the acronyms defined in Section 2.1 of RFC 6378.
+
+
+
+
+Osborne                      Standards Track                    [Page 2]
+
+RFC 7324                       PSC Updates                     July 2014
+
+
+1.1.  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].
+
+2.  Message Formatting and Error Handling
+
+   This section covers message formatting as well as some recommended
+   error checking.
+
+2.1.  PSC TLV Format
+
+   [RFC6378] provides the capability to carry TLVs in the PSC messages.
+   All fields are encoded in network byte order.  Each TLV contains
+   three fields, as follows:
+
+       0                   1                   2                   3
+       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |             Type              |            Length             |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                             Value                             |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Type field (T):
+
+   A two-octet field that encodes a type 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.  The value of this field MUST be a multiple of 4.
+
+   Value field (V):
+
+   The payload of the TLV.  The length of this field (which is the value
+   of the Length field) MUST be a multiple of 4 octets, and so this
+   field may contain explicit padding.  The length of each single TLV is
+   the sum of the lengths of its three fields: the length of the value
+   field + 4.  The overall TLV Length field in the PSC message contains
+   the total length of all TLVs in octets.
+
+
+
+
+
+
+
+
+Osborne                      Standards Track                    [Page 3]
+
+RFC 7324                       PSC Updates                     July 2014
+
+
+2.2.  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.
+
+   This text is not intended to limit the error or bounds checking a
+   device performs.  The recommendations herein should be taken as a
+   starting point.
+
+2.2.1.  Malformed Messages
+
+   An implementation SHOULD:
+
+   o  Ensure any fields prior to TLV Length are consistent with RFC
+      6378, particularly Section 4.2 of that document.
+
+   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 that 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.2.2.  Well-Formed but Unknown or 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 or unexpected TLV value MUST be ignored,
+   and the rest of the message processed as if the ignored TLV did not
+   exist.  An implementation detecting a malformed TLV SHOULD alert the
+   operator as described in Section 2.2.1.
+
+
+
+
+
+
+
+
+
+
+
+
+Osborne                      Standards Track                    [Page 4]
+
+RFC 7324                       PSC Updates                     July 2014
+
+
+3.  Incorrect Local Status after Failure
+
+   Issue #2 in the liaison statement identifies a case where a strict
+   reading of RFC 6378 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 RFC 6378
+   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.  Handling a Capabilities Mismatch
+
+   PSC has no explicit facility to negotiate any properties of the
+   protection domain.  It does, however, have the ability to signal two
+   properties of that domain, via the Protection Type (PT) and Revertive
+   (R) bits.  RFC 6378 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 is no text that
+   specifies the behavior of the end nodes of a protection domain in
+   case of a mismatch.  This section provides that text, as requested by
+   issue #7 in the liaison statement.
+
+4.1.  Protection Type Mismatch
+
+   The behavior of the protection domain depends on the exact Protection
+   Type (PT) mismatch.  Section 4.2.3 of RFC 6378 specifies three
+   protection types -- bidirectional switching using a permanent bridge,
+   bidirectional switching using a selector bridge, and unidirectional
+   switching using a permanent bridge.  They are abbreviated here as BP,
+   BS, and UP.
+
+
+
+
+
+
+Osborne                      Standards Track                    [Page 5]
+
+RFC 7324                       PSC Updates                     July 2014
+
+
+   There are three possible mismatches: {BP, UP}, {BP, BS}, and
+   {UP, BS}.  The priority is:
+
+   UP > BS > BP
+
+   In other words:
+
+   o  If the PT mismatch is {BP, UP}, the node transmitting BP MUST
+      switch to UP mode if it is supported.
+
+   o  If the PT mismatch is {BP, BS}, the node transmitting BP MUST
+      switch to BS mode if it is supported.
+
+   o  If the PT mismatch is {UP, BS}, the node transmitting BS MUST
+      switch to UP mode if it is supported.
+
+   If a node does not support a mode to which it is required to switch,
+   then that node MUST behave as in Section 4.3.
+
+4.2.  R Mismatch
+
+   The R bit indicates whether the protection domain is in revertive or
+   non-revertive behavior.  If the R bits do not match, the node
+   indicating non-revertive MUST switch to Revertive if it is supported.
+   If it is not supported, a node must behave as in Section 4.3.
+
+4.3.  Unsupported Modes
+
+   An implementation may not support all three PT modes and/or both R
+   modes, 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 the mismatches 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 is no failure (e.g., NR state) regardless of any PT or
+   R mismatch.
+
+   If there is a trigger that would cause the protection LSP to be used,
+   such as SF or MS, a node MUST NOT use the protection LSP to carry
+   traffic.
+
+
+
+
+
+
+
+Osborne                      Standards Track                    [Page 6]
+
+RFC 7324                       PSC Updates                     July 2014
+
+
+5.  Reversion Deadlock Due to a Race Condition
+
+   Issue #8 in the liaison statement identifies a deadlock case where
+   each node can end up sending NR(0,1) when it should instead be in the
+   process of recovering from the failure (i.e., entering into WTR or
+   DNR, as appropriate for the protection domain).  The root of the
+   issue is that a pair of nodes can simultaneously enter WTR state,
+   receive an out-of-date SF-W indication, transition into a remotely
+   triggered WTR, and remain in remotely triggered WTR waiting for the
+   other end to trigger a change 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
+   that receives NR(0,1) is in fact not indicating a local error, the
+   correct behavior for the receiving node is to take the received
+   NR(0,1) as an indication that there is no error in the protection
+   domain, and recovery procedures (WTR or DNR) should begin.
+
+   This is addressed by adding the following text as the penultimate
+   bullet in Section 4.3.3.4 of RFC 6378:
+
+   o  If a node is in Protecting Failure state due to a remote SF-W 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, and
+      begins transmitting WTR(0,1).  If the LER is configured for non-
+      revertive behavior, it enters into Do-Not-Revert state and begins
+      transmitting a DNR(0,1) message.
+
+   Additionally, the penultimate bullet in Section 4.3.3.3 is changed
+   from
+
+   o  A remote NR(0,0) message SHALL be ignored if in local Protecting
+      administrative state.
+
+   to
+
+   o  A 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 value of FPath and Path.  This change does not directly
+   address issue #8, but it fixes a similar issue -- if a node receives
+   NR while in Remote administrative state, the value of FPath and Path
+   have no bearing on the node's reaction to this NR.
+
+
+
+
+
+Osborne                      Standards Track                    [Page 7]
+
+RFC 7324                       PSC Updates                     July 2014
+
+
+6.  Clarifying PSC's Behavior in the Face of Multiple Inputs
+
+   RFC 6378 describes the PSC state machine.  Figure 1 in Section 3 of
+   RFC 6378 shows two inputs into the PSC Control logic -- Local Request
+   logic and Remote PSC Request.  When there 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, as necessary.  This is what the PSC State
+   Machine in Section 4.3 of RFC 6378 describes.
+
+   RFC 6378 does not sufficiently describe the behavior in the face of
+   multiple inputs into the PSC Control Logic (one Local Request and one
+   Remote Request).  This section clarifies the expected behavior.
+
+   There are two cases to think about when considering dual inputs into
+   the PSC Control logic.  The first is when the same request is
+   presented from both local and remote sources.  One example of this
+   case is a Forced Switch (FS) configured 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 as [L(FS),
+   R(FS)] -- that is, Local(Forced Switch) and Remote(Forced Switch).
+
+   The second case, which is handled in exactly the same way as the
+   first, is when the two inputs into the PSC Control logic describe
+   different events.  There are a number of variations on this case.
+   One example is when there is a Lockout of Protection from the Local
+   request logic and a Signal Fail on the Working path from the Remote
+   PSC Request.  This is shortened to [L(LO), R(SF-W)].
+
+   In both cases, the question is not how the PSC Control logic decides
+   which of these is the one it acts upon.  Section 4.3.2 of RFC 6378
+   lists the priority order and prioritizes the local input over the
+   remote input in case both inputs are of the same priority.  So, in
+   the first example it is the local SF that drives the PSC Control
+   logic, and in the second example it is the local Lockout that drives
+   the PSC Control logic.
+
+   The point that this section clears up is around what happens when the
+   highest-priority input goes away.  Consider the first case.
+   Initially, the PSC Control logic has [L(FS), R(FS)], and L(FS) is
+   driving PSC's behavior.  When L(FS) is removed, but R(FS) remains,
+   what does PSC do?  A strict reading of the Finite State Machine (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 clear that they are not.
+
+
+
+
+Osborne                      Standards Track                    [Page 8]
+
+RFC 7324                       PSC Updates                     July 2014
+
+
+   The second case is similar.  If a node starts with [L(LO), R(SF-W)]
+   and the local lockout is removed, a strict reading of the state
+   machine would suggest that the node transition from UA:LO:L to N, and
+   then at some future time presumably notice the R(SF-W) and transition
+   from N to PF:W:R.  As with the first case, this is clearly not a
+   useful behavior.
+
+   In both cases, the request that was driving PSC's behavior was
+   removed.  What should happen is that the PSC Control logic should,
+   upon removal of an input, immediately reevaluate all other inputs to
+   decide on the next course of action.  This requires an implementation
+   to store the most recent local and remote inputs regardless of their
+   eventual use as triggers for the PSC Control Logic.
+
+   There is also a third case.  Consider 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 that the inputs into the PSC Control
+   logic on the receiving node go to [L(FS), R(SF-W)].  Similar to the
+   first two cases, the node should immediately reevaluate both its
+   local and remote inputs to determine the highest priority among them
+   and act on that input accordingly.  That is in fact what happens, as
+   defined in Section 4.3.3 of RFC 6378:
+
+      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 a
+      contradictory state, e.g., in remote Unavailable state receiving a
+      remote FS(1,1) message, then the PSC Control logic SHALL
+      reevaluate all inputs (both the local input and the remote
+      message) as if the LER is in the Normal state.
+
+   This section extends that paragraph to 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 were in Normal
+   state.  So, the quoted paragraph is replaced with the following text:
+
+      The PSC Control logic may simultaneously have Local and Remote
+      requests, and the highest priority of these requests ultimately
+      drives the behavior of the PSC Control logic.  When this highest-
+      priority request is removed or is replaced with another input,
+      then the PSC Control logic SHALL immediately reevaluate all inputs
+      (both the local input and the remote message), transitioning into
+      a new state only upon reevaluation of all inputs.
+
+
+
+
+
+
+
+
+Osborne                      Standards Track                    [Page 9]
+
+RFC 7324                       PSC Updates                     July 2014
+
+
+7.  Security Considerations
+
+   These changes and clarifications raise no new security concerns.  RFC
+   6941 [RFC6941] provides the baseline security discussion for MPLS-TP,
+   and PSC (as described in both RFC 6378 and this document) falls under
+   that umbrella.  Additionally, Section 2.2 clarifies how to react to
+   malformed or unexpected messages.
+
+8.  IANA Considerations
+
+   IANA has marked the value 0 in the "MPLS PSC TLV Registry" as
+   "Reserved, not to be allocated" and updated the references to show
+   [RFC6378] and this document (RFC 7324).  Note that this document
+   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/>.
+
+   [RFC6941]  Fang, L., Niven-Jenkins, B., Mansfield, S., and R.
+              Graveman, "MPLS Transport Profile (MPLS-TP) Security
+              Framework", RFC 6941, April 2013.
+
+
+
+
+
+
+
+Osborne                      Standards Track                   [Page 10]
+
+RFC 7324                       PSC Updates                     July 2014
+
+
+   [RFC7271]  Ryoo, J., Gray, E., van Helvoort, H., D'Alessandro, A.,
+              Cheung, T., and E. Osborne, "MPLS Transport Profile (MPLS-
+              TP) Linear Protection to Match the Operational
+              Expectations of Synchronous Digital Hierarchy, Optical
+              Transport Network, and Ethernet Transport Network
+              Operators", RFC 7271, June 2014.
+
+Author's Address
+
+   Eric Osborne
+
+   EMail: eric.osborne@notcom.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Osborne                      Standards Track                   [Page 11]
+