Internet DRAFT - draft-ietf-pwe3-cbit-negotiation

draft-ietf-pwe3-cbit-negotiation






Network Working Group                                        L. Jin(ed.)
Internet-Draft                                                       ZTE
Updates: 4447, 6073 (if approved)                            R. Key(ed.)
Intended status: Standards Track                                  Huawei
Expires: January 4, 2013                                       S. Delord
                                                          Alcatel-Lucent
                                                               T. Nadeau
                                                                 Juniper
                                                              S. Boutros
                                                     Cisco Systems, Inc.
                                                            July 3, 2012


          Pseudowire Control Word Negotiation Mechanism Update
                draft-ietf-pwe3-cbit-negotiation-05.txt

Abstract

   The control word negotiation mechanism specified in RFC4447 has a
   problem when a PE changes the preference for the use of the control
   word from NOT PREFERRED to PREFERRED.  This document updates RFC4447
   and RFC6073 by adding the Label Request message to resolve this
   control word negotiation issue for single-segment and multi-segment
   pseudowires.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   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."

   This Internet-Draft will expire on January 4, 2013.

Copyright Notice

   Copyright (c) 2012 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



Jin, et al.              Expires January 4, 2013                [Page 1]

Internet-Draft     draft-ietf-pwe3-cbit-negotiation-05         July 2012


   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.  Conventions used in this document . . . . . . . . . . . . . . . 3
   3.  Problem Statement . . . . . . . . . . . . . . . . . . . . . . . 3
   4.  Control word renegotiation by Label Request message . . . . . . 4
     4.1.  Control word renegotiation for multi-segment PW . . . . . . 5
     4.2.  Control word re-negotiation use case  . . . . . . . . . . . 6
   5.  Backward Compatibility  . . . . . . . . . . . . . . . . . . . . 7
   6.  Security Considerations . . . . . . . . . . . . . . . . . . . . 7
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 7
   9.  Contributing Authors  . . . . . . . . . . . . . . . . . . . . . 7
   10. Normative references  . . . . . . . . . . . . . . . . . . . . . 8
   Appendix A.  Updated C-bit Handling Procedures Diagram  . . . . . . 8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 9

























Jin, et al.              Expires January 4, 2013                [Page 2]

Internet-Draft     draft-ietf-pwe3-cbit-negotiation-05         July 2012


1.  Introduction

   The control word negotiation mechanism specified in [RFC4447] section
   6.2 encounters a problem when a PE (Provider Edge) changes the
   preference for the use of the control word from NOT PREFERRED to
   PREFERRED. [RFC4447] specifies that if both endpoints prefer the use
   of the control word, then the pseudowire control word should be used.
   However, in the case whereby a PE changes its preference from NOT
   PREFERRED to PREFERRED and both ends of the PW (pseudowire) PE have
   the use of control word set as PREFERRED, an incorrect negotiated
   result of the control word as "not used" occurs. This document
   updates the control word negotiation mechanism in [RFC4447] by adding
   Label Request message to resolve this negotiation issue for single-
   segment PW. Multi-segment PW in [RFC6073] inherits the control word
   negotiation mechanism in [RFC4447], and this document updates
   [RFC6073] by adding the processing of Label Request message on S-PE.
   When PE changes the preference for the use of control word from
   PREFERRED to NOT PREFERRED, it should follow [RFC4447], and there is
   no problem.


2.  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].


3.  Problem Statement

   [RFC4447] section 6 describes the control word negotiation mechanism.
   Each PW endpoint has a configurable parameter that specifies whether
   the use of the control word is PREFERRED or NOT PREFERRED.  During
   control word negotiation whereby one PE advertises a C bit set 0 in
   the label mapping message with its locally configured use of control
   word as PREFERRED and a corresponding peer PE changes its use of
   control word from NOT PREFERRED to PREFERRED causes an incorrect
   negotiated control word result of "not used".

   The following case will describe the negotiation problem in detail:











Jin, et al.              Expires January 4, 2013                [Page 3]

Internet-Draft     draft-ietf-pwe3-cbit-negotiation-05         July 2012


                +-------+                    +-------+
                |       |         PW         |       |
                |  PE1  |====================|  PE2  |
                |       |                    |       |
                +-------+                    +-------+

                                 Figure 1

   1.  Initially, the use of control word on PE1 is configured as
       PREFERRED, and on PE2 as NOT PREFERRED.

   2.  The negotiation result for the control word of this PW is not
       used, and ultimately PE1 sends the Label Mapping message with C
       bit set to 0 according to [RFC4447] section 6.2.

   3.  PE2 then changes its use of control word configuration from NOT
       PREFERRED to PREFERRED, by deleting PW configuration with NOT
       PREFERRED use of control word, and configuring the PW again with
       PREFERRED use of control word.

   4.  PE2 will then send the Label Withdraw message to PE1, and
       correspondingly will receive the Label Release message from PE1.

   5.  According to the control word negotiation mechanism, the
       previously received Label Mapping message on PE2 from PE1 carries
       the C bit set to 0, therefore PE2 will still send the Label
       Mapping message with C bit set to 0.

   The negotiation result for the control word is still not used, even
   though the use of control word configuration on both PE1 and PE2 are
   PREFERRED.


4.  Control word renegotiation by Label Request message

   The control word negotiation mechanism in [RFC4447] section 6 is
   updated to add the Label Request message described in this section.

   The renegotiation process begins when the local PE has received the
   remote Label Mapping message with the C bit set to 0 and at the point
   a change occurs of its use of control word from NOT PREFERRED to
   PREFERRED.  The following additional procedure will be carried out:

      i.  The local PE MUST send a Label Release message to remote PE.
      If local PE has previously sent a Label Mapping message, it MUST
      send a Label Withdraw message to remote PE, and wait until it has
      received a Label Release message from the remote PE.  Note: the
      above Label Release message and Label Withdraw message sending



Jin, et al.              Expires January 4, 2013                [Page 4]

Internet-Draft     draft-ietf-pwe3-cbit-negotiation-05         July 2012


      does not require specific sequence.

      ii.  The local PE MUST send a Label Request message to peer PE,
      and then MUST wait until it receives a Label Mapping message
      containing the peer's current configured preference for use of
      control word.

      iii.  After receiving the remote peer PE Label Mapping message
      with C bit, local PE MUST follow the procedures defined in
      [RFC4447] section 6 when sending its Label Mapping message.

   The remote PE will follow [RFC4447], and once the remote PE has
   successfully processed the Label Withdraw message and Label Release
   message, it will reset its use of control word with the locally
   configured preference. Then the remote PE will send Label Mapping
   message with locally configured preference for use of control word as
   a response of Label Request message as specified in [RFC5036].

   Note: for the local PE, before processing new configuration changing
   request, the above message exchanging process should be finished.
   The FEC (Forwarding Equivalence Class) element in the Label Request
   message should be the PE's local PW FEC element.  As a response of
   the Label Request message, the peer PE should send Label Mapping
   message with its own local PW FEC element. The Label Request message
   format and procedure is described in [RFC5036].

4.1.  Control word renegotiation for multi-segment PW

   The multi-segment PW case for a T-PE (Terminating Provider Edge)
   operates similarly as the PE in single-segment PW described in the
   above section.  An initial passive role is defined in [RFC6073] for
   S-PE (Switching Provider Edge) for the processing of Label Mapping
   message.  [RFC6073] is updated by applying this passive role to the
   processing of Label Request message.  When an S-PE receives a Label
   Request message from one of its adjacent PEs (may be S-PE or another
   T-PE), it MUST send a matching Label Request message to other
   adjacent PE (again, it may be an S-PE or a T-PE).  This is necessary
   since an S-PE does not have complete information of the interface
   parameter field in the FEC advertisement.  When the S-PE receives a
   Label Release message from remote PE, it MUST send a corresponding
   Label Release message to the other remote PE when it holds a label
   for the PW from the remote PE.

   Note: because the local T-PE will send Label Withdraw message before
   sending Label Request message to the remote peer, the S-PE MUST
   process the Label Withdraw message before the Label Request message.
   When the S-PE receives the Label Withdraw message, it should process
   this message to send a Label Release message as a response and a



Jin, et al.              Expires January 4, 2013                [Page 5]

Internet-Draft     draft-ietf-pwe3-cbit-negotiation-05         July 2012


   Label Withdraw message to upstream S-PE/T-PE.  The S-PE will then
   process the next LDP message, e.g. the Label Request message.

   When the local PE changes the use of control word from PREFERRED to
   NOT PREFERRED, the local PE would then renegotiate the PW control
   word to be not used by deleting the PW configuration with PREFERRED
   use of control word, and configuring the PW again with NOT PREFERRED
   use of control word.  All of these procedures have been defined in
   [RFC4447] section 5.4.1.

   The diagram in Appendix A in this document updates the control word
   negotiation diagram in [RFC4447] Appendix A.

4.2.  Control word re-negotiation use case

   The procedure of PE1 and PE2 for the use case in figure 1 will become
   as follows:

   1.  PE2 changes locally configured preference for use of control word
       to PREFERRED.

   2.  PE2 will then send the Release messages to PE1.  PE2 will also
       send the Label Withdraw message, and wait until it has received
       the Label Release message from PE1.

   3.  PE1 will send the Label Release message in response to the Label
       Withdraw message from PE2.  After processing the Label Release
       from PE2, PE1 will then reset the use of control word to the
       locally configured preference as PREFERRED.

   4.  Upon receipt of the Label Release message from PE1, PE2 will send
       the Label Request message to PE1, and proceed to wait until a
       Label Mapping message is received.

   5.  PE1 will send a Label Mapping message with C bit set to 1 again
       to PE2 as response of the Label Request message.

   6.  PE2 receives the Label Mapping message from PE1 and gets the
       remote label binding information.  PE2 will wait for the PE1
       Label Mapping message before sending its Label Mapping message
       with C bit set.

   7.  PE2 will send the Label Mapping to PE1 with C bit set to 1, and
       follow procedures defined in [RFC4447] section 6.

   While it is assumed that PE1 is configured to prefer the use of the
   control word, in step 5 if PE1 doesn't prefer or support the control
   word, PE1 would then send the Label Mapping message with C bit set to



Jin, et al.              Expires January 4, 2013                [Page 6]

Internet-Draft     draft-ietf-pwe3-cbit-negotiation-05         July 2012


   0.  As a result, PE2 in step 7 would send a Label Mapping message
   with C bit set 0 as per [RFC4447] section 6.

   By sending a Label Request message, PE2 will get the locally
   configured preference for use of control word of peer PE1 in the
   received Label Mapping message. By using the new C bit from the
   Label Mapping message received from peer PE1 and the locally
   configured preference for use of control word, PE2 should determine
   the use of PW control word according to [RFC4447] section 6.


5.  Backward Compatibility

   Since control word negotiation mechanism is updated by adding Label
   Request message, and still follows the basic procedure described in
   [RFC4447] section 6, this document is fully compatible with existing
   implementations. For single-segment pseudowire, the remote PE (PE1
   in figure 1) which already implements [RFC4447] and Label Request
   message as defined in [RFC5036] could be compatible with the PE (PE2
   in figure 1) following the mechanism of this document. For the
   multi-segment pseudowire, the T-PE is same as PE in single-segment
   pseudowire; the S-PE should be upgraded with the mechanism defined in
   this document.


6.  Security Considerations

   The security considerations specified in [RFC4447] and [RFC6073] also
   apply to this document, and this document does not introduce any
   additional security constraints.


7.  IANA Considerations

   This document does not require IANA assignment.


8.  Acknowledgements

   The authors would like to thank Stewart Bryant, Andrew Malis, Nick
   Del Regno, Luca Martini, Venkatesan Mahalingam, Alexander Vainshtein,
   Adrian Farrel and Spike Curtis for their discussion and comments.


9.  Contributing Authors

   Vishwas Manral 
   Hewlett-Packard Co.



Jin, et al.              Expires January 4, 2013                [Page 7]

Internet-Draft     draft-ietf-pwe3-cbit-negotiation-05         July 2012


   19111 Pruneridge Ave, Bldg 44, 
   Cupertino, CA 95014-0691
   Email: vishwas.manral@hp.com

   Reshad Rahman 
   Cisco Systems, Inc.
   2000 Innovation Drive Ottawa, 
   Ontario K2K 3E8
   CANADA 
   Email: rrahman@cisco.com
   

10.  Normative references

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC4447]  Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G.
              Heron, "Pseudowire Setup and Maintenance Using the Label
              Distribution Protocol (LDP)", RFC 4447, April 2006.

   [RFC5036]  Andersson, L., Minei, I., and B. Thomas, "LDP
              Specification", RFC 5036, October 2007.

   [RFC6073]  Martini, L., Metz, C., Nadeau, T., Bocci, M., and M.
              Aissaoui, "Segmented Pseudowire", RFC 6073, January 2011.





			  
			  
			  
			  
			  
			  
			  
			  
			  
			  
			  
			  
			  
			  
			  
			  
			  
			  
			  
			  
Jin, et al.              Expires January 4, 2013                [Page 8]

Internet-Draft     draft-ietf-pwe3-cbit-negotiation-05         July 2012

Appendix A. Updated C-bit Handling Procedures Diagram

    -----------------------------------
    |                                 |
    |                        ------------------
    |                    Y   | Received Label |       N
    |                 -------|  Mapping Msg?  |--------------
    |                 |      ------------------             |
    |             --------------                            |
    |             |            |                            |
    |          -------      -------                         |
    |          | C=0 |      | C=1 |                         |
    |          -------      -------                         |
    |             |            |                            |
    |             |    ----------------                     |
    |             |    | Control Word |     N               |
    |             |    |    Capable?  |-----------          |
    |             |    ----------------          |          |
    |             |          Y |                 |          |
    |             |   ----------------           |          |
    |             |   | Control Word |  N        |          |
    |             |   |  Preferred?  |----       |          |
    |             |   ----------------   |       |          |
    |             |          Y |         |       |          |
    |  ---------------------   |         |       |          |
    |  |Control Word change|   |         |       |   ----------------
    |  |from: NOT PREFERRED|   |         |       |   | Control Word |
    |  | to PREFERRED?     |   |         |       |   |  Preferred?  |
    |  ---------------------   |         |       |   ----------------
    |     Y |     | N          |         |       |     N |     Y |
    |       | Delete, and      |         |       |       |       |
    |       | configure      Send      Send    Send    Send    Send
    |       | new PW again    C=1       C=0     C=0     C=0     C=1
    |       |                            |       |       |       |
    |  ----------------------------   ----------------------------------
    |  |Send Label Release Msg,   |   | If receive the same as sent,   |
    |  |send Label Withdraw Msg if|   | PW setup is complete. If not:  |
    |  |has sent Label Mapping Msg|   ----------------------------------
    |  ----------------------------          |       |       |       |
    |           |                       ------------------- -----------
    |  -------------------              |     Receive     | | Receive |
    |  | Receiving Label |              |       C=1       | |   C=0   |
    |  | Release message |              ------------------- -----------
    |  -------------------                       |               |
    |           |                          Wait for the        Send
    |  -------------------                 next message     Wrong C-bit
    |  | Send Label      |                                       |
    |  | Request message |                                  Send Label
    |  -------------------                               Mapping Message
    |           |
    -------------

Jin, et al.              Expires January 4, 2013                [Page 9]

Internet-Draft     draft-ietf-pwe3-cbit-negotiation-05         July 2012


Authors' Addresses

   Lizhong Jin (editor)
   ZTE Corporation
   889, Bibo Road
   Shanghai, 201203, China

   Email: lizhong.jin@zte.com.cn


   Raymond Key (editor)
   Huawei

   Email: raymond.key@ieee.org


   Simon Delord
   Alcatel-Lucent

   Email: simon.delord@gmail.com


   Thomas Nadeau
   Juniper

   Email: tnadeau@juniper.net


   Sami Boutros
   Cisco Systems, Inc.
   3750 Cisco Way
   San Jose, California 95134, USA

   Email: sboutros@cisco.com

















Jin, et al.              Expires January 4, 2013               [Page 10]