idnits 2.17.1 draft-ietf-pwe3-cbit-negotiation-03.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC4447]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. -- The draft header indicates that this document updates RFC4447, but the abstract doesn't seem to directly say this. It does mention RFC4447 though, so this could be OK. 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 (April 13, 2012) is 4389 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: 2 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Lizhong Jin (ed.), ZTE 3 Internet-Draft Raymond Key (ed.), Huawei 4 Updates: 4447 (if approved) Simon Delord, Alcatel-Lucent 5 Category: Standards Track Thomas Nadeau, Juniper 6 Expires: October 13, 2012 Vishwas Manral, Hewlett-Packard 7 Sami Boutros, Cisco 8 Reshad Rahman, Cisco 10 April 13, 2012 12 Pseudowire Control Word Negotiation Mechanism Update 13 draft-ietf-pwe3-cbit-negotiation-03 15 Abstract 17 This document describes the problem of control word negotiation 18 mechanism specified in [RFC4447]. Based on the problem analysis, a 19 message exchanging mechanism is introduced to solve this control word 20 negotiation issue. This document is to update [RFC4447] control word 21 negotiation mechanism. 23 Status of this Memo 25 This Internet-Draft is submitted to IETF in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as Internet- 31 Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/ietf/1id-abstracts.txt. 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html. 44 This Internet-Draft will expire on April 13, 2012. 46 Copyright Notice 48 Copyright (c) 2012 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents (http://trustee.ietf.org/ 53 license-info) in effect on the date of publication of this document. 54 Please review these documents carefully, as they describe your rights 55 and restrictions with respect to this document. Code Components 56 extracted from this document must include Simplified BSD License text 57 as described in Section 4.e of the Trust Legal Provisions and are 58 provided without warranty as described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . . 3 64 3. Control word re-negotiation by label request message . . . . . . 4 65 4. Backward Compatibility . . . . . . . . . . . . . . . . . . . . . 6 66 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 67 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 68 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 6 69 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 70 8.1. Normative References . . . . . . . . . . . . . . . . . . . . . 6 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 72 Appendix A. Updated C-bit Handling Procedures Diagram . . . . . . . 8 74 Conventions used in this document 76 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 77 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 78 document are to be interpreted as described in [RFC2119]. 80 1. Introduction 82 This document describes the problem of control word negotiation 83 mechanism specified in [RFC4447]. Based on the problem analysis, a 84 message exchanging mechanism is introduced to solve this negotiation 85 issue. The control word negotiation mechanism in this document is to 86 update [RFC4447] section 6.2 "PW Types for Which the Control Word is 87 NOT Mandatory". 89 2. Problem Statement 91 [RFC4447] section 6 describes the control word negotiation mechanism. 92 Each PW endpoint has the capability of being configurable with a 93 parameter that specifies whether the use of the control word is 94 PREFERRED or NOT PREFERRED. While in some case of control word 95 negotiation, PE will advertise C-bit=0 in label mapping message with 96 its locally configured control word PREFERRED. This kind of behavior 97 will cause some problem when peer PE changes its control word from 98 NOT PREFERRED to PREFERRED. 100 This following case will describe the negotiation problem in detail: 102 +-------+ +-------+ 103 | | PW | | 104 | PE1 |====================| PE2 | 105 | | | | 106 +-------+ +-------+ 107 Figure 1 109 1. Initially, the control word on PE1 is configured to PREFERRED, 110 and on PE2 to NOT PREFERRED. 112 2. The negotiation result for the control word for this PW is 113 "not supported", and PE1 send label mapping with C-bit=0 114 finally. 116 3. PE2 then changes its control word configuration to PREFERRED. 118 4. PE2 will then send label withdraw message to PE1. 120 5. According to the control word negotiation mechanism, the 121 received label mapping on PE2 from PE1 indicates C-bit=0, 122 therefore PE2 will still send label mapping with C-bit=0. 124 The negotiation result for the PW control word is still "not 125 supported", even though the control word configuration on both PE1 126 and PE2 is set to PREFERRED. 128 3. Control word re-negotiation by label request message 130 In order to solve this problem, the control word re-negotiation is 131 operated by adding label request message. The control word 132 negotiation mechanism can still follow the procedure described in 133 [RFC4447] section 6. 135 When Local PE changes its control word from NOT PREFERRED to 136 PREFERRED and only if it already received the remote label mapping 137 message with C-bit=0, additional procedure will be added as follow: 139 -i. Local PE MUST send a label withdraw message to remote PE if 140 it has previously sent a label mapping, and wait until 141 receiving a label release from the remote PE. And it MUST 142 also send a label release message to the remote PE. 144 -ii. Local PE MUST send a label request message to remote PE, 145 and wait until receiving a label mapping message containing 146 the remote PE configured control word setting. 148 -iii. After receiving remote PE label mapping with control word 149 setting, Local PE MUST follow procedures defined in 150 [RFC4447] section 6 when sending its label mapping message. 152 When the peer PE successfully processed the label withdraw and label 153 release, and removed the remote label binding, it MUST reset its 154 local control word with the configured one, and send label mapping as 155 a response of label request with locally configured control word 156 parameter. 158 Note: the FEC element in label request message should be the PE's 159 local FEC element. Only if FEC element in label request message 160 could bind together with peer PE's local FEC element, the peer PE 161 sends label mapping with its bound local FEC element and label as a 162 response. The label request message format and procedure is 163 described in [RFC5036]. 165 The multi-segment PW case for T-PE is same, and the request message 166 MUST be processed in ordered mode. When S-PE receives a label 167 request message from a remote peer, it MUST advertise the request 168 message to the other remote PE. This is necessary since S-PE does 169 not have full information of interface parameter field in the FEC 170 advertisement. When S-PE receives a label release message from 171 remote peer, it MUST send a corresponding label release to the other 172 remote PE. 174 As local T-PE will send label withdraw before sending label request 175 to remote peer, the S-PE MUST send the label withdraw upstream before 176 it advertises the label request. When S-PE receives the label 177 withdraw, it should process this message to send a label release as a 178 response and a label withdraw to upstream S-PE/T-PE, then process the 179 next LDP message, e.g. the label request message. 181 When Local PE changes its control word from PREFERRED to NOT 182 PREFERRED, Local PE would be able to re-negotiate the Control Word to 183 be NOT PREFERRED following the procedures defined in [RFC4447], and 184 no label request message to peer PE will be needed. In that case, 185 Local PE will always send new label mapping with C-bit reflecting the 186 local Control Word configuration. 188 The procedure of PE1 and PE2 for the case in figure 1 should be as 189 follows: 191 1. PE2 changes locally configured control word to PREFERRED. 193 2. PE2 will then send label withdraw and release messages to PE1. 195 3. PE1 will send label release in reply to label withdraw message 196 from PE2. After that and processing the label release from 197 PE2, it would reset local control word to the configured one. 199 4. Upon receipt of Label release message from PE1, PE2 would 200 reset local control word to the configured one, and MUST send 201 label request message to PE1. 203 5. PE1 MUST send label mapping message with C-bit=1 again to PE2 204 as response of label request. 206 6. PE2 receives the label mapping from PE1 and gets the remote 207 label binding information. PE2 could wait for PE1 label 208 binding before sending its label binding with C-bit set. 210 7. PE2 will send label mapping to PE1 with C-bit=1. 212 It is to be noted that the above assume that PE1 is configured to 213 support CW, however in step 5 if PE1 doesn't support CW, PE1 would 214 send the label mapping message with C-bit=0, this would result in PE2 215 in step 7 sending a label mapping with C-bit=0 as per [RFC4447] CW 216 negotiation procedure. 218 By sending label request message, PE2 will get the configured CW 219 parameter of peer PE1 in the received label mapping message. By 220 using the new CW parameter from label mapping message received from 221 peer PE1 and locally configured CW, PE2 should determine the PW CW 222 parameter according to [RFC4447] section 6. 224 The diagram in Appendix A in this document updates the control word 225 negotiation diagram in [RFC4447] Appendix A. 227 4. Backward Compatibility 229 Since control word re-negotiation is operated by adding label request 230 message, and still follows the procedure described in [RFC4447] 231 section 6, it is fully compatible with existing implementations. The 232 remote PE (PE1 in figure 1) which already implement label request 233 message could be compatible with the PE (PE2 in figure 1) following 234 the mechanism of this document. 236 5. Security Considerations 238 This document does not introduce any additional security constraints. 240 6. IANA Considerations 242 This document does not require IANA assignment. 244 7. Acknowledgements 246 The authors would like to thank Stewart Bryant, Andrew Malis, Nick 247 Del Regno, Luca Martini, Venkatesan Mahalingam, Alexander Vainshtein, 248 Adrian Farrel and Spike Curtis for their discussion and comments. 250 8. References 252 8.1. Normative References 254 [RFC2119] Bradner, S., Key words for use in RFCs to Indicate 255 Requirement Levels, BCP 14, RFC 2119, March 1997 257 [RFC4447] Martini, L., and al, Pseudowire Setup and Maintenance 258 Using the Label Distribution Protocol (LDP), RFC 4447, 259 April 2006 261 [RFC5036] Andersson, L., Minei, I., and Thomas B., 262 LDP Specification, RFC 5036, October 2007 264 Authors' Addresses 266 Lizhong Jin (editor) 267 ZTE Corporation 268 889, Bibo Road 269 Shanghai, 201203, China 270 Email: lizhong.jin@zte.com.cn 272 Raymond Key (editor) 273 Huawei 274 Email: raymond.key@ieee.org 276 Simon Delord 277 Alcatel-Lucent 278 Email: simon.delord@gmail.com 280 Thomas Nadeau 281 Juniper 282 Email: tnadeau@juniper.net 284 Vishwas Manral 285 Hewlett-Packard Co. 286 19111 Pruneridge Ave, Bldg 44, 287 Cupertino, CA 95014-0691 288 Email: vishwas.manral@hp.com 290 Sami Boutros 291 Cisco Systems, Inc. 292 3750 Cisco Way 293 San Jose, California 95134 294 USA 295 Email: sboutros@cisco.com 297 Reshad Rahman 298 Cisco Systems, Inc. 299 2000 Innovation Drive 300 Ottawa, Ontario K2K 3E8 301 CANADA 302 Email: rrahman@cisco.com 304 Appendix A. Updated C-bit Handling Procedures Diagram 306 ----------------------------------- 307 | | 308 | ------------------ 309 | Y | Received Label | N 310 | -------| Mapping Msg? |-------------- 311 | | ------------------ | 312 | -------------- | 313 | | | | 314 | ------- ------- | 315 | | C=0 | | C=1 | | 316 | ------- ------- | 317 | | | | 318 | | ---------------- | 319 | | | Control Word | N | 320 | | | Capable? |----------- | 321 | | ---------------- | | 322 | | Y | | | 323 | | | | | 324 | | ---------------- | | 325 | | | Control Word | N | | 326 | | | Preferred? |---- | | 327 | | ---------------- | | | 328 | | Y | | | | 329 | --------------------- | | | | 330 | | Control Word | | | | ---------------- 331 | | change Preferred | | | | | Control Word | 332 | | to not-Preferred? | | | | | Preferred? | 333 | --------------------- | | | ---------------- 334 | Y | | N | | | N | Y | 335 | | | | | | | | 336 | | Send Send Send Send Send Send 337 | | C=0 C=1 C=0 C=0 C=0 C=1 338 | | | | | | 339 | ------------------- ---------------------------------- 340 | | Send withdraw | | If receive the same as sent, | 341 | | if already sent | | PW setup is complete. If not: | 342 | | label mapping | ---------------------------------- 343 | ------------------- | | | | 344 | | ------------------- ----------- 345 | ------------------- | Receive | | Receive | 346 | | Send label | | C=1 | | C=0 | 347 | | release message | ------------------- ----------- 348 | ------------------- | | 349 | | Wait for the Send 350 | ------------------- next message Wrong C-bit 351 | | Send label | | 352 | | request message | Send Label 353 | ------------------- Mapping Message 354 | | 355 -------------