idnits 2.17.1 draft-ietf-pals-status-reduction-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 2017) is 2537 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Luca Martini 3 Internet Draft Monoski LLC 4 Intended status: Standards Track George Swallow 5 Expires: November 2017 Cisco 6 Elisa Bellagamba 7 Ericsson 9 May 2017 11 MPLS LSP PW status refresh reduction for Static Pseudowires 13 draft-ietf-pals-status-reduction-05.txt 15 Status of this Memo 17 This Internet-Draft is submitted to IETF in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on November 10, 2010 38 Abstract 40 This document describes a method for generating an aggregated 41 pseudowire status message transmitted for a statically configured 42 pseudowire on a Multi-Protocol Label Switching (MPLS) Label Switched 43 Path (LSP) to indicate the status of one or more pseudowires carried 44 on the LSP. 46 The method for transmitting the pseudowire (PW) status information is 47 not new, however this protocol extension allows a Service Provider 48 (SP) to reliably monitor the individual PW status while not 49 overwhelming the network with multiple periodic status messages. This 50 is achieved by sending a single cumulative summary status 51 verification message for all the PWs grouped in the same LSP. 53 Table of Contents 55 1 Introduction ......................................... 3 56 1.1 Requirements Language ................................ 3 57 1.2 Terminology .......................................... 3 58 1.3 Notational Conventions in Backus-Naur Form ........... 4 59 2 PW status refresh reduction protocol ................. 4 60 2.1 Protocol states ...................................... 4 61 2.1.1 INACTIVE ............................................. 5 62 2.1.2 STARTUP .............................................. 5 63 2.1.3 ACTIVE ............................................... 5 64 2.2 Timer value change transition procedure .............. 5 65 3 PW status refresh reduction procedure ................ 6 66 4 PW status refresh reduction Message Encoding ......... 6 67 5 PW status refresh reduction Control Messages ......... 10 68 5.1 Notification message ................................. 10 69 5.2 PW Configuration Message ............................. 11 70 5.2.1 MPLS-TP Tunnel ID .................................... 12 71 5.2.2 PW ID configured List ................................ 13 72 5.2.3 PW ID unconfigured List .............................. 13 73 6 PW provisioning verification procedure ............... 14 74 6.0.4 PW ID List advertising and processing ................ 15 75 7 Security Considerations .............................. 15 76 8 IANA Considerations .................................. 15 77 8.1 PW Status Refresh Reduction Message Types ............ 15 78 8.2 PW Configuration Message Sub-TLVs .................... 16 79 8.3 PW Status Refresh Reduction Notification Codes ....... 16 80 8.4 PW status refresh reduction Message Flags ............ 17 81 8.5 G-ACH Registry Allocation ............................ 17 82 8.6 Guidance for Designated Experts ...................... 17 83 9 References ........................................... 18 84 9.1 Normative References ................................. 18 85 9.2 Informative References ............................... 18 86 10 Authors' Addresses ................................... 18 88 1. Introduction 90 When PWs use a Multi Protocol Label Switched (MPLS) network as the 91 Packet Switched Network (PSN), they are setup according to [RFC8077] 92 static configuration mode and the PW status information is propagated 93 using the method described in [RFC6478]. There are 2 basic modes of 94 operation described in [RFC6478] section 5.3: Periodic retransmission 95 of non-zero status messages, and a simple acknowledgement of PW 96 status (sec 5.3.1 of [RFC6478]). The LSP level protocol described 97 below applies to the case when PW status is acknowledged immediately 98 with a requested refresh value of zero (no refresh). In this case 99 the PW status refresh reduction protocol is necessary for several 100 reasons, such as: 102 -i. Greatly increase the scalability of the PW status protocol 103 by reducing the amount of messages that a PE needs to 104 periodically send to it's neighbors. 105 -ii. Detect a remote PE restart. 106 -iii. If the local state is lost for some reason, the PE needs to 107 be able to request a status refresh reduction from the 108 remote PE 109 -iv. Optionally detect a remote PE provisioning change. 111 1.1. Requirements Language 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 115 document are to be interpreted as described in [RFC2119]. 117 1.2. Terminology 119 FEC: Forwarding Equivalence Class 121 LDP: Label Distribution Protocol 123 LSP: Label Switching Path 125 MS-PW: Multi-Segment Pseudowire 127 PE: Provider Edge 129 PW: Pseudowire 131 SS-PW: Single-Segment Pseudowire 133 S-PE: Switching Provider Edge Node of MS-PW 134 T-PE: Terminating Provider Edge Node of MS-PW 136 1.3. Notational Conventions in Backus-Naur Form 138 All multiple-word atomic identifiers use underscores (_) between the 139 words to join the words. Many of the identifiers are composed of a 140 concatenation of other identifiers. These are expressed using 141 Backus-Naur Form (using double-colon - "::" - notation). 143 Where the same identifier type is used multiple times in a 144 concatenation, they are qualified by a prefix joined to the 145 identifier by a dash (-). For example Src-Node_ID is the Node_ID of 146 a node referred to as Src (where "Src" is short for "source" in this 147 example). 149 The notation does not define an implicit ordering of the information 150 elements involved in a concatenated identifier. 152 2. PW status refresh reduction protocol 154 PW status refresh reduction protocol consists of a simple message 155 that is sent at the LSP level using the MPLS Generic Associated 156 Channel.[RFC5586] 158 A PE using the PW status refresh reduction protocol, for a particular 159 LSP where this protocol is enabled, MUST send the PW status refresh 160 reduction Message as soon as a PW is configured on that LSP. The 161 message is then re-transmitted at a locally configured interval 162 indicated in the refresh timer field. If no acknowledgment is 163 received, the protocol does not reach active state, and the PE SHOULD 164 NOT send any PW status messages with a refresh timer of zero as 165 described in [RFC6478] section 5.3.1. 167 It is worth noting that no relationship is existing between the 168 locally configured timer for the refresh reduction protocol and the 169 PW individual status refresh timers. 171 2.1. Protocol states 173 The protocol can be in 3 possible states: INACTIVE, STARTUP, and 174 ACTIVE. 176 2.1.1. INACTIVE 178 This state is entered when the protocol is turned off. This state is 179 also entered if all PW on a specific LSP are deprovisioned, or the 180 feature is deprovisioned. 182 2.1.2. STARTUP 184 In this state the PE transmits periodic PW status refresh reduction 185 messages, with the Ack Session ID set to 0. The PE remains in this 186 state until a PW status refresh message is received with the correct 187 local session ID in the Ack Session ID Field. This state can be 188 exited to the ACTIVE or INACTIVE state. 190 2.1.3. ACTIVE 192 This state is entered once the PE receives a PW status refresh 193 reduction message with the correct local session ID in the Ack 194 Session ID Field within 3.5 times the refresh timer field value of 195 the last PW status refresh reduction message transmitted. This state 196 is immediately exited as follows: 198 -i. A valid PW status refresh reduction message is not received 199 within 3.5 times the current refresh timer field value. 200 (assuming a timer transition procedure is not in progress) 201 New state: STARTUP 202 -ii. A PW status refresh reduction message is received with the 203 wrong, or a zero, Ack Session ID field value. New state: 204 STARTUP 205 -iii. All PWs using the particular LSP are deprovisioned, or the 206 protocol is disabled. New state: INACTIVE 208 2.2. Timer value change transition procedure 210 If a PE needs to change the refresh timer value field while the PW 211 refresh reduction protocol is in the ACTIVE state, the following 212 procedure must be followed: 213 -i. A PW status refresh reduction message is transmitted with 214 the new timer value. 215 -ii. If the new value is greater then the original one the PE 216 will operate on the new timer value immediately. 217 -iii. If the new value is smaller then the original one, the PE 218 will operate according to the original timer value for a 219 period 3.5 times the original timer value, or until the 220 first valid PW status refresh reduction message is received. 222 A PE receiving a PW status refresh reduction message with a 223 new timer value, will immediately transmit an acknowledge PW 224 status refresh reduction message, and start operating 225 according to the new timer value. 227 3. PW status refresh reduction procedure 229 When the refresh reduction protocol, on a particular LSP, is in the 230 ACTIVE state, the PE can send all PW status messages, for PWs on that 231 LSP, with a refresh timer value of zero. This greatly decreases the 232 amount of messages that the PE needs to transmit to the remote PE 233 because once the PW status message for a particular PW is 234 acknowledged, further repetitions of that message are no longer 235 necessary. 237 To further mitigate the amount of possible messages when an LSP 238 starts forwarding traffic, care should be taken to permit the PW 239 refresh reduction protocol to reach the ACTIVE state quickly, and 240 before the first PW status refresh timer expires. This can be 241 achieved by using a PW status refresh reduction Message refresh timer 242 value that is much smaller then the PW status message refresh timer 243 value in use. (sec 5.3.1 of [RFC6478]) 245 If the refresh reduction protocol session is terminated by entering 246 the INACTIVE or STARTUP states, the PE MUST immediately re-send all 247 the previously sent PW status messages for that particular LSP for 248 which the session terminated. In this case the refresh timer value 249 MUST NOT be set to zero, and MUST be set according to the local 250 policy of the PE router. Care MUST be considered by implementations 251 to avoid flooding the remote PE with a large number of PW status 252 messages at once. if the refresh reduction protocol session is 253 terminated for administrative reasons, and the local PE can still 254 communicate with the remote PE, the local PE SHOULD pace the 255 transmission of PW status messages to the remote PE. 257 4. PW status refresh reduction Message Encoding 259 The packet containing the refresh reduction message is encoded as 260 follows: (omitting link layer information) 261 0 1 2 3 262 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 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 | MPLS LSP (tunnel) Label Stack Entry | 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 | GAL | 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 |0 0 0 1|Version| Reserved | 0xZZ PW OAM Message | 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 | Session ID | Ack Session ID | 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 | Refresh Timer | Total Message Length | 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 | Checksum | Message Sequence Number | 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 | Last Received Seq Number | Message Type |U|C| Flags | 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 | | 279 ~ Control Message Body ~ 280 | | 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 This message contains the following fields: 285 * MPLS LSP (tunnel) Label Stack Entry 287 This is explained in [RFC3031]. 289 * GAL 291 The GAL and the next 4 octets are explained in [RFC5586]. 292 * PW OAM Message. 294 This field indicates the Generic Associated Channel type in the 295 GACH header as defined in [RFC5586]. 297 Note: Channel type 0xZZ pending IANA allocation. 299 * Session ID 301 A non-zero, locally selected session number that is not preserved 302 if the local PE restarts. 304 In order to get a locally unique session ID, the recommended 305 choice is to perform a CRC-16 giving as input the following data 307 |YY|MM|DD|HHMMSSLLL| 308 Where: YY: are the decimal two last digit of the current year 309 MM: are the decimal two digit of the current month DD: are the 310 decimal two digit of the current day HHMMSSLLL: are the decimal 311 digits of the current time expressed in (hour, minutes, seconds, 312 milliseconds) If the calculation results in an already existing 313 Session ID, a unique Session ID can be generated by adding 1 to 314 the result until the Session ID is unique. Any other method to 315 generate a locally unique session ID is also acceptable. 317 * Ack Session ID 319 The Acknowledgment Session ID received from the remote PE. 321 * Refresh Timer. 323 A non zero unsigned 16 bit integer value greater or equal to 10, 324 in milliseconds, that indicates the desired refresh interval. The 325 default value of 30000 is RECOMMENDED. 327 * Total Message Length 329 Total length in octets of the Checksum, Message Type, Flags, 330 Message Sequence Number, and control message body. A value of 331 zero means that no control message is present, and therefore that 332 no Checksum, and following fields are present either. 334 * Checksum 336 A 16 bit field containing the one's complement of the one's 337 complement sum of the entire message (including the GACH header), 338 with the checksum field replaced by zero for the purpose of 339 computing the checksum. An all-zero value means that no checksum 340 was transmitted. Note that when the checksum is not computed, the 341 header of the bundle message will not be covered by any checksum. 343 * Message Sequence Number 345 An unsigned 16 bit integer number that is started from 1 when the 346 protocol enters ACTIVE state. The sequence numbers wraps back to 347 1 when the maximum value is reached. The value of zero is 348 reserved and MUST NOT be used. 350 * Last Received Message Sequence Number 352 The sequence number of the last message received. In no message 353 has yet been received during this session, this field is set to 354 zero. 356 * Message Type 358 The Type of the control message that follows. Control message 359 types are allocated in this document, and by IANA. 361 * (U) Unknown flag bit. 363 Upon receipt of an unknown message or TLV, if U is clear (=0), a 364 notification message of "Unknown TLV (U-bit=0)" code 0x4 MUST be 365 sent to the remote PE, and the keepalive session MUST be 366 terminated by entering STARTUP state; if U is set (=1), the 367 unknown message, or message contining a unknown TLV, MUST be 368 acknowledged and silently ignored and the following messages, or 369 TLVs, if any, processed as if the unknown message, or TLV did not 370 exist. In this case the PE MAY send back a single notification 371 message per keepalive session with code "Unknown TLV (U-bit=1)". 372 This last Step is OPTIONAL. 374 * (C) Configuration flag bit. 376 The C Bit is used to signal the end of PW configuration 377 transmission. If it is set, the sending PE has finished sending 378 all it's current configuration information. 380 * Flags 382 The remaining 6 bits of PW status refresh reduction Message Flags 383 to be allocated by IANA. These unallocated bits MUST be set to 0 384 on transmission, and ignored on reception. 386 * Control Message Body 388 The Control Message body is defined in a section below, and is 389 specific to the type of message. 391 It should be noted that the Checksum, Message Sequence Number, Last 392 Received Message Sequence Number, Message Type, Flags, and control 393 message body are OPTIONAL. The length field is used to parse how many 394 optional fields are included. Hence all optional fields that precede 395 a specific field that needs to be included in a specific 396 implementation MUST be included if that optional field is also 397 included. 399 If any of the above values are outside the specified range, a 400 notification message is returned with a code "PW configuration not 401 supported.", and the message is ignored. 403 5. PW status refresh reduction Control Messages 405 PW status refresh reduction Control messages consist of the Checksum, 406 Message Sequence Number, Last Received Message Sequence Number, 407 Message Type, Flags, and control message body. 409 When there is the need to send a PW status refresh reduction Control 410 Messages, the system can attach it to a scheduled PW status refresh 411 reduction or send one ahead of time. In any case PW status refresh 412 reduction Control Messages always piggy back on normal messages. 414 A PW refresh reduction message is also called a PW status refresh 415 reduction Control Message if it contains a control message 416 construct. 418 There can only be one control message construct per PW status refresh 419 reduction Message. If the U bit is set, and a PE receiving the PW 420 status refresh reduction Message does not understand the control 421 message, the control message MUST be silently ignored. However the 422 message sequence number MUST still be acknowledged by sending a null 423 message back with the appropriate value in the Last Message Received 424 Field. If a control message is not acknowledged, after 3.5 times the 425 value of the Refresh Timer, a fatal notification "unacknowledged 426 control message" MUST be sent, and the PW refresh reduction session 427 MUST be terminated. 429 If a PE does not want or need to send a control message, the 430 Checksum, and all following fields MUST NOT be sent, and the Total 431 Message Length field is then set to zero. 433 5.1. Notification message 435 The most common use of the Notification Message is to acknowledge the 436 reception of a message by indicating the received message sequence 437 number in the "Last Received Sequence Number" field. The notification 438 message is encoded as follows: 440 0 1 2 3 441 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 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 | Checksum | Message Sequence Number | 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 | Last Received Seq Number | Type=0x01 |U|C| Flags | 446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 | Notification Code | 448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 449 The message type is set to 0x01, and the U bit is treated as 450 described in the above section. The Notification Codes are a 32 bit 451 quantity assigned by IANA. (see IANA consideration section) 452 Notification codes are either considered "Error codes" or simple 453 notifications. If the Notification code is an Error code as indicated 454 in the IANA allocation registry, the keepalive session MUST be 455 terminated by entering STARTUP state. 457 When there is no notification information to be sent, the 458 notification code is set to 0 to indicate a "Null Notification". The 459 C Bit MUST always be set to 0 in this type of message. The 460 remaining 6 bits of PW status refresh reduction Message Flags to be 461 allocated by IANA. These unallocated bits MUST be set to 0 on 462 transmission, and ignored on reception. 464 5.2. PW Configuration Message 466 The PW status refresh reduction TLVs are informational TLVs, that 467 allow the remote PE to verify certain provisioning information. This 468 message contain a series of sub-TLVs in no particular order, that 469 contain PW and LSP configuration information. The message has no 470 preset length limit, however its total length will be limited by the 471 transport network Maximum Transmit Unit (MTU). PW refresh reduction 472 messages MUST NOT be fragmented. If a sender has more configuration 473 information to send than will fit into one PW Configuration Message 474 it may send further messages carrying further TLVs. 476 0 1 2 3 477 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 478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 479 | Checksum | Message Sequence Number | 480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 481 | Last Received Seq Number | Type=0x02 |U|C| Flags | 482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 ~ ~ 484 | PW Configuration Message Sub-TLVs | 485 ~ ~ 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 488 The PW Configuration Message type is set to 0x02. For this message 489 the U-bit is set to 1 as processing of these messages is OPTIONAL. 491 The C Bit is used to signal the end of PW configuration transmission. 492 If it is set, the sending PE has finished sending all its current 493 configuration information. The PE transmitting the configuration MUST 494 set the C bit on the last PW configuration message when all current 495 PW configuration has been sent. 497 PW Configuration Message Sub-TLVs have the following generic format: 499 0 1 2 3 500 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 501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 502 | Type | Length | Value | 503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 504 ~ ~ 505 | Value Continued | 506 ~ ~ 507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 509 5.2.1. MPLS-TP Tunnel ID 511 This TLV contains the MPLS-TP tunnel ID. When the configuration 512 message is used for a particular keepalive session the MPLS-TP Tunnel 513 ID sub-TLV MUST be sent at least once. 515 The MPLS Tunnel ID is encoded as follows: 517 0 1 2 3 518 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 519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 520 | Type=0x01 | Length=20 | MPLS-TP Tunnel ID | 521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 522 ~ ~ 523 | MPLS-TP Tunnel ID (20 Octets) | 524 ~ ~ 525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 527 The MPLS point to point tunnel ID is defined in [RFC6370] as follows: 529 Src-Global_Node_ID::Src-Tunnel_Num::Dst-Global_Node_ID::Dst- 530 Tunnel_Num 532 Note that a single Tunnel ID is enough to identify the tunnel, and 533 the source end of the message. 535 5.2.2. PW ID configured List 537 This OPTIONAL TLV contains a list of the provisioned PWs on the LSP. 539 0 1 2 3 540 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 541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 542 | Type=0x02 | Length | PW Path ID | 543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 544 | | 545 | PW Path ID | 546 ~ ~ 547 | Continued | 548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 550 The PW Path ID is a 32 octet pseudowire path identifier specified in 551 [RFC6370] as follows: AGI::Src-Global_ID::Src-Node_ID::Src-AC_ID:: 552 Dst-Global_ID::Dst-Node_ID::Dst-AC_ID 554 The number of PW Path IDs in the TLV will be inferred by the length 555 of the TLV up to a maximum of 8. The procedure for processing this 556 TLV will be described in a section below. 558 5.2.3. PW ID unconfigured List 560 This OPTIONAL TLV contains a list of the PWs that have been 561 deprovisioned on the LSP. Note that it is a fatal session error to 562 send the same PW address in both the configured list TLV , and the 563 unconfigured list TLV in the same configuration message. If the this 564 error occurs, an error notification message is returned with the 565 error code of "PW Configuration TLV conflict" and the session is 566 terminated by entering STARTUP state. 568 0 1 2 3 569 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 570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 571 | Type=0x03 | Length | PW Path ID | 572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 573 | | 574 | PW Path ID | 575 ~ ~ 576 | Continued | 577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 579 The PW Path ID is a 32 octet pseudowire path identifier specified in 581 [RFC6370] as follows: AGI::Src-Global_ID::Src-Node_ID::Src-AC_ID:: 582 Dst-Global_ID::Dst-Node_ID::Dst-AC_ID 584 The number of PW Path IDs in the TLV will be inferred by the length 585 of the TLV up to a maximum of 8. 587 6. PW provisioning verification procedure 589 The advertisement of the PW configuration message is OPTIONAL. 591 A PE that desires to use the PW configuration message to verify the 592 configuration of PWs on a particular LSP, should advertise its PW 593 configuration to the remote PE on LSPs that have active keepalive 594 sessions. When a PE receives PW configuration information using this 595 protocol and it is not supporting or is not willing to use the 596 information, it MUST acknowledge all the PW configuration messages 597 with a notification of "PW configuration not supported". In this 598 case, the information in the control messages is silently ignored. If 599 a PE receives such a notification it SHOULD stop sending PW 600 configuration control messages for the duration of the PW refresh 601 reduction keepalive session. 603 If PW configuration information is received, it is used to verify the 604 accuracy of the local configuration information against the remote 605 PE's configuration information. If a configuration mismatch is 606 detected, where a particular PW is configured locally but not on the 607 remote PE, the following action SHOULD be taken: 609 -i. The local PW MUST be considered in "Not Forwarding" State. 611 -ii. The PW Attachment Circuit status is set to reflect the PW 612 fault. 614 -iii. An Alarm SHOULD be raised to a network management system. 616 -iv. A Notification message with notification code of "PW 617 configuration mismatch." MUST be sent to the remote PE. Only 618 one such message is REQUIRED per configuration message even 619 if the configuration message is split into multiple 620 configuration messages due to individual message size 621 restriction on a particular link. Upon receipt of such a 622 message the receiving PE MAY raise an alarm to a network 623 management system. This alarm MAY be cleared when the 624 configuration is updated. 626 6.0.4. PW ID List advertising and processing 628 When configuration messages are advertised along a particular LSP, 629 the PE sending the messages needs to check point the configuration 630 information sent by setting the C bit when all currently known 631 configuration information has been sent. This process allows the 632 receiving PE to immediately proceed to verify all the currently 633 configured PWs on that LSP, eliminating the need for a long waiting 634 period. 636 If a new PW is added to a particular LSP, the PE MUST place the 637 configuration verification of this PW on hold for a period of at 638 least 30 seconds. This is necessary to minimize false positive events 639 of mis-configuration due to the ends of the PW being slightly out of 640 sync. 642 7. Security Considerations 644 The security considerations of [RFC6478] are adequate for the 645 proposed mechanism since the operating environment is almost 646 identical to the one where this protocol would be deployed. It should 647 also be noted that since this protocol is designed to be deployed 648 between two adjacent PEs connected by a physical link, it is not 649 possible to misdirect or inject traffic without compromising the PW 650 transport link itself. All these situations are covered in the 651 security considerations of [RFC6478]. 653 8. IANA Considerations 655 All the registries in this section are to be created or updated as 656 appropriate in the Pseudowire Name Spaces (PWE3). For the allocation 657 ranges designated as "vendor proprietary extensions", the respective 658 IANA registry, will contain the vendor name in brackets at the end of 659 the description field. 661 8.1. PW Status Refresh Reduction Message Types 663 IANA needs to set up a registry of "PW status refresh reduction 664 Control Messages". These are 8-bit values. Type value 1 through 2 are 665 defined in this document. Type values 3 through 64, and 128 through 666 254 are to be assigned by IANA using the "Expert Review" policy 667 defined in RFC5226. Type values 65 through 127, 0 and 255 are to be 668 allocated using the IETF review policy defined in [RFC5226]. 670 The Type Values are assigned as follows: 672 Type Message Description 673 ---- ------------------- 674 0x01 Notification message 675 0x02 PW Configuration Message 677 8.2. PW Configuration Message Sub-TLVs 679 IANA needs to set up a registry of "PW status refresh reduction 680 Configuration Message Sub-TLVs". These are 8-bit values. Type value 1 681 through 3 are defined in this document. Type values 3 through 64, and 682 128 through 254 are to be assigned by IANA using the "Expert Review" 683 policy defined in RFC5226. Type values 65 through 127, 0 and 255 are 684 to be allocated using the IETF review policy defined in [RFC5226]. 686 The Type Values are assigned as follows: 687 sub-TLV type Description 688 ------------ ----------- 689 0x01 MPLS-TP Tunnel ID. 690 0x02 PW ID configured List. 691 0x03 PW ID unconfigured List. 693 8.3. PW Status Refresh Reduction Notification Codes 695 IANA needs to set up a registry of "PW status refresh reduction 696 Notification Codes". These are 32-bit values. Type value 0 through 7 697 are defined in this document. Type values 8 through 65536, and 698 134,217,729 through 4,294,967,294 are to be assigned by IANA using 699 the "Expert Review" policy defined in RFC5226. Type values 65536 700 through 134,217,728, 0 and 4,294,967,295 are to be allocated using 701 the IETF review policy defined in [RFC5226]. 703 For each value assigned IANA should also track whether the value 704 constitutes an error as described in Section 5.1. When values are 705 assigned by IETF review, the setting of this column must be 706 documented in the RFC that requests the allocation. For Expert Review 707 assignments, the setting of this column must be made clear by the 708 requester at the time of assignment. 710 The Type Values are assigned as follows: 711 Code Error? Description 712 ---- ------ ----------- 713 0x00000000 No Null Notification. 714 0x00000001 No PW configuration mismatch. 715 0x00000002 Yes PW Configuration TLV conflict. 716 0x00000003 No Unknown TLV (U-bit=1) 717 0x00000004 Yes Unknown TLV (U-bit=0) 718 0x00000005 No Unknown Message Type 719 0x00000006 No PW configuration not supported. 720 0x00000007 Yes Unacknowledged control message. 722 8.4. PW status refresh reduction Message Flags 724 IANA needs to set up a registry of "PW status refresh reduction 725 Message Flags". This is a 8 bit registry with the first 2 most 726 significant bits allocated by this document as follows: 727 Bit Position Name Description 728 ------------ ---- ----------- 729 0 U Unknown flag bit. 730 1 C Configuration flag bit. 732 The remaining bits are to be allocated by "IETF Review" policy 733 defined in [RFC5226]. 735 8.5. G-ACH Registry Allocation 737 IANA maintains a registry called "MPLS Generalized Associated Channel 738 (G-ACh) Types". IANA needs, to allocate a new value as follows: 739 Value Description Reference 740 ----- ----------- --------- 741 0xZZ PW Status Refresh Reduction RFCXXXX 743 8.6. Guidance for Designated Experts 745 In all cases of review by the Designated Expert (DE) described here, 746 the DE is expected to ascertain the existence of suitable 747 documentation (a specification) as described in [RFC5226] and to 748 verify that the document is permanently and publicly available. The 749 DE is also expected to check the clarity of purpose and use of the 750 requested code points fits the general architecture and intended 751 purpose of the respective message or TLV. Lastly the DE should check 752 that any assignment does not duplicate or conflict with work that is 753 active or already published within the IETF. 755 9. References 757 9.1. Normative References 759 [RFC2119] Bradner. S, "Key words for use in RFCs to 760 Indicate Requirement Levels", RFC 2119, March, 1997. 762 [RFC8077] "Pseudowire Setup and Maintenance Using the Label 763 Distribution Protocol (LDP)", L. Martini, G. Heron, RFC8077, 764 february 2017. 766 [RFC6478] L. Martini, G. Swallow, G. Heron, M. Bocci "Pseudowire 767 Status for Static Pseudowires", RFC6478, May 2012 769 [RFC6370] M. Bocci, G. Swallow, E. Gray "MPLS-TP Identifiers", 770 RFC6370, September 2011 772 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 773 IANA Considerations section in RFCs", BCP 26, RFC 5226, May 2008 775 [RFC3031] E. Rosen, et al., RFC 3031, MPLS Architecture, January 776 2001. 778 9.2. Informative References 780 [RFC5586] M. Bocci, Ed., M. Vigoureux, Ed., S. Bryant, Ed., 781 "MPLS Generic Associated Channel", rfc5586, June 2009 783 10. Authors' Addresses 785 Luca Martini 786 Monoski LLC. 787 e-mail: lmartini@monoski.com 789 George Swallow 790 Cisco Systems, Inc. 791 300 Beaver Brook Road 792 Boxborough, Massachusetts 01719 793 United States 794 e-mail: swallow@cisco.com 795 Elisa Bellagamba 796 Ericsson EAB 797 Torshamnsgatan 48 798 16480, Stockholm 799 Sweden 800 e-mail: elisa.bellagamba@gmail.com 802 Copyright Notice 804 Copyright (c) 2017 IETF Trust and the persons identified as the 805 document authors. All rights reserved. 807 This document is subject to BCP 78 and the IETF Trust's Legal 808 Provisions Relating to IETF Documents 809 (http://trustee.ietf.org/license-info) in effect on the date of 810 publication of this document. Please review these documents 811 carefully, as they describe your rights and restrictions with respect 812 to this document. Code Components extracted from this document must 813 include Simplified BSD License text as described in Section 4.e of 814 the Trust Legal Provisions and are provided without warranty as 815 described in the Simplified BSD License. 817 Expiration Date: November 2017