Network Working Group Lizhong Jin (ed.), ZTE Internet-Draft Raymond Key (ed.), Telstra Updates: 4447 Simon Delord Category: Standards Track Thomas Nadeau, Huawei Expires: April 22, 2011 Vishwas Manral, IPInfusion October 22, 2010 Pseudowire Control Word Negotiation Mechanism Analysis and Update draft-jin-pwe3-cbit-negotiation-01.txt Abstract This draft describes the problem of control word negotiation mechanism specified in [RFC4447]. Based on the problem analysis, possible solutions and their potential shortcomings are also discussed. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 22, 2011. Jin, et al. Expires April 2011 [Page 1] Internet-Draft draft-jin-pwe3-cbit-negotiation-00 October 2010 Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Problem statement . . . . . . . . . . . . . . . . . . . . . . . 3 3. Possible Solutions . . . . . . . . . . . . . . . . . . . . . . 3 3.1. Option 1: Control Word Re-Negotiation by Label Request . . . . 4 3.2. Option 2: Make CW Non-Configurable . . . . . . . . . . . . . . 4 3.3. Option 3: Manual Configuration Process for CW . . . . . . . . 5 3.4. Option 4: Make CW Capability Mandatory . . . . . . . . . . . . 5 3.5. Extra Considerations . . . . . . . . . . . . . . . . . . . . . 5 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 5 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 7.1. Normative References . . . . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Jin, et al. Expires April 2011 [Page 2] Internet-Draft draft-jin-pwe3-cbit-negotiation-00 October 2010 1. Introduction This draft describes the problem of control word negotiation mechanism specified in [RFC4447]. Based on the problem analysis, possible solutions and their potential shortcomings are also discussed. 2. Problem Statement [RFC4447] section 6 describes the control word negotiation mechanism. Each PW endpoint has the capability of being configurable with a parameter that specifies whether the use of the control word is PREFERRED or NOT PREFERRED. This negotiation mechanism will not work properly in the following case: +-------+ +-------+ | | PW | | | PE1 |====================| PE2 | | | | | +-------+ +-------+ Figure 1 1. Initially, the control word on PE1 is configured to PREFERRED, and on PE2 to NOT PREFERRED. 2. The negotiation result for the control word for this PW is "not supported", and PE1 send label mapping with CW=0 finally. 3. PE2 then changes its control word configuration to PREFERRED. 4. PE2 will then send label withdraw message to PE1. 5. According to the control word negotiation mechanism, the received label mapping on PE2 from PE1 indicates CW=0, therefore PE2 will still send label mapping with CW=0. 6. The negotiation result for the PW control word is still "not supported", even though the control word configuration on both PE1 and PE2 is set to PREFERRED. 3. Possible Solutions The solution for this problem should be applicable to both SS-PW and MS-PW. In this draft, possible solutions are discussed. Jin, et al. Expires April 2011 [Page 3] Internet-Draft draft-jin-pwe3-cbit-negotiation-00 October 2010 3.1. Option 1: Control Word Re-Negotiation by Label Request In this option, the control word re-negotiation is operated by adding label request message. The control word negotiation mechanism can still follow the procedure described in [RFC4447] section 6. The behavior of PE1 and PE2 should be as follows: 1. PE2 changes locally configured control word to PREFERRED. 2. PE2 will then send label withdraw message to PE1. 3. When PE doing the CW changing operation, PE2 needs to send label request to PE1 although it already received the label mapping. 4. PE1 will send label release in reply to label withdraw message from PE2. 5. PE1 will send label mapping message with Cbit=1 again to PE2 (Note: PE1 SHOULD send label mapping with locally configured CW parameter). 6. PE2 receives the label mapping from PE1 and updates the remote label binding information. 7. PE2 will send label mapping to PE1 with CW=1. It should be noted that the request message should be processed in ordered mode in MS-PW case. When S-PE receives a label request message from a remote, it should advertise the request message to the other remote PE. This is necessary since S-PE does not have full information of interface parameter field in the FEC advertisement. By sending label request message, PE2 will get the configured CW parameter from peer PE1 from receiving label mapping message. By using the new CW parameter from label mapping message sent by peer PE1 and locally configured CW, PE2 will determine the control word parameter according to [RFC4447] section 6. 3.2. Option 2: Make CW Non-Configurable The second solution is to change the control word to be not configurable, and default value is PREFERRED which can be degraded to NOT PREFERRED by negotiation automatically. The negotiation mechanism can still follow the procedure described in [RFC4447] section 6. There is explicit requirement from some service providers to allow control word to be configurable. This option will not fulfill their need. Jin, et al. Expires April 2011 [Page 4] Internet-Draft draft-jin-pwe3-cbit-negotiation-00 October 2010 3.3. Option 3: Manual Configuration Process for CW The third solution is to abandon the control word negotiation mechanism described in [RFC4447], and use a new simple mechanism. When receiving the CW bit from peer PE, local PE should simply compare the control word with local configuration (PREFERRED or not-PREFERRED). Only when the control word configured on both end-points of PW is PREFERRED, the PW will be UP with CW = 1, otherwise the PW will be UP with CW = 0 and the node with CW PREFERRED will automatically degrade to CW not-PREFERRED. It is important to note that this control word negotiation mechanism is not interoperable with the old mechanism defined in [RFC4447]. 3.4. Option 4: Make CW Capability Mandatory This option is to make CW capability mandatory. The PW will only be in operation UP when both PW end-points support control word capability. We should consider some side effect while making CW capability mandatory, which will be analyzed in future. 3.5. Extra Considerations The possible CW negotiation for multi-segment PW as well as potential complications with FEC129 will be covered in later version of this document. Backward compatibility issues will be further discussed in later version of this document. 4. Security Considerations This will be added in later version of this document. 5. IANA Considerations This will be no IANA request for this document. 6. Acknowledgements The authors would like to thank Stewart Bryant, Andrew Malis, Nick Del Regno, Sami Boutros, Luca Martini, Venkatesan Mahalingam, Alexander Vainshtein for their discussion and comments. Jin, et al. Expires April 2011 [Page 5] Internet-Draft draft-jin-pwe3-cbit-negotiation-00 October 2010 7. References 7.1. Normative References [RFC2119] Bradner, S., Key words for use in RFCs to Indicate Requirement Levels, BCP 14, RFC 2119, March 1997 [RFC4447] Martini, L., and al, Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP), April 2006 Authors' Addresses Lizhong Jin (editor) ZTE Corporation 889, Bibo Road Shanghai, 201203, China Email: lizhong.jin@zte.com.cn Raymond Key (editor) Telstra 242 Exhibition Street, Melbourne VIC 3000, Australia Email: raymond.key@team.telstra.com Simon Delord Email: simon.delord@gmail.com Thomas Nadeau Huawei Email: Thomas.Nadeau@huawei.com Vishwas Manral IPInfusion Email: vishwas@ipinfusion.com Jin, et al. Expires April 2011 [Page 6]