Internet Engineering Task Force L. Martini Internet-Draft Monoski LLC Intended status: Standards Track G. Swallow Expires: November 2, 2017 Cisco E. Bellagamba Ericsson May 2017 MPLS LSP PW status refresh reduction for Static Pseudowires draft-ietf-pals-status-reduction-05.txt 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 (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. 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 November 2, 2017. Martini, et al. Expires November 2, 2017 [Page 1] Internet-Draft draft-ietf-pals-status-reduction-05.txt May 2017 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. 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.1. 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 Martini, et al. Expires November 2, 2017 [Page 2] Internet-Draft draft-ietf-pals-status-reduction-05.txt May 2017 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 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 Martini, et al. Expires November 2, 2017 [Page 3] Internet-Draft draft-ietf-pals-status-reduction-05.txt May 2017 PW: Pseudowire SS-PW: Single-Segment Pseudowire S-PE: Switching Provider Edge Node of MS-PW 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. Expires November 2, 2017 [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. Martini, et al. Expires November 2, 2017 [Page 5] Internet-Draft draft-ietf-pals-status-reduction-05.txt May 2017 -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. 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. Expires November 2, 2017 [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. Martini, et al. Expires November 2, 2017 [Page 7] Internet-Draft draft-ietf-pals-status-reduction-05.txt May 2017 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| 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 Martini, et al. Expires November 2, 2017 [Page 8] Internet-Draft draft-ietf-pals-status-reduction-05.txt May 2017 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. * 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 Martini, et al. Expires November 2, 2017 [Page 9] Internet-Draft draft-ietf-pals-status-reduction-05.txt May 2017 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. 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: Martini, et al. Expires November 2, 2017 [Page 10] 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum | Message Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Last Received Seq Number | Type=0x01 |U|C| Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Notification Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 | ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Martini, et al. Expires November 2, 2017 [Page 11] Internet-Draft draft-ietf-pals-status-reduction-05.txt May 2017 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 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. Expires November 2, 2017 [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 [RFC6370] as follows: AGI::Src-Global_ID::Src-Node_ID::Src-AC_ID:: Dst-Global_ID::Dst-Node_ID::Dst-AC_ID Martini, et al. Expires November 2, 2017 [Page 13] Internet-Draft draft-ietf-pals-status-reduction-05.txt May 2017 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. Expires November 2, 2017 [Page 14] Internet-Draft draft-ietf-pals-status-reduction-05.txt May 2017 6.1. 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. Expires November 2, 2017 [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. Martini, et al. Expires November 2, 2017 [Page 16] Internet-Draft draft-ietf-pals-status-reduction-05.txt May 2017 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) 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. Expires November 2, 2017 [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", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8077] Martini, L., Ed. and G. Heron, Ed., "Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)", STD 84, RFC 8077, DOI 10.17487/RFC8077, February 2017, . [RFC6478] Martini, L., Swallow, G., Heron, G., and M. Bocci, "Pseudowire Status for Static Pseudowires", RFC 6478, DOI 10.17487/RFC6478, May 2012, . [RFC6370] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport Profile (MPLS-TP) Identifiers", RFC 6370, DOI 10.17487/RFC6370, September 2011, . [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", RFC 5226, DOI 10.17487/RFC5226, May 2008, . [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, DOI 10.17487/RFC3031, January 2001, . 9.2. Informative References [RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., "MPLS Generic Associated Channel", RFC 5586, DOI 10.17487/RFC5586, June 2009, . Authors' Addresses Luca Martini Monoski LLC. e-mail: lmartini@monoski.com Martini, et al. Expires November 2, 2017 [Page 18] Internet-Draft draft-ietf-pals-status-reduction-05.txt May 2017 George Swallow Cisco Systems, Inc. 300 Beaver Brook Road Boxborough, Massachusetts 01719 United States e-mail: swallow@cisco.com Elisa Bellagamba Ericsson EAB Torshamnsgatan 48 16480, Stockholm Sweden e-mail: elisa.bellagamba@gmail.com Martini, et al. Expires November 2, 2017 [Page 19]