idnits 2.17.1 draft-jin-pwe3-cbit-negotiation-04.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 (March 11, 2011) is 4787 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.), Telstra 4 Updates: 4447 (if approved) Simon Delord, Alcatel-Lucent 5 Category: Standards Track Thomas Nadeau, Huawei 6 Expires: September 11, 2011 Vishwas Manral, IPInfusion 7 Sami Boutros, Cisco 8 Reshad Rahman, Cisco 10 March 11, 2011 12 Pseudowire Control Word Negotiation Mechanism Update 13 draft-jin-pwe3-cbit-negotiation-04 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 September 11, 2011. 46 Copyright Notice 48 Copyright (c) 2011 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. 143 -ii. Local PE MUST send a label request message to remote PE, 144 and wait until receiving a label mapping message containing 145 the remote PE configured control word setting. 147 -iii. After receiving remote PE label mapping with control word 148 setting, Local PE MUST follow procedures defined in 149 [RFC4447] section 6 when sending its label mapping message. 151 When the peer PE successfully processed the label withdraw and 152 removed the remote label binding, it MUST send label mapping as a 153 response of label request with locally configured control word 154 parameter. 156 Note: the FEC element in label request message should be the PE's 157 local FEC element. Only if FEC element in label request message 158 could bind together with peer PE's local FEC element, the peer PE 159 sends label mapping with its bound local FEC element and label as a 160 response. The label request message format and procedure is 161 described in [RFC5036]. 163 The multi-segment PW case for T-PE is same, and the request message 164 MUST be processed in ordered mode. When S-PE receives a label 165 request message from a remote peer, it MUST advertise the request 166 message to the other remote PE. This is necessary since S-PE does 167 not have full information of interface parameter field in the FEC 168 advertisement. 170 As local T-PE will send label withdraw before sending label request 171 to remote peer, the S-PE MUST send the label withdraw upstream before 172 it advertises the label request. When S-PE receives the label 173 withdraw, it should process this message to send a label release as a 174 response and a label withdraw to upstream S-PE/T-PE, then process the 175 next LDP message, e.g. the label request message. 177 When Local PE changes its control word from PREFERRED to NOT 178 PREFERRED, Local PE would be able to re-negotiate the Control Word to 179 be NOT PREFERRED following the procedures defined in [RFC4447], and 180 no label request message to peer PE will be needed. In that case, 181 Local PE will always send new label mapping with C-bit reflecting the 182 local Control Word configuration. 184 The procedure of PE1 and PE2 for the case in figure 1 should be as 185 follows: 187 1. PE2 changes locally configured control word to PREFERRED. 189 2. PE2 will then send label withdraw message to PE1. 191 3. PE1 will send label release in reply to label withdraw message 192 from PE2. 194 4. Upon receipt of Label release message from PE1, PE2 MUST send 195 label request messages to PE1 although it already received the 196 label mapping with C-bit=0. 198 5. PE1 MUST send label mapping message with C-bit=1 again to PE2 199 (Note: PE1 MUST send label mapping with locally configured CW 200 parameter). 202 6. PE2 receives the label mapping from PE1 and updates the remote 203 label binding information. PE2 MUST wait for PE1 label 204 binding before sending its label binding with C-bit set, only 205 if it previously had a label binding with C-bit=0 from PE1. 207 7. PE2 will send label mapping to PE1 with C-bit=1. 209 It is to be noted that the above assume that PE1 is configured to 210 support CW, however in step 5 if PE1 doesn't support CW, PE1 would 211 send the label mapping message with C-bit=0, this would result in PE2 212 in step 7 sending a label mapping with C-bit=0 as per [RFC4447] CW 213 negotiation procedure. 215 By sending label request message, PE2 will get the configured CW 216 parameter of peer PE1 in the received label mapping message. By 217 using the new CW parameter from label mapping message received from 218 peer PE1 and locally configured CW, PE2 should determine the PW CW 219 parameter according to [RFC4447] section 6. 221 The diagram in Appendix A in this document updates the control word 222 negotiation diagram in [RFC4447] Appendix A. 224 4. Backward Compatibility 226 Since control word re-negotiation is operated by adding label request 227 message, and still follows the procedure described in [RFC4447] 228 section 6, it is fully compatible with existing implementations. The 229 remote PE (PE1 in figure 1) which already implement label request 230 message could be compatible with the PE (PE2 in figure 1) following 231 the mechanism of this document. 233 5. Security Considerations 235 This document does not introduce any additional security constraints. 237 6. IANA Considerations 239 This document does not require IANA assignment. 241 7. Acknowledgements 243 The authors would like to thank Stewart Bryant, Andrew Malis, Nick 244 Del Regno, Luca Martini, Venkatesan Mahalingam, Alexander Vainshtein, 245 Adrian Farrel and Spike Curtis for their discussion and comments. 247 8. References 249 8.1. Normative References 251 [RFC2119] Bradner, S., Key words for use in RFCs to Indicate 252 Requirement Levels, BCP 14, RFC 2119, March 1997 254 [RFC4447] Martini, L., and al, Pseudowire Setup and Maintenance 255 Using the Label Distribution Protocol (LDP), RFC 4447, 256 April 2006 258 [RFC5036] Andersson, L., Minei, I., and Thomas B., 259 LDP Specification, RFC 5036, October 2007 261 Authors' Addresses 263 Lizhong Jin (editor) 264 ZTE Corporation 265 889, Bibo Road 266 Shanghai, 201203, China 267 Email: lizhong.jin@zte.com.cn 269 Raymond Key (editor) 270 Telstra 271 242 Exhibition Street, Melbourne 272 VIC 3000, Australia 273 Email: raymond.key@ieee.org 275 Simon Delord 276 Alcatel-Lucent 277 Email: simon.delord@gmail.com 279 Thomas Nadeau 280 Huawei 281 Email: tnadeau@lucidvision.com 283 Vishwas Manral 284 IPInfusion 285 Email: vishwas@ipinfusion.com 287 Sami Boutros 288 Cisco Systems, Inc. 289 3750 Cisco Way 290 San Jose, California 95134 291 USA 292 Email: sboutros@cisco.com 294 Reshad Rahman 295 Cisco Systems, Inc. 296 2000 Innovation Drive 297 Ottawa, Ontario K2K 3E8 298 CANADA 299 Email: rrahman@cisco.com 301 Appendix A. Updated C-bit Handling Procedures Diagram 303 ----------------------------------- 304 | | 305 | ------------------ 306 | Y | Received Label | N 307 | -------| Mapping Msg? |-------------- 308 | | ------------------ | 309 | -------------- | 310 | | | | 311 | ------- ------- | 312 | | C=0 | | C=1 | | 313 | ------- ------- | 314 | | | | 315 | | ---------------- | 316 | | | Control Word | N | 317 | | | Capable? |----------- | 318 | | ---------------- | | 319 | | Y | | | 320 | | | | | 321 | | ---------------- | | 322 | | | Control Word | N | | 323 | | | Preferred? |---- | | 324 | | ---------------- | | | 325 | | Y | | | | 326 | --------------------- | | | | 327 | | Control Word | | | | ---------------- 328 | | change Preferred | | | | | Control Word | 329 | | to not-Preferred? | | | | | Preferred? | 330 | --------------------- | | | ---------------- 331 | Y | | N | | | N | Y | 332 | | | | | | | | 333 | | Send Send Send Send Send Send 334 | | C=0 C=1 C=0 C=0 C=0 C=1 335 | | | | | | 336 | ------------------- ---------------------------------- 337 | | Send withdraw | | If receive the same as sent, | 338 | | if already sent | | PW setup is complete. If not: | 339 | | label mapping, | ---------------------------------- 340 | | and wait until | | | | | 341 | | receiving label | ------------------- ----------- 342 | | release | | Receive | | Receive | 343 | ------------------- | C=1 | | C=0 | 344 | | ------------------- ----------- 345 | ------------------- | | 346 | | Send label | Wait for the Send 347 | | request message | next message Wrong C-Bit 348 | ------------------- | 349 | | Send Label 350 | | Mapping Message 351 -------------