idnits 2.17.1 draft-ietf-pwe3-cbit-negotiation-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 (Using the creation date from RFC4447, updated by this document, for RFC5378 checks: 2002-08-12) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 3, 2012) is 4307 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 4447 (Obsoleted by RFC 8077) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group L. Jin(ed.) 3 Internet-Draft ZTE 4 Updates: 4447, 6073 (if approved) R. Key(ed.) 5 Intended status: Standards Track Huawei 6 Expires: January 4, 2013 S. Delord 7 Alcatel-Lucent 8 T. Nadeau 9 Juniper 10 S. Boutros 11 Cisco Systems, Inc. 12 July 3, 2012 14 Pseudowire Control Word Negotiation Mechanism Update 15 draft-ietf-pwe3-cbit-negotiation-05.txt 17 Abstract 19 The control word negotiation mechanism specified in RFC4447 has a 20 problem when a PE changes the preference for the use of the control 21 word from NOT PREFERRED to PREFERRED. This document updates RFC4447 22 and RFC6073 by adding the Label Request message to resolve this 23 control word negotiation issue for single-segment and multi-segment 24 pseudowires. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on January 4, 2013. 43 Copyright Notice 45 Copyright (c) 2012 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Conventions used in this document . . . . . . . . . . . . . . . 3 62 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . . 3 63 4. Control word renegotiation by Label Request message . . . . . . 4 64 4.1. Control word renegotiation for multi-segment PW . . . . . . 5 65 4.2. Control word re-negotiation use case . . . . . . . . . . . 6 66 5. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 7 67 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 68 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 69 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 70 9. Contributing Authors . . . . . . . . . . . . . . . . . . . . . 7 71 10. Normative references . . . . . . . . . . . . . . . . . . . . . 8 72 Appendix A. Updated C-bit Handling Procedures Diagram . . . . . . 8 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 75 1. Introduction 77 The control word negotiation mechanism specified in [RFC4447] section 78 6.2 encounters a problem when a PE (Provider Edge) changes the 79 preference for the use of the control word from NOT PREFERRED to 80 PREFERRED. [RFC4447] specifies that if both endpoints prefer the use 81 of the control word, then the pseudowire control word should be used. 82 However, in the case whereby a PE changes its preference from NOT 83 PREFERRED to PREFERRED and both ends of the PW (pseudowire) PE have 84 the use of control word set as PREFERRED, an incorrect negotiated 85 result of the control word as "not used" occurs. This document 86 updates the control word negotiation mechanism in [RFC4447] by adding 87 Label Request message to resolve this negotiation issue for single- 88 segment PW. Multi-segment PW in [RFC6073] inherits the control word 89 negotiation mechanism in [RFC4447], and this document updates 90 [RFC6073] by adding the processing of Label Request message on S-PE. 91 When PE changes the preference for the use of control word from 92 PREFERRED to NOT PREFERRED, it should follow [RFC4447], and there is 93 no problem. 95 2. Conventions used in this document 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 99 document are to be interpreted as described in [RFC2119]. 101 3. Problem Statement 103 [RFC4447] section 6 describes the control word negotiation mechanism. 104 Each PW endpoint has a configurable parameter that specifies whether 105 the use of the control word is PREFERRED or NOT PREFERRED. During 106 control word negotiation whereby one PE advertises a C bit set 0 in 107 the label mapping message with its locally configured use of control 108 word as PREFERRED and a corresponding peer PE changes its use of 109 control word from NOT PREFERRED to PREFERRED causes an incorrect 110 negotiated control word result of "not used". 112 The following case will describe the negotiation problem in detail: 114 +-------+ +-------+ 115 | | PW | | 116 | PE1 |====================| PE2 | 117 | | | | 118 +-------+ +-------+ 120 Figure 1 122 1. Initially, the use of control word on PE1 is configured as 123 PREFERRED, and on PE2 as NOT PREFERRED. 125 2. The negotiation result for the control word of this PW is not 126 used, and ultimately PE1 sends the Label Mapping message with C 127 bit set to 0 according to [RFC4447] section 6.2. 129 3. PE2 then changes its use of control word configuration from NOT 130 PREFERRED to PREFERRED, by deleting PW configuration with NOT 131 PREFERRED use of control word, and configuring the PW again with 132 PREFERRED use of control word. 134 4. PE2 will then send the Label Withdraw message to PE1, and 135 correspondingly will receive the Label Release message from PE1. 137 5. According to the control word negotiation mechanism, the 138 previously received Label Mapping message on PE2 from PE1 carries 139 the C bit set to 0, therefore PE2 will still send the Label 140 Mapping message with C bit set to 0. 142 The negotiation result for the control word is still not used, even 143 though the use of control word configuration on both PE1 and PE2 are 144 PREFERRED. 146 4. Control word renegotiation by Label Request message 148 The control word negotiation mechanism in [RFC4447] section 6 is 149 updated to add the Label Request message described in this section. 151 The renegotiation process begins when the local PE has received the 152 remote Label Mapping message with the C bit set to 0 and at the point 153 a change occurs of its use of control word from NOT PREFERRED to 154 PREFERRED. The following additional procedure will be carried out: 156 i. The local PE MUST send a Label Release message to remote PE. 157 If local PE has previously sent a Label Mapping message, it MUST 158 send a Label Withdraw message to remote PE, and wait until it has 159 received a Label Release message from the remote PE. Note: the 160 above Label Release message and Label Withdraw message sending 161 does not require specific sequence. 163 ii. The local PE MUST send a Label Request message to peer PE, 164 and then MUST wait until it receives a Label Mapping message 165 containing the peer's current configured preference for use of 166 control word. 168 iii. After receiving the remote peer PE Label Mapping message 169 with C bit, local PE MUST follow the procedures defined in 170 [RFC4447] section 6 when sending its Label Mapping message. 172 The remote PE will follow [RFC4447], and once the remote PE has 173 successfully processed the Label Withdraw message and Label Release 174 message, it will reset its use of control word with the locally 175 configured preference. Then the remote PE will send Label Mapping 176 message with locally configured preference for use of control word as 177 a response of Label Request message as specified in [RFC5036]. 179 Note: for the local PE, before processing new configuration changing 180 request, the above message exchanging process should be finished. 181 The FEC (Forwarding Equivalence Class) element in the Label Request 182 message should be the PE's local PW FEC element. As a response of 183 the Label Request message, the peer PE should send Label Mapping 184 message with its own local PW FEC element. The Label Request message 185 format and procedure is described in [RFC5036]. 187 4.1. Control word renegotiation for multi-segment PW 189 The multi-segment PW case for a T-PE (Terminating Provider Edge) 190 operates similarly as the PE in single-segment PW described in the 191 above section. An initial passive role is defined in [RFC6073] for 192 S-PE (Switching Provider Edge) for the processing of Label Mapping 193 message. [RFC6073] is updated by applying this passive role to the 194 processing of Label Request message. When an S-PE receives a Label 195 Request message from one of its adjacent PEs (may be S-PE or another 196 T-PE), it MUST send a matching Label Request message to other 197 adjacent PE (again, it may be an S-PE or a T-PE). This is necessary 198 since an S-PE does not have complete information of the interface 199 parameter field in the FEC advertisement. When the S-PE receives a 200 Label Release message from remote PE, it MUST send a corresponding 201 Label Release message to the other remote PE when it holds a label 202 for the PW from the remote PE. 204 Note: because the local T-PE will send Label Withdraw message before 205 sending Label Request message to the remote peer, the S-PE MUST 206 process the Label Withdraw message before the Label Request message. 207 When the S-PE receives the Label Withdraw message, it should process 208 this message to send a Label Release message as a response and a 209 Label Withdraw message to upstream S-PE/T-PE. The S-PE will then 210 process the next LDP message, e.g. the Label Request message. 212 When the local PE changes the use of control word from PREFERRED to 213 NOT PREFERRED, the local PE would then renegotiate the PW control 214 word to be not used by deleting the PW configuration with PREFERRED 215 use of control word, and configuring the PW again with NOT PREFERRED 216 use of control word. All of these procedures have been defined in 217 [RFC4447] section 5.4.1. 219 The diagram in Appendix A in this document updates the control word 220 negotiation diagram in [RFC4447] Appendix A. 222 4.2. Control word re-negotiation use case 224 The procedure of PE1 and PE2 for the use case in figure 1 will become 225 as follows: 227 1. PE2 changes locally configured preference for use of control word 228 to PREFERRED. 230 2. PE2 will then send the Release messages to PE1. PE2 will also 231 send the Label Withdraw message, and wait until it has received 232 the Label Release message from PE1. 234 3. PE1 will send the Label Release message in response to the Label 235 Withdraw message from PE2. After processing the Label Release 236 from PE2, PE1 will then reset the use of control word to the 237 locally configured preference as PREFERRED. 239 4. Upon receipt of the Label Release message from PE1, PE2 will send 240 the Label Request message to PE1, and proceed to wait until a 241 Label Mapping message is received. 243 5. PE1 will send a Label Mapping message with C bit set to 1 again 244 to PE2 as response of the Label Request message. 246 6. PE2 receives the Label Mapping message from PE1 and gets the 247 remote label binding information. PE2 will wait for the PE1 248 Label Mapping message before sending its Label Mapping message 249 with C bit set. 251 7. PE2 will send the Label Mapping to PE1 with C bit set to 1, and 252 follow procedures defined in [RFC4447] section 6. 254 While it is assumed that PE1 is configured to prefer the use of the 255 control word, in step 5 if PE1 doesn't prefer or support the control 256 word, PE1 would then send the Label Mapping message with C bit set to 257 0. As a result, PE2 in step 7 would send a Label Mapping message 258 with C bit set 0 as per [RFC4447] section 6. 260 By sending a Label Request message, PE2 will get the locally 261 configured preference for use of control word of peer PE1 in the 262 received Label Mapping message. By using the new C bit from the 263 Label Mapping message received from peer PE1 and the locally 264 configured preference for use of control word, PE2 should determine 265 the use of PW control word according to [RFC4447] section 6. 267 5. Backward Compatibility 269 Since control word negotiation mechanism is updated by adding Label 270 Request message, and still follows the basic procedure described in 271 [RFC4447] section 6, this document is fully compatible with existing 272 implementations. For single-segment pseudowire, the remote PE (PE1 273 in figure 1) which already implements [RFC4447] and Label Request 274 message as defined in [RFC5036] could be compatible with the PE (PE2 275 in figure 1) following the mechanism of this document. For the 276 multi-segment pseudowire, the T-PE is same as PE in single-segment 277 pseudowire; the S-PE should be upgraded with the mechanism defined in 278 this document. 280 6. Security Considerations 282 The security considerations specified in [RFC4447] and [RFC6073] also 283 apply to this document, and this document does not introduce any 284 additional security constraints. 286 7. IANA Considerations 288 This document does not require IANA assignment. 290 8. Acknowledgements 292 The authors would like to thank Stewart Bryant, Andrew Malis, Nick 293 Del Regno, Luca Martini, Venkatesan Mahalingam, Alexander Vainshtein, 294 Adrian Farrel and Spike Curtis for their discussion and comments. 296 9. Contributing Authors 298 Vishwas Manral 299 Hewlett-Packard Co. 301 19111 Pruneridge Ave, Bldg 44, 302 Cupertino, CA 95014-0691 303 Email: vishwas.manral@hp.com 305 Reshad Rahman 306 Cisco Systems, Inc. 307 2000 Innovation Drive Ottawa, 308 Ontario K2K 3E8 309 CANADA 310 Email: rrahman@cisco.com 312 10. Normative references 314 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 315 Requirement Levels", BCP 14, RFC 2119, March 1997. 317 [RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. 318 Heron, "Pseudowire Setup and Maintenance Using the Label 319 Distribution Protocol (LDP)", RFC 4447, April 2006. 321 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 322 Specification", RFC 5036, October 2007. 324 [RFC6073] Martini, L., Metz, C., Nadeau, T., Bocci, M., and M. 325 Aissaoui, "Segmented Pseudowire", RFC 6073, January 2011. 327 Appendix A. Updated C-bit Handling Procedures Diagram 329 ----------------------------------- 330 | | 331 | ------------------ 332 | Y | Received Label | N 333 | -------| Mapping Msg? |-------------- 334 | | ------------------ | 335 | -------------- | 336 | | | | 337 | ------- ------- | 338 | | C=0 | | C=1 | | 339 | ------- ------- | 340 | | | | 341 | | ---------------- | 342 | | | Control Word | N | 343 | | | Capable? |----------- | 344 | | ---------------- | | 345 | | Y | | | 346 | | ---------------- | | 347 | | | Control Word | N | | 348 | | | Preferred? |---- | | 349 | | ---------------- | | | 350 | | Y | | | | 351 | --------------------- | | | | 352 | |Control Word change| | | | ---------------- 353 | |from: NOT PREFERRED| | | | | Control Word | 354 | | to PREFERRED? | | | | | Preferred? | 355 | --------------------- | | | ---------------- 356 | Y | | N | | | N | Y | 357 | | Delete, and | | | | | 358 | | configure Send Send Send Send Send 359 | | new PW again C=1 C=0 C=0 C=0 C=1 360 | | | | | | 361 | ---------------------------- ---------------------------------- 362 | |Send Label Release Msg, | | If receive the same as sent, | 363 | |send Label Withdraw Msg if| | PW setup is complete. If not: | 364 | |has sent Label Mapping Msg| ---------------------------------- 365 | ---------------------------- | | | | 366 | | ------------------- ----------- 367 | ------------------- | Receive | | Receive | 368 | | Receiving Label | | C=1 | | C=0 | 369 | | Release message | ------------------- ----------- 370 | ------------------- | | 371 | | Wait for the Send 372 | ------------------- next message Wrong C-bit 373 | | Send Label | | 374 | | Request message | Send Label 375 | ------------------- Mapping Message 376 | | 377 ------------- 379 Authors' Addresses 381 Lizhong Jin (editor) 382 ZTE Corporation 383 889, Bibo Road 384 Shanghai, 201203, China 386 Email: lizhong.jin@zte.com.cn 388 Raymond Key (editor) 389 Huawei 391 Email: raymond.key@ieee.org 393 Simon Delord 394 Alcatel-Lucent 396 Email: simon.delord@gmail.com 398 Thomas Nadeau 399 Juniper 401 Email: tnadeau@juniper.net 403 Sami Boutros 404 Cisco Systems, Inc. 405 3750 Cisco Way 406 San Jose, California 95134, USA 408 Email: sboutros@cisco.com