idnits 2.17.1 draft-jc-pwe3-static-config-check-01.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 (October 9, 2012) is 4215 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) == Outdated reference: A later version (-08) exists of draft-ietf-mpls-gach-adv-02 -- Obsolete informational reference (is this intentional?): RFC 4447 (Obsoleted by RFC 8077) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group L. Jin 3 Internet-Draft R. Chen 4 Intended status: Standards Track ZTE 5 Expires: April 12, 2013 S. Boutros 6 Cisco Systems 7 S. Kini 8 Ericsson 9 October 9, 2012 11 Static pseudowire configuration checking using Generic Associated 12 Channel (G-ACh) Advertisement Protocol 13 draft-jc-pwe3-static-config-check-01.txt 15 Abstract 17 This document defines a method to verify the configuration parameters 18 of static pseudowires (PW). Since a static PW can be independently 19 provisioned at each end of the PW there is a potential for a 20 configuration parameter mismatch and this can result in the PW not 21 being operational. This document introduces a configuration checking 22 protocol to simplify the provisioning and ease trouble shooting. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on April 12, 2013. 41 Copyright Notice 43 Copyright (c) 2012 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. GAP Extensions . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3.1. Static PW Application Message . . . . . . . . . . . . . . 4 62 3.2. PE Procedure for SS-PW . . . . . . . . . . . . . . . . . . 7 63 3.2.1. Sending PW application Element TLV . . . . . . . . . . 7 64 3.2.2. Receiving PW application Element TLV . . . . . . . . . 7 65 3.2.3. PW Configuration Verification Process . . . . . . . . 8 66 3.2.4. Remote Label Advertisement . . . . . . . . . . . . . . 8 67 3.3. PE Procedure for MS-PW . . . . . . . . . . . . . . . . . . 8 68 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 69 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 70 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 71 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 72 7.1. Normative references . . . . . . . . . . . . . . . . . . . 9 73 7.2. Informative References . . . . . . . . . . . . . . . . . . 10 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 76 1. Introduction 78 The manual configuration of static PW in MPLS and MPLS-TP network 79 requires configuring different PW parameters at the two terminating 80 PEs (Provider Edge). The PW parameters include PW-id, PW-Type, 81 Control word setting, interface and VCCV parameters settings. 83 The PW provisioned parameters MUST be aligned, so as to make the PW 84 operational. For dynamically signaled PW, the PW parameters are 85 negotiated using the signaling protocol, and only when the PW 86 parameters match at the terminating PE end points, the P2P (Point-to- 87 Point) PW is made operational and can be used to forward data 88 traffic. 90 In the absence of a signaling protocol, this draft defines a method 91 to do static PW configuration verification, so as to ease the 92 troubleshooting of end to end static PW provisioning in both MPLS and 93 MPLS-TP networks. The mechanism to exchange the PW configuration 94 parameters uses the Generic Associated Channel (G-ACh) Advertisement 95 Protocol (GAP) defined in [I-D.ietf-mpls-gach-adv]. In this draft, 96 the GAP functionality assumes that the PW's underlying PSN Tunnel 97 with GAP enabled is operational. 99 In the following sections we will describe the extension to the GAP 100 mechanism to do the PW configuration verification at the two 101 terminating PEs for P2P PW. The P2MP (Point-to-Multipoint) PW 102 configuration verification is for further study. 104 2. Terminology 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 108 document are to be interpreted as described in [RFC2119]. 110 This document uses some terms and acronyms as follows: 112 MPLS: Multi Protocol Label Switching. 114 OAM: MPLS Operations, Administration and Maintenance. 116 PE: Provide Edge Node. 118 T-PE: PW Terminating Provider Edge. 120 S-PE: PW Switching Provider Edge. 122 PW: PseudoWire. 124 TLV: Type, Length, and Value. 126 SS-PW: Single-segment PseudoWire 128 MS-PW: Multi-segment PseudoWire 130 3. GAP Extensions 132 3.1. Static PW Application Message 134 0 1 2 3 135 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 136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 137 | Static PW | Length | 138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 139 | Lifetime | Reserve | 140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 141 | | 142 + Static PW FEC Element TLV + 143 | | 144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 146 Figure 1 148 A new GAP application "Static PW" is defined in this draft. The 149 Static PW Application ID is to be assigned by IANA, and suggested 150 value is 0x0002. 152 Length: as per [I-D.ietf-mpls-gach-adv]. 154 Lifetime: as per [I-D.ietf-mpls-gach-adv], and the default value is 155 suggested to be 120 seconds. 157 Static PW FEC Element TLV for "Static PW" GAP application: 159 0 1 2 3 160 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 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 | Type | Reserved | Length | 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 | Source Global ID | 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 | Source Node ID | 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 | Source AC-ID | 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 | Destination Global ID | 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 | Destination Node ID | 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 174 | Destination AC-ID | 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 | PW Type |C| Reserved | 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 | TX Sequence Number | 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 | RX Sequence Number | 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 |0|0| Label Sub-TLV(0x0200) | Length | 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 | Incoming Label | 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 |0|0| Label Sub-TLV(0x0200) | Length | 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 | Outgoing Label | 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 | | 191 + Optional Interface Parameters Sub-TLV + 192 | | 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 Figure 2 197 The Static PW FEC Element TLV type is to be assigned by IANA. The 198 Length field specifies the length in octets of the Static PW FEC 199 Element and all Optional Interface Parameters Sub-TLVs. 201 The Static PW FEC element TLV value MUST include the following: 203 o The Global ID and Node ID fields MUST be set as per [RFC6370]. 205 o The AC-ID fields MUST be set as per [RFC5003]. 207 o PW-Type and control word bit (C) MUST be set as per [RFC4447]. 209 o TX Sequence Number: The transmitted message sequence number for 210 the associated Static PW FEC Element TLV. 212 o RX Sequence Number: The last received sequence number for the 213 associated Static PW FEC Element TLV. 215 o Two Generic Label TLVs as defined in [RFC5036] to encode static PW 216 incoming and outgoing labels in the order shown above. 218 o Optional Interface parameters Sub-TLV as defined in [RFC4447]. 220 The GAP Suppress message defined in [I-D.ietf-mpls-gach-adv] only 221 applies all TLVs for a given application. We define a new TLV, 222 static PW suppress TLV, to suppress static PW FEC element 223 transmission. Multiple static PW FEC element TLVs could be included 224 in this TLV. The format would be as follows: 226 0 1 2 3 227 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 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 |PW Suppress TLV| Reserved | Length | 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 | | 232 + Static PW FEC Element + 233 | | 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 ~ Multiple Static PW FEC Element TLVs ~ 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 Figure 3 240 The type of static PW suppress TLV is to be assigned by IANA. 242 The static PW suppress TLV could be sent by a receiving PE to request 243 a transmitting PE to stop sending GAP messages for the static PW FEC 244 Element TLVs in the static PW suppress TLV. 246 The static PW application MUST follow all procedures defined in 247 [I-D.ietf-mpls-gach-adv]. 249 3.2. PE Procedure for SS-PW 251 The mechanism defined in this draft provides a verification tool for 252 the P2P PW configuration information between two PEs. Upon the 253 provisioning or re-provisioning of a PW at an endpoint PE, GAP 254 messages carrying the static PW application TLV will be sent over the 255 PW's corresponding PSN tunnel which the endpoints PEs of the P2P PW 256 selects by local policy. 258 3.2.1. Sending PW application Element TLV 260 When a PW is configured at one endpoint PE, and the PW corresponding 261 PSN Tunnel is operational and UP, the PE MUST send its local PW 262 configuration information using the GAP over the PSN tunnel. 264 The transmitting PE MUST set the TX sequence number to a non-zero 265 value in Static PW FEC Element TLV, and MUST increment the TX 266 sequence number each time any local PW parameters change. 268 If the transmitting PE has previously received a GAP message with the 269 static PW FEC Element, the transmitting PE MUST verify local PW 270 parameters with the remote PE parameters as specified in section 271 4.2.3. The RX sequence number MUST be set to the previously received 272 TX sequence number, otherwise set to zero. 274 3.2.2. Receiving PW application Element TLV 276 The receiving PE MUST update the remote PW parameters associated with 277 a static PW FEC Element TLV, when the received TX sequence number in 278 the GAP message is different from the last one received. 280 If the receiving PE has been provisioned locally with the PW 281 parameters and has previously sent GAP message for the PW parameters, 282 it MUST check if the RX sequence number in the received GAP message 283 is equal to the TX sequence number it previously sent. 285 If the RX sequence number is equal, the receiving PE MUST send GAP 286 message with static PW suppress TLV as a response to remote PE, and 287 then verify local static PW parameters with the remote static PW FEC 288 parameters as specified in section 3.2.3. 290 Otherwise, if the RX sequence number is not equal, the receiving PE 291 MUST continue sending GAP message with static PW FEC element TLV, 292 with the RX sequence number set to the last received TX sequence 293 number from the remote PE. 295 If there is no local PW configuration associated with the static PW 296 FEC Element TLV, the receiving PE MUST retain the remote static PW 297 FEC Element information. 299 Whenever PE receives the GAP message with static PW suppress TLV, it 300 MUST stop sending GAP messages with the specified static PW FEC 301 element TLVs included in the static suppress TLV. 303 The GAP message of static PW application SHOULD be sent at least 304 three times within lifetime. 306 The mechanism described above applies as well for MS-PW. 308 3.2.3. PW Configuration Verification Process 310 Using source/destination Global-IDs, and source/destination node-ID 311 and AC-IDs, to identify a locally provisioned static PW, once found, 312 perform the following parameter verification checks: 314 1. Check the control word bit (C), and MUST do logical operation 315 "AND". Only when both ends have the use of control word enabled, 316 the result would be with control word presented on this PW. 318 2. Check PW type mismatch as defined in [RFC4447]. 320 3. Check and negotiate interface parameters as defined in [RFC4447]. 322 4. Check incoming and outgoing static PW labels. The local incoming 323 label should be equal to remote outgoing label, and the local 324 outgoing label should be equal to remote incoming label, 325 otherwise checking failed. 327 3.2.4. Remote Label Advertisement 329 The mechanism described in this draft MAY also be used to communicate 330 local static PW labels to allow for single side provisioning of 331 labels. As such, only incoming label will be included in the GAP 332 message and this label will be used by the remote PE as the output 333 label for the PW. 335 3.3. PE Procedure for MS-PW 337 The mechanism described above for verifying the SS-PW configuration 338 applies for MS-PW. As described in section 3.2, an S-PE MUST verify 339 the incoming and outgoing static PW labels, however no other PW 340 configuration parameters checking are needed at S-PE, since only the 341 labels will be configured at S-PE. 343 An S-PE MUST pass through static PW application TLVs carried in GAP 344 messages, from one PW segment's corresponding PSN tunnel to the other 345 PW segment's corresponding PSN tunnel. 347 4. Security Considerations 349 The mechanisms defined in this draft do not introduce any new threats 350 more than what's described in [I-D.ietf-mpls-gach-adv]. 352 5. IANA Considerations 354 IANA is requested to allocate a new "Static PW" Application ID in the 355 "G-Ach Advertisement Protocol Applications" registry. 357 Application ID Description Reference 358 -------------- ---------------------------- ------------ 359 (TBD) Static PW Application (this draft) 361 This document requests that IANA create a new registry, "GAP Static 362 PW Application: TLV objects", with fields and initial value as 363 follows: 365 Type Name Type ID Reference 366 ----------------------- ------- ------------ 367 Static PW FEC Element 0 (this draft) 368 Static PW suppress TLV 1 (this draft) 370 The range of the Type ID field is 0 - 255. 372 The allocation policy for this registry is IETF Review. 374 6. Acknowledgements 376 The authors would like to thank Stewart Bryant, Dan Frost for their 377 review and contributions. 379 7. References 381 7.1. Normative references 383 [I-D.ietf-mpls-gach-adv] 384 Frost, D., Bryant, S., and M. Bocci, "MPLS Generic 385 Associated Channel (G-ACh) Advertisement Protocol", 386 draft-ietf-mpls-gach-adv-02 (work in progress), May 2012. 388 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 389 Requirement Levels", BCP 14, RFC 2119, March 1997. 391 7.2. Informative References 393 [RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. 394 Heron, "Pseudowire Setup and Maintenance Using the Label 395 Distribution Protocol (LDP)", RFC 4447, April 2006. 397 [RFC5003] Metz, C., Martini, L., Balus, F., and J. Sugimoto, 398 "Attachment Individual Identifier (AII) Types for 399 Aggregation", RFC 5003, September 2007. 401 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 402 Specification", RFC 5036, October 2007. 404 [RFC6370] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport 405 Profile (MPLS-TP) Identifiers", RFC 6370, September 2011. 407 Authors' Addresses 409 Lizhong Jin 410 ZTE Corporation 411 889, Bibo Road 412 Shanghai, 201203, China 414 Email: lizhong.jin@zte.com.cn 416 Ran Chen 417 ZTE Corporation 418 No.19 East Huayuan Road 419 Beijing, 100191, China 421 Email: chen.ran@zte.com.cn 423 Sami Boutros 424 Cisco Systems, Inc. 425 3750 Cisco Way 426 San Jose, California 95134 427 USA 429 Email: sboutros@cisco.com 430 Sriganesh Kini 431 Ericsson 432 Ericsson 433 San Jose, CA 95134 435 Email: sriganesh.kini@ericsson.com