PALS Working Group                                     Patrice Brissette
Internet Draft                                               Kamran Raza
Intended Status: Proposed Standard                          Sami Boutros
Expires: April 26, 2015                              Cisco Systems, Inc.

                                                          Nick Del Regno
                                                      Matthew Turlington
                                                                 Verizon

                                                           June 29, 2015


            Handling Incoming Label Request for PW FEC Types
              draft-brissette-pals-pw-fec-label-request-01

Abstract

   This document clarifies the behavior of an LSR PE upon receiving an
   LDP Label Request message for Pseudowire (PW) FEC types. Furthermore,
   this document specifies the procedures to be followed by the LSR PE
   in order to answer such requests for a given PW FEC type.

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/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html


Copyright and License Notice

   Copyright (c) 2014 IETF Trust and the persons identified as the
   document authors. All rights reserved.



Brissette, et. al        Expires April 26, 2015                 [Page 1]


Internet-Draft      draft-pwe3-pw-fec-label-request        June 20, 2015


   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.

Convention

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


Table of Contents

   1  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2. Requirements  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3. Procedures  . . . . . . . . . . . . . . . . . . . . . . . . . .  4
     3.1 PWid FEC (FEC128)  . . . . . . . . . . . . . . . . . . . . .  5
     3.2 Generalized PWid FEC (FEC129): . . . . . . . . . . . . . . .  5
     3.3 Common to PWid and Generalized PWid FEC  . . . . . . . . . .  5
     3.4 P2MP PW Upstream FEC (FEC130): . . . . . . . . . . . . . . .  5
     3.5 P2MP PW Downstream FEC (FEC132): . . . . . . . . . . . . . .  5
     3.5 PW Typed Wildcard FEC  . . . . . . . . . . . . . . . . . . .  5
   4 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . .  5
   5  Security Considerations . . . . . . . . . . . . . . . . . . . .  6
   6  IANA Considerations . . . . . . . . . . . . . . . . . . . . . .  6
   7  References  . . . . . . . . . . . . . . . . . . . . . . . . . .  7
     7.1  Normative References  . . . . . . . . . . . . . . . . . . .  7
     7.2  Informative References  . . . . . . . . . . . . . . . . . .  7
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . .  7
















Brissette, et. al        Expires April 26, 2015                 [Page 2]


Internet-Draft      draft-pwe3-pw-fec-label-request        June 20, 2015


1  Introduction

   Label Distribution Protocol (LDP) base specification [RFC5036]
   defines different LDP message types and their procedures for
   advertising label bindings. These procedures are generic and
   inherited by any FEC type that is advertised using these message
   types. For a given FEC type, any difference in behavior, compared to
   what is already specified in RFC 5036, needs to be spelled out
   clearly in the corresponding specification in which the FEC type is
   being introduced or extended.

   [RFC4447] specifies mechanisms to setup pseudowires (PWs) using LDP.
   [RFC4447] does not specify any behavior change with regards to label
   binding distribution for PW FEC types in response to a corresponding
   Label Request message from a peer LSR PE. This implies that [RFC4447]
   inherits the base procedures defined in [RFC5036] for Label Request
   and associated response for a PW FEC type. The lack of specification
   in the area of Label Request in [RFC4447] has led to some
   interoperability issues between vendors due to different
   interpretation. For example, there are some implementations which do
   not honor and do not respond to an incoming Label Request for a PW
   FEC type, resulting in functionality impact. Some of these problems
   are very critical for the deployment of PW technologies. The
   following is a non-exhaustive list of some of the problems and
   potential breakages that may result due to the lack of support of
   incoming Label Request for a PW FEC:

      - An LSR PE can not restart forwarding of packet with sequence
        number 1 as specified in section 4.1 of [RFC4385] with regards
        to Control Word Sequencing.

      - An LSR PE may not be able to perform a PW consistency check as
        defined in section 4.1 of [RFC6667], resulting in LSR PEs
        becoming out-of-sync.

      - Some implementations of LSR PE do not checkpoint PW label
        bindings learnt from peer(s) in their persistent memory and
        hence are not able to recover any peer state after their own
        restarts or switchovers. Such implementations typically require
        re-learning of peer's label bindings after their own failure
        and rely on Label Request mechanisms.

      - The combination of Downstream Unsolicited mode and Conservative
        Label retention (used due to memory limitations) can lead
        to a situation where an LSR PE releases the label learnt from a
        peer for a PW that it may need later. Label Request is used to
        solve this issue. For example, consider an LSR PE operating in
        Label Conservative mode receiving a label binding for a



Brissette, et. al        Expires April 26, 2015                 [Page 3]


Internet-Draft      draft-pwe3-pw-fec-label-request        June 20, 2015


        non-locally configured/known PW. This LSR PE ignores such a
        label binding and later tries to re-learn it via Label Request
        procedure once PW is locally configured. The authors will like
        to remind the readers about the following fact: [RFC4447] does
        not mandate to use Label Liberal mode. Therefore it is possible
        that some implementation used Label Conservative mode.


   This document clarifies the use of Label Request message and its
   procedures for PW FEC types and re-enforces the acceptable behavior
   to be implemented by an LSR PE.

2. Requirements

   This document recommends the following action to be implemented by an
   LSR PE that supports a PW FEC Type (P2P or P2MP type):

      - An LSR PE MUST respond to an incoming Label Request message
        for a PW FEC by sending its local binding for the PW via a
        Label Mapping message. If no such binding is available, the
        LSR PE SHOULD respond by sending a new status code "No PW"
        in a Notification message.

      - An LSR PE MUST respond to an incoming Label Request message
        for a Wildcard FEC [RFC5036] by sending its local bindings for
        all its PWs via Label Mapping messages. This is in addition to
        label bindings corresponding to any other LDP FEC types
        configured and available at the LSR.

      - An LSR PE MUST respond to an incoming Label Request message
        for a Typed Wildcard PW FEC [RFC6667] by sending its local
        bindings for all its PWs for the given FEC type via Label
        Mapping messages. For a given PW FEC type, this advertisement
        is to be scoped either for a specific PW type or for all
        PW types according to the received PW Typed Wildcard FEC.

3. Procedures

   This document re-enforces the Label Request generic procedures, as
   defined by RFC 5036, for PW FEC types, and hence strongly recommends
   that an LSR PE receiving the PW Label Request message should respond
   either by sending its label binding in Label Mapping message(s) or
   with a Notification message indicating why it cannot satisfy the
   request.

   An LSR PE should respond to a Label Request when corresponding PW FEC
   is resolved locally. The following sub sections define the meaning of
   a "resolution" for a given PW FEC type.



Brissette, et. al        Expires April 26, 2015                 [Page 4]


Internet-Draft      draft-pwe3-pw-fec-label-request        June 20, 2015


3.1 PWid FEC (FEC128)

   A PWid FEC is resolved when a local label binding has been allocated
   after local configuration application.

   [RFC6073] does not preclude setting up MS-PWs using FEC-128,
   therefore this procedure is also applicable to PEs acting as S-PEs.

3.2 Generalized PWid FEC (FEC129):

   A Generalized PWid FEC is resolved at an ST-PE when SAII is locally
   configured, TAII is learnt statically or dynamically via discovery
   mechanisms, and a local label binding has been allocated.

   This FEC is resolved at an TT-PE when SAII is locally configured,
   TAII is learnt statically or dynamically via discovery mechanisms,
   remote label binding is received, and a local label binding has been
   allocated.

   Whereas, this FEC is resolved at an S-PE when remote label binding is
   received for PW segment, TAII is learnt statically or dynamically via
   discovery mechanisms, and a local label binding has been allocated.

3.3 Common to PWid and Generalized PWid FEC

   A FEC is resolved at an S-PE when remote label binding is received
   for PW segment.

   In the case of Generalized PWid FEC, TAII is learnt statically or
   dynamically via discovery mechanisms, and a local label binding has
   been allocated. Whereas PWid FEC is resolved when a local binding has
   been allocated.

3.4 P2MP PW Upstream FEC (FEC130):

   Editor Note: Deferred for further study.

3.5 P2MP PW Downstream FEC (FEC132):

   Editor Note: Deferred for further study.

3.5 PW Typed Wildcard FEC

   The rules defined for individual PW FEC types apply equally when they
   are used under a PW Typed Wildcard FEC [RFC6667].

4 Acknowledgements




Brissette, et. al        Expires April 26, 2015                 [Page 5]


Internet-Draft      draft-pwe3-pw-fec-label-request        June 20, 2015


      The authors would like to thank for Alexander Vainshtein its
   reviews and comments of this document.

5  Security Considerations

   This document does not introduce any additional security constraints.

6  IANA Considerations

   This document requires the assignment of a new LDP Status Code to be
   used in a Notification message to notify a peer LSR if lookup fails
   at receiving LSR for a PW FEC received in a Label Request message.

   The value requested from the IANA managed LDP registry "LDP Status
   Code Name Space" is:




































Brissette, et. al        Expires April 26, 2015                 [Page 6]


Internet-Draft      draft-pwe3-pw-fec-label-request        June 20, 2015


    Range/Value   E   Description
    -----------  ---  -----------
    0x00000032    0   No PW

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.

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

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

   [RFC6667]  Raza, K., Boutros, S., and Pignataro, C., "LDP Typed
              Wildcard FEC for PWid and Generalized PWid FEC", RFC 6667,
              July 2012.

7.2  Informative References



Authors' Addresses


              Patrice Brissette
              Cisco Systems, Inc.
              2000 Innovation Drive
              Kanata, ON  K2K-3E8, Canada.
              EMail: pbrisset@cisco.com

              Kamran Raza
              Cisco Systems, Inc.
              2000 Innovation Drive
              Kanata, ON  K2K-3E8, Canada.
              EMail: skraza@cisco.com

              Sami Boutros
              Cisco Systems, Inc.
              3750 Cisco Way,
              San Jose, CA 95134, USA.
              E-mail: sboutros@cisco.com

              Nick Del Regno



Brissette, et. al        Expires April 26, 2015                 [Page 7]


Internet-Draft      draft-pwe3-pw-fec-label-request        June 20, 2015


              Verizon
              400 International Pkwy
              Richardson, TX  75081, USA.
              E-mail: nick.delregno@verizon.com

              Matthew Turlington
              Verizon
              400 International Pkwy
              Richardson, TX  75081, USA.
              E-mail: matt.turlington@verizon.com









































Brissette, et. al        Expires April 26, 2015                 [Page 8]