[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: (draft-ietf-pwe3-status-reduction) 00 01 02 03 04 05

Internet Engineering Task Force                             Luca Martini
Internet Draft                                               Monoski LLC
Intended status: Standards Track                          George Swallow
Expires: November 2017                                             Cisco
                                                        Elisa Bellagamba
                                                                Ericsson

                                                                May 2017


      MPLS LSP PW status refresh reduction for Static Pseudowires


                draft-ietf-pals-status-reduction-05.txt

Status of this Memo

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

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   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."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on November 10, 2010

Abstract

   This document describes a method for generating an aggregated
   pseudowire status message transmitted for a statically configured
   pseudowire on a Multi-Protocol Label Switching (MPLS) Label Switched
   Path (LSP) to indicate the status of one or more pseudowires carried
   on the LSP.

   The method for transmitting the pseudowire (PW) status information is
   not new, however this protocol extension allows a Service Provider



Martini, et al.                                                 [Page 1]


Internet Draft  draft-ietf-pals-status-reduction-05.txt         May 2017


   (SP) to reliably monitor the individual PW status while not
   overwhelming the network with multiple periodic status messages. This
   is achieved by sending a single cumulative summary status
   verification message for all the PWs grouped in the same LSP.



Table of Contents

    1        Introduction  .........................................   3
    1.1      Requirements Language  ................................   3
    1.2      Terminology  ..........................................   3
    1.3      Notational Conventions in Backus-Naur Form  ...........   4
    2        PW status refresh reduction protocol  .................   4
    2.1      Protocol states  ......................................   4
    2.1.1    INACTIVE  .............................................   5
    2.1.2    STARTUP  ..............................................   5
    2.1.3    ACTIVE  ...............................................   5
    2.2      Timer value change transition procedure  ..............   5
    3        PW status refresh reduction procedure  ................   6
    4        PW status refresh reduction Message Encoding  .........   6
    5        PW status refresh reduction Control Messages  .........  10
    5.1      Notification message  .................................  10
    5.2      PW Configuration Message  .............................  11
    5.2.1    MPLS-TP Tunnel ID  ....................................  12
    5.2.2    PW ID configured List  ................................  13
    5.2.3    PW ID unconfigured List  ..............................  13
    6        PW provisioning verification procedure  ...............  14
    6.0.4    PW ID List advertising and processing  ................  15
    7        Security Considerations  ..............................  15
    8        IANA Considerations  ..................................  15
    8.1      PW Status Refresh Reduction Message Types  ............  15
    8.2      PW Configuration Message Sub-TLVs  ....................  16
    8.3      PW Status Refresh Reduction Notification Codes  .......  16
    8.4      PW status refresh reduction Message Flags  ............  17
    8.5      G-ACH Registry Allocation  ............................  17
    8.6      Guidance for Designated Experts  ......................  17
    9        References  ...........................................  18
    9.1      Normative References  .................................  18
    9.2      Informative References  ...............................  18
   10        Authors' Addresses  ...................................  18










Martini, et al.                                                 [Page 2]


Internet Draft  draft-ietf-pals-status-reduction-05.txt         May 2017


1. Introduction

   When PWs use a Multi Protocol Label Switched (MPLS) network as the
   Packet Switched Network (PSN), they are setup according to [RFC8077]
   static configuration mode and the PW status information is propagated
   using the method described in [RFC6478]. There are 2 basic modes of
   operation described in [RFC6478] section 5.3: Periodic retransmission
   of non-zero status messages, and a simple acknowledgement of PW
   status (sec 5.3.1 of [RFC6478]).  The LSP level protocol described
   below applies to the case when PW status is acknowledged immediately
   with a requested refresh value of zero (no refresh).  In this case
   the PW status refresh reduction protocol is necessary for several
   reasons, such as:

        -i. Greatly increase the scalability of the PW status protocol
            by reducing the amount of messages that a PE needs to
            periodically send to it's neighbors.
       -ii. Detect a remote PE restart.
      -iii. If the local state is lost for some reason, the PE needs to
            be able to request a status refresh reduction from the
            remote PE
       -iv. Optionally detect a remote PE provisioning change.


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 [RFC2119].


1.2. Terminology

   FEC: Forwarding Equivalence Class

   LDP: Label Distribution Protocol

   LSP: Label Switching Path

   MS-PW: Multi-Segment Pseudowire

   PE: Provider Edge

   PW: Pseudowire

   SS-PW: Single-Segment Pseudowire

   S-PE: Switching Provider Edge Node of MS-PW



Martini, et al.                                                 [Page 3]


Internet Draft  draft-ietf-pals-status-reduction-05.txt         May 2017


   T-PE: Terminating Provider Edge Node of MS-PW


1.3. Notational Conventions in Backus-Naur Form

   All multiple-word atomic identifiers use underscores (_) between the
   words to join the words.  Many of the identifiers are composed of a
   concatenation of other identifiers.  These are expressed using
   Backus-Naur Form (using double-colon - "::" - notation).

   Where the same identifier type is used multiple times in a
   concatenation, they are qualified by a prefix joined to the
   identifier by a dash (-).  For example Src-Node_ID is the Node_ID of
   a node referred to as Src (where "Src" is short for "source" in this
   example).

   The notation does not define an implicit ordering of the information
   elements involved in a concatenated identifier.


2. PW status refresh reduction protocol

   PW status refresh reduction protocol consists of a simple message
   that is sent at the LSP level using the MPLS Generic Associated
   Channel.[RFC5586]

   A PE using the PW status refresh reduction protocol, for a particular
   LSP where this protocol is enabled, MUST send the PW status refresh
   reduction Message as soon as a PW is configured on that LSP. The
   message is then re-transmitted at a locally configured interval
   indicated in the refresh timer field. If no acknowledgment is
   received, the protocol does not reach active state, and the PE SHOULD
   NOT send any PW status messages with a refresh timer of zero as
   described in [RFC6478] section 5.3.1.

   It is worth noting that no relationship is existing between the
   locally configured timer for the refresh reduction protocol and the
   PW individual status refresh timers.


2.1. Protocol states

   The protocol can be in 3 possible states: INACTIVE, STARTUP, and
   ACTIVE.







Martini, et al.                                                 [Page 4]


Internet Draft  draft-ietf-pals-status-reduction-05.txt         May 2017


2.1.1. INACTIVE

   This state is entered when the protocol is turned off. This state is
   also entered if all PW on a specific LSP are deprovisioned, or the
   feature is deprovisioned.


2.1.2. STARTUP

   In this state the PE transmits periodic PW status refresh reduction
   messages, with the Ack Session ID set to 0. The PE remains in this
   state until a PW status refresh message is received with the correct
   local session ID in the Ack Session ID Field. This state can be
   exited to the ACTIVE or INACTIVE state.


2.1.3. ACTIVE

   This state is entered once the PE receives a PW status refresh
   reduction message with the correct local session ID in the Ack
   Session ID Field within 3.5 times the refresh timer field value of
   the last PW status refresh reduction message transmitted. This state
   is immediately exited as follows:

        -i. A valid PW status refresh reduction message is not received
            within 3.5 times the current refresh timer field value.
            (assuming a timer transition procedure is not in progress)
            New state: STARTUP
       -ii. A PW status refresh reduction message is received with the
            wrong, or a zero, Ack Session ID field value. New state:
            STARTUP
      -iii. All PWs using the particular LSP are deprovisioned, or the
            protocol is disabled. New state: INACTIVE


2.2. Timer value change transition procedure

   If a PE needs to change the refresh timer value field while the PW
   refresh reduction protocol is in the ACTIVE state, the following
   procedure must be followed:
        -i. A PW status refresh reduction message is transmitted with
            the new timer value.
       -ii. If the new value is greater then the original one the PE
            will operate on the new timer value immediately.
      -iii. If the new value is smaller then the original one, the PE
            will operate according to the original timer value for a
            period 3.5 times the original timer value, or until the
            first valid PW status refresh reduction message is received.



Martini, et al.                                                 [Page 5]


Internet Draft  draft-ietf-pals-status-reduction-05.txt         May 2017


            A PE receiving a PW status refresh reduction message with a
            new timer value, will immediately transmit an acknowledge PW
            status refresh reduction message, and start operating
            according to the new timer value.


3. PW status refresh reduction procedure

   When the refresh reduction protocol, on a particular LSP, is in the
   ACTIVE state, the PE can send all PW status messages, for PWs on that
   LSP, with a refresh timer value of zero. This greatly decreases the
   amount of messages that the PE needs to transmit to the remote PE
   because once the PW status message for a particular PW is
   acknowledged, further repetitions of that message are no longer
   necessary.

   To further mitigate the amount of possible messages when an LSP
   starts forwarding traffic, care should be taken to permit the PW
   refresh reduction protocol to reach the ACTIVE state quickly, and
   before the first PW status refresh timer expires. This can be
   achieved by using a PW status refresh reduction Message refresh timer
   value that is much smaller then the PW status message refresh timer
   value in use. (sec 5.3.1 of [RFC6478])

   If the refresh reduction protocol session is terminated by entering
   the INACTIVE or STARTUP states, the PE MUST immediately re-send all
   the previously sent PW status messages for that particular LSP for
   which the session terminated. In this case the refresh timer value
   MUST NOT be set to zero, and MUST be set according to the local
   policy of the PE router. Care MUST be considered by implementations
   to avoid flooding the remote PE with a large number of PW status
   messages at once. if the refresh reduction protocol session is
   terminated for administrative reasons, and the local PE can still
   communicate with the remote PE, the local PE SHOULD pace the
   transmission of PW status messages to the remote PE.


4. PW status refresh reduction Message Encoding

   The packet containing the refresh reduction message is encoded as
   follows: (omitting link layer information)










Martini, et al.                                                 [Page 6]


Internet Draft  draft-ietf-pals-status-reduction-05.txt         May 2017


    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               MPLS LSP (tunnel) Label Stack Entry             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              GAL                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 1|Version|   Reserved    | 0xZZ PW OAM Message           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Session ID           |         Ack Session ID        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Refresh Timer         |     Total Message Length      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Checksum              |    Message Sequence Number    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Last Received Seq Number     | Message Type  |U|C|   Flags   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                     Control Message Body                      ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   This message contains the following fields:

     * MPLS LSP (tunnel) Label Stack Entry

       This is explained in [RFC3031].

     * GAL

       The GAL and the next 4 octets are explained in [RFC5586].
     * PW OAM Message.

       This field indicates the Generic Associated Channel type in the
       GACH header as defined in [RFC5586].

       Note: Channel type 0xZZ pending IANA allocation.

     * Session ID

       A non-zero, locally selected session number that is not preserved
       if the local PE restarts.

       In order to get a locally unique session ID, the recommended
       choice is to perform a CRC-16 giving as input the following data

       |YY|MM|DD|HHMMSSLLL|



Martini, et al.                                                 [Page 7]


Internet Draft  draft-ietf-pals-status-reduction-05.txt         May 2017


       Where:  YY: are the decimal two last digit of the current year
       MM: are the decimal two digit of the current month DD: are the
       decimal two digit of the current day HHMMSSLLL: are the decimal
       digits of the current time expressed in (hour, minutes, seconds,
       milliseconds) If the calculation results in an already existing
       Session ID, a unique Session ID can be generated by adding 1 to
       the result until the Session ID is unique.  Any other method to
       generate a locally unique session ID is also acceptable.

     * Ack Session ID

       The Acknowledgment Session ID received from the remote PE.

     * Refresh Timer.

       A non zero unsigned 16 bit integer value greater or equal to 10,
       in milliseconds, that indicates the desired refresh interval. The
       default value of 30000 is RECOMMENDED.

     * Total Message Length

       Total length in octets of the Checksum, Message Type, Flags,
       Message Sequence Number, and control message body. A value of
       zero means that no control message is present, and therefore that
       no Checksum, and following fields are present either.

     * Checksum

       A 16 bit field containing the one's complement of the one's
       complement sum of the entire message (including the GACH header),
       with the checksum field replaced by zero for the purpose of
       computing the checksum. An all-zero value means that no checksum
       was transmitted. Note that when the checksum is not computed, the
       header of the bundle message will not be covered by any checksum.

     * Message Sequence Number

       An unsigned 16 bit integer number that is started from 1 when the
       protocol enters ACTIVE state. The sequence numbers wraps back to
       1 when the maximum value is reached. The value of zero is
       reserved and MUST NOT be used.

     * Last Received Message Sequence Number

       The sequence number of the last message received. In no message
       has yet been received during this session, this field is set to
       zero.




Martini, et al.                                                 [Page 8]


Internet Draft  draft-ietf-pals-status-reduction-05.txt         May 2017


     * Message Type

       The Type of the control message that follows. Control message
       types are allocated in this document, and by IANA.

     * (U) Unknown flag bit.

       Upon receipt of an unknown message or TLV, if U is clear (=0), a
       notification message of "Unknown TLV (U-bit=0)" code 0x4 MUST be
       sent to the remote PE, and the keepalive session MUST be
       terminated by entering STARTUP state; if U is set (=1), the
       unknown message, or message contining a unknown TLV, MUST be
       acknowledged and silently ignored and the following messages, or
       TLVs, if any, processed as if the unknown message, or TLV did not
       exist.  In this case the PE MAY send back a single notification
       message per keepalive session with code "Unknown TLV (U-bit=1)".
       This last Step is OPTIONAL.

     * (C) Configuration flag bit.

       The C Bit is used to signal the end of PW configuration
       transmission. If it is set, the sending PE has finished sending
       all it's current configuration information.

     * Flags

       The remaining 6 bits of PW status refresh reduction Message Flags
       to be allocated by IANA. These unallocated bits MUST be set to 0
       on transmission, and ignored on reception.

     * Control Message Body

       The Control Message body is defined in a section below, and is
       specific to the type of message.

   It should be noted that the Checksum, Message Sequence Number, Last
   Received Message Sequence Number, Message Type, Flags, and control
   message body are OPTIONAL. The length field is used to parse how many
   optional fields are included. Hence all optional fields that precede
   a specific field that needs to be included in a specific
   implementation MUST be included if that optional field is also
   included.

   If any of the above values are outside the specified range, a
   notification message is returned with a code "PW configuration not
   supported.", and the message is ignored.





Martini, et al.                                                 [Page 9]


Internet Draft  draft-ietf-pals-status-reduction-05.txt         May 2017


5. PW status refresh reduction Control Messages

   PW status refresh reduction Control messages consist of the Checksum,
   Message Sequence Number, Last Received Message Sequence Number,
   Message Type, Flags, and control message body.

   When there is the need to send a PW status refresh reduction Control
   Messages, the system can attach it to a scheduled PW status refresh
   reduction or send one ahead of time. In any case PW status refresh
   reduction Control Messages always piggy back on normal messages.

   A PW refresh reduction message is also called a PW status refresh
   reduction Control Message if it contains a  control message
   construct.

   There can only be one control message construct per PW status refresh
   reduction Message. If the U bit is set, and a PE receiving the PW
   status refresh reduction Message does not understand the control
   message, the control message MUST be silently ignored. However the
   message sequence number MUST still be acknowledged by sending a null
   message back with the appropriate value in the Last Message Received
   Field. If a control message is not acknowledged, after 3.5 times the
   value of the Refresh Timer, a fatal notification "unacknowledged
   control message" MUST be sent, and the PW refresh reduction session
   MUST be terminated.

   If a PE does not want or need to send a control message, the
   Checksum, and all following fields MUST NOT be sent, and the Total
   Message Length field is then set to zero.


5.1. Notification message

   The most common use of the Notification Message is to acknowledge the
   reception of a message by indicating the received message sequence
   number in the "Last Received Sequence Number" field. The notification
   message is encoded 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Checksum              |    Message Sequence Number    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Last Received Seq Number     |  Type=0x01    |U|C|   Flags   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Notification Code                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+




Martini, et al.                                                [Page 10]


Internet Draft  draft-ietf-pals-status-reduction-05.txt         May 2017


   The message type is set to 0x01, and the U bit is treated as
   described in the above section. The Notification Codes are a 32 bit
   quantity assigned by IANA. (see IANA consideration section)
   Notification codes are either considered "Error codes" or simple
   notifications. If the Notification code is an Error code as indicated
   in the IANA allocation registry, the keepalive session MUST be
   terminated by entering STARTUP state.

   When there is no notification information to be sent, the
   notification code is set to 0 to indicate a "Null Notification".  The
   C Bit MUST  always be set to 0 in this type of message.  The
   remaining 6 bits of PW status refresh reduction Message Flags to be
   allocated by IANA. These unallocated bits MUST be set to 0 on
   transmission, and ignored on reception.


5.2. PW Configuration Message

   The PW status refresh reduction TLVs are informational TLVs, that
   allow the remote PE to verify certain provisioning information. This
   message contain a series of sub-TLVs in no particular order, that
   contain PW and LSP configuration information. The message has no
   preset length limit, however its total length will be limited by the
   transport network Maximum Transmit Unit (MTU). PW refresh reduction
   messages MUST NOT be fragmented. If a sender has more configuration
   information to send than will fit into one PW Configuration Message
   it may send further messages carrying further TLVs.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Checksum              |    Message Sequence Number    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Last Received Seq Number     |  Type=0x02    |U|C|   Flags   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                                                               ~
   |                  PW Configuration Message Sub-TLVs            |
   ~                                                               ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   The PW Configuration Message type is set to 0x02. For this message
   the U-bit is set to 1 as processing of these messages is OPTIONAL.

   The C Bit is used to signal the end of PW configuration transmission.
   If it is set, the sending PE has finished sending all its current
   configuration information. The PE transmitting the configuration MUST
   set the C bit on the last PW configuration message when all current



Martini, et al.                                                [Page 11]


Internet Draft  draft-ietf-pals-status-reduction-05.txt         May 2017


   PW configuration has been sent.

   PW Configuration Message Sub-TLVs have the following generic format:

    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                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                                                               ~
   |                  Value Continued                              |
   ~                                                               ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



5.2.1. MPLS-TP Tunnel ID

   This TLV contains the MPLS-TP tunnel ID. When the configuration
   message is used for a particular keepalive session the MPLS-TP Tunnel
   ID sub-TLV MUST be sent at least once.

   The MPLS Tunnel ID is encoded 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=0x01   |  Length=20    |      MPLS-TP Tunnel ID        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                                                               ~
   |                  MPLS-TP Tunnel ID  (20 Octets)               |
   ~                                                               ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   The MPLS point to point tunnel ID is defined in [RFC6370] as follows:

   Src-Global_Node_ID::Src-Tunnel_Num::Dst-Global_Node_ID::Dst-
   Tunnel_Num

   Note that a single Tunnel ID is enough to identify the tunnel, and
   the source end of the message.









Martini, et al.                                                [Page 12]


Internet Draft  draft-ietf-pals-status-reduction-05.txt         May 2017


5.2.2. PW ID configured List

   This OPTIONAL TLV contains a list of the provisioned PWs on the LSP.

    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=0x02   |    Length     |         PW Path ID            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                         PW Path ID                            |
   ~                                                               ~
   |                         Continued                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   The PW Path ID is a 32 octet pseudowire path identifier specified in
   [RFC6370] as follows: AGI::Src-Global_ID::Src-Node_ID::Src-AC_ID::
   Dst-Global_ID::Dst-Node_ID::Dst-AC_ID

   The number of PW Path IDs in the TLV will be inferred by the length
   of the TLV up to a maximum of 8.  The procedure for processing this
   TLV will be described in a section below.


5.2.3. PW ID unconfigured List

   This OPTIONAL TLV contains a list of the PWs that have been
   deprovisioned on the LSP. Note that it is a fatal session error to
   send the same PW address in both the configured list TLV , and the
   unconfigured list TLV in the same configuration message. If the this
   error occurs, an error notification message is returned with the
   error code of "PW Configuration TLV conflict" and the session is
   terminated by entering STARTUP state.

    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=0x03   |    Length     |         PW Path ID            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                        PW Path ID                             |
   ~                                                               ~
   |                         Continued                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   The PW Path ID is a 32 octet pseudowire path identifier specified in



Martini, et al.                                                [Page 13]


Internet Draft  draft-ietf-pals-status-reduction-05.txt         May 2017


   [RFC6370] as follows: AGI::Src-Global_ID::Src-Node_ID::Src-AC_ID::
   Dst-Global_ID::Dst-Node_ID::Dst-AC_ID

   The number of PW Path IDs in the TLV will be inferred by the length
   of the TLV up to a maximum of 8.


6. PW provisioning verification procedure

   The advertisement of the PW configuration message is OPTIONAL.

   A PE that desires to use the PW configuration message to verify the
   configuration of PWs on a particular LSP, should advertise its PW
   configuration to the remote PE on LSPs that have active keepalive
   sessions.  When a PE receives PW configuration information using this
   protocol and it is not supporting or is not willing to use the
   information, it MUST acknowledge all the PW configuration messages
   with a notification of "PW configuration not supported". In this
   case, the information in the control messages is silently ignored. If
   a PE receives such a notification it SHOULD stop sending PW
   configuration control messages for the duration of the PW refresh
   reduction keepalive session.

   If PW configuration information is received, it is used to verify the
   accuracy of the local configuration information against the remote
   PE's configuration information. If a configuration mismatch is
   detected, where a particular PW is configured locally but not on the
   remote PE, the following action SHOULD be taken:

        -i. The local PW MUST be considered in "Not Forwarding" State.

       -ii. The PW Attachment Circuit status is set to reflect the PW
            fault.

      -iii. An Alarm SHOULD be raised to a network management system.

       -iv. A Notification message with notification code of "PW
            configuration mismatch." MUST be sent to the remote PE. Only
            one such message is REQUIRED per configuration message even
            if the configuration message is split into multiple
            configuration messages due to individual message size
            restriction on a particular link. Upon receipt of such a
            message the receiving PE MAY raise an alarm to a network
            management system. This alarm MAY be cleared when the
            configuration is updated.






Martini, et al.                                                [Page 14]


Internet Draft  draft-ietf-pals-status-reduction-05.txt         May 2017


6.0.4. PW ID List advertising and processing

   When configuration messages are advertised along a particular LSP,
   the PE sending the messages needs to check point the configuration
   information sent by setting the C bit when all currently known
   configuration information has been sent. This process allows the
   receiving PE to immediately proceed to verify all the currently
   configured PWs on that LSP, eliminating the need for a long waiting
   period.

   If a new PW is added to a particular LSP, the PE MUST place the
   configuration verification of this PW on hold for a period of at
   least 30 seconds. This is necessary to minimize false positive events
   of mis-configuration due to the ends of the PW being slightly out of
   sync.


7. Security Considerations

   The security considerations of [RFC6478] are adequate for the
   proposed mechanism since the operating environment is almost
   identical to the one where this protocol would be deployed. It should
   also be noted that since this protocol is designed to be deployed
   between two adjacent PEs connected by a physical link, it is not
   possible to misdirect or inject traffic without compromising the PW
   transport link itself. All these situations are covered in the
   security considerations of [RFC6478].


8. IANA Considerations

   All the registries in this section are to be created or updated as
   appropriate in the Pseudowire Name Spaces (PWE3). For the allocation
   ranges designated as "vendor proprietary extensions", the respective
   IANA registry, will contain the vendor name in brackets at the end of
   the description field.


8.1. PW Status Refresh Reduction Message Types

   IANA needs to set up a registry of "PW status refresh reduction
   Control Messages". These are 8-bit values. Type value 1 through 2 are
   defined in this document. Type values 3 through 64, and 128 through
   254 are to be assigned by IANA using the "Expert Review" policy
   defined in RFC5226. Type values 65 through 127, 0 and 255 are to be
   allocated using the IETF review policy defined in [RFC5226].

   The Type Values are assigned as follows:



Martini, et al.                                                [Page 15]


Internet Draft  draft-ietf-pals-status-reduction-05.txt         May 2017


   Type   Message Description
   ----   -------------------
   0x01   Notification message
   0x02   PW Configuration Message


8.2. PW Configuration Message Sub-TLVs

   IANA needs to set up a registry of "PW status refresh reduction
   Configuration Message Sub-TLVs". These are 8-bit values. Type value 1
   through 3 are defined in this document. Type values 3 through 64, and
   128 through 254 are to be assigned by IANA using the "Expert Review"
   policy defined in RFC5226. Type values 65 through 127, 0 and 255 are
   to be allocated using the IETF review policy defined in [RFC5226].

   The Type Values are assigned as follows:
   sub-TLV type    Description
   ------------    -----------
   0x01            MPLS-TP Tunnel ID.
   0x02            PW ID configured List.
   0x03            PW ID unconfigured List.


8.3. PW Status Refresh Reduction Notification Codes

   IANA needs to set up a registry of "PW status refresh reduction
   Notification Codes". These are 32-bit values. Type value 0 through 7
   are defined in this document. Type values 8 through 65536, and
   134,217,729 through 4,294,967,294 are to be assigned by IANA using
   the "Expert Review" policy defined in RFC5226. Type values 65536
   through 134,217,728, 0 and 4,294,967,295 are to be allocated using
   the IETF review policy defined in [RFC5226].

   For each value assigned IANA should also track whether the value
   constitutes an error as described in Section 5.1. When values are
   assigned by IETF review, the setting of this column must be
   documented in the RFC that requests the allocation. For Expert Review
   assignments, the setting of this column must be made clear by the
   requester at the time of assignment.

   The Type Values are assigned as follows:
   Code        Error?  Description
   ----     ------  -----------
   0x00000000    No    Null Notification.
   0x00000001    No    PW configuration mismatch.
   0x00000002    Yes   PW Configuration TLV conflict.
   0x00000003    No    Unknown TLV (U-bit=1)
   0x00000004    Yes   Unknown TLV (U-bit=0)



Martini, et al.                                                [Page 16]


Internet Draft  draft-ietf-pals-status-reduction-05.txt         May 2017


   0x00000005    No    Unknown Message Type
   0x00000006    No    PW configuration not supported.
   0x00000007    Yes   Unacknowledged control message.


8.4. PW status refresh reduction Message Flags

   IANA needs to set up a registry of "PW status refresh reduction
   Message Flags". This is a 8 bit registry with the first 2 most
   significant bits allocated by this document as follows:
   Bit Position  Name    Description
   ------------  ----    -----------
        0       U      Unknown flag bit.
        1       C      Configuration flag bit.

   The remaining bits are to be allocated by "IETF Review" policy
   defined in [RFC5226].


8.5. G-ACH Registry Allocation

   IANA maintains a registry called "MPLS Generalized Associated Channel
   (G-ACh) Types". IANA needs, to allocate a new value as follows:
   Value     Description                      Reference
   -----     -----------                      ---------
   0xZZ   PW Status Refresh Reduction     RFCXXXX


8.6. Guidance for Designated Experts

   In all cases of review by the Designated Expert (DE) described here,
   the DE is expected to ascertain the existence of suitable
   documentation (a specification) as described in [RFC5226] and to
   verify that the document is permanently and publicly available. The
   DE is also expected to check the clarity of purpose and use of the
   requested code points fits the general architecture and intended
   purpose of the respective message or TLV. Lastly the DE should check
   that any assignment does not duplicate or conflict with work that is
   active or already published within the IETF.












Martini, et al.                                                [Page 17]


Internet Draft  draft-ietf-pals-status-reduction-05.txt         May 2017


9. References

9.1. Normative References

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

   [RFC8077] "Pseudowire Setup and Maintenance Using the Label
        Distribution Protocol (LDP)", L. Martini, G. Heron, RFC8077,
        february 2017.

   [RFC6478] L. Martini, G. Swallow, G. Heron, M. Bocci "Pseudowire
        Status for Static Pseudowires", RFC6478, May 2012

   [RFC6370] M. Bocci, G. Swallow, E. Gray "MPLS-TP Identifiers",
        RFC6370, September 2011

   [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
        IANA Considerations section in RFCs", BCP 26, RFC 5226, May 2008

   [RFC3031] E. Rosen, et al., RFC 3031, MPLS Architecture, January
        2001.


9.2. Informative References

   [RFC5586] M. Bocci, Ed., M. Vigoureux, Ed., S. Bryant, Ed.,
        "MPLS Generic Associated Channel", rfc5586,  June 2009


10. Authors' Addresses


   Luca Martini
   Monoski LLC.
   e-mail: lmartini@monoski.com


   George Swallow
   Cisco Systems, Inc.
   300 Beaver Brook Road
   Boxborough, Massachusetts  01719
   United States
   e-mail: swallow@cisco.com







Martini, et al.                                                [Page 18]


Internet Draft  draft-ietf-pals-status-reduction-05.txt         May 2017



   Elisa Bellagamba
   Ericsson EAB
   Torshamnsgatan 48
   16480, Stockholm
   Sweden
   e-mail: elisa.bellagamba@gmail.com


Copyright Notice

   Copyright (c) 2017 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.

   Expiration Date: November 2017


























Martini, et al.                                                [Page 19]


Html markup produced by rfcmarkup 1.124, available from https://tools.ietf.org/tools/rfcmarkup/