MPLS Working Group                                          Kamran Raza
Internet Draft                                             Sami Boutros
Updates: 5036, 4447 (if approved) 4447, 5918, 6388, 3212                      Luca Martini
Intended status: Standards Track                    Cisco Systems, Inc.
Expires: August 14, 2013 July 19, 2014
                                                        Nicolai Leymann
                                                       Deutsche Telekom

                                                      February 15, 2013

               Applicability of LDP

                                                       January 20, 2014

                Label Advertisement Mode

            draft-ietf-mpls-ldp-applicability-label-adv-01.txt

Abstract

   An Discipline for LDP speaker negotiates the FECs

            draft-ietf-mpls-ldp-applicability-label-adv-02.txt

Abstract

  The label advertisement mode with its LDP
   peer at the time advertising behavior of session establishment. Although different
   applications sharing the same an LDP session may need different modes
   of label distribution and advertisement, there is only one type of
   label advertisement mode that speaker for a given FEC is negotiated and used per LDP
   session. This document clarifies
  governed by the use FEC type and not necessarily by the applicability of LDP session's
  negotiated label advertisement mode, and categorizes LDP
   applications into two broad categories of negotiated mode-bound and
   mode-independent applications. The mode. This document updates RFC5036 and
   RFC4447 RFC 5036
  to remove any ambiguity make that fact clear, as well as updates RFC 3212, RFC 4447,
  RFC 5918, and conflict in RFC 6388 by specifying the area of using
   correct label advertisement mode
  for a given application. all currently defined FECs.

 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), 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 August 14, 2013. July 19, 2014.

Copyright Notice

   Copyright (c) 2013 2014 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
  2. Conventions used in this document                               3
  3. Label Advertisement Mode Applicability                          4
     3.1. Label Advertisement Mode Negotiation                       4
     3.2. Mode-based Categorization of LDP Applications              4
          3.2.1. Session mode-bound Applications                     5
          3.2.2. Session mode-independent Applications               5
     3.3. Unacceptable label advertisement mode                      6
  4. Clarification on Mode Applicability                             6
     4.1. Discipline                                   3
     2.1. Update to RFC-5036                                         7
     4.2. Update to RFC-4447                                         7
  5.                                          3
     2.2. Specification for LDP FECs                                  4
  3. Security Considerations                                         7
  6.                                          4
  4. IANA Considerations                                             7
  7.                                              4
  5. References                                                      7
     7.1.                                                       5
     5.1. Normative References                                       7
     7.2.                                        5
     5.2. Informative References                                     8
  8.                                      5
  6. Acknowledgments                                                 8                                                  5

1. Introduction

   The MPLS architecture [RFC3031] defines two modes of label
   advertisement for an LSR:

     1. Downstream-on-Demand

     2. Unsolicited Downstream

   The "Downstream-on-Demand" mode requires an LSR to explicitly
   request the label binding for FECs from its peer, whereas
   "Unsolicited Downstream" mode allows an LSR to distribute the label
   binding for FECs to LSR peers that have not explicitly requested
   them. The MPLS architecture also specifies that on any given label
   distribution adjacency, the upstream LSR and the downstream LSR must
   agree to use a single label advertisement mode.

  Label Distribution Protocol (LDP) [RFC5036] allows label
  advertisement mode negotiation at the time of session establishment
   (section 3.5.3 [RFC5036]). To comply with MPLS architecture, establishment.
  LDP specification also dictates that only single label advertisement
  mode is negotiated, agreed and used for a given LDP session between
  two LSRs.

   With

  The negotiated label advertisement mode defined in RFC 5036 and
  carried in the advent of new LDP applications, such as L2VPN [RFC4447],
   mLDP [RFC6388], ICCP [ICCP], there are situations when an Initialization message is only indicative. It
  indicates how the LDP speakers on a session will advertise labels for
  some FECs, but it is shared across more than one application not a rule that restricts the speakers to exchange label
   bindings behave
  in a specific way.  Furthermore, for different some FEC types the advertising
  behavior of FEC. Although different applications
   sharing the same LDP session may need a different speaker is governed by the FEC type of label
   advertisement mode negotiated, there is only one type of label
   advertisement mode that is negotiated and agreed at not by
  the time of
   establishment of LDP session. negotiated behavior.

  This document clarifies the use and the applicability of label
   advertisement mode of a session for each application using the
   session. It also categorizes LDP applications into two broad
   categories of mode-bound and mode-independent applications.

   The document also suggests an update to RFC-5036 and RFC-4447 to
   remove any ambiguity and conflict in the area of using correct label
   advertisement mode for a given LDP application.

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 RFC-2119 [RFC2119].

   The unqualified term "mode" used in document refers to "label
   advertisement mode".

   Please also note that LDP specification updates [RFC5036] uses the term
   "Downstream Unsolicited" to refer to "Unsolicited Downstream". The
   LDP specification also uses the terms "label distribution mode" make that fact clear, and
   "label advertisement mode" interchangeably. Like LDP specification
   document, this document also uses these terms interchangeably.

3. Label Advertisement Mode Applicability

3.1. Label Advertisement Mode Negotiation

   Label advertisement mode is negotiated between LSR peers at the time
   of session establishment. The label advertisement mode is specified
   in LDP Initialization message's "Common Session Parameter" TLV by
   setting A-bit (Label Advertisement Discipline bit) to 1 or 0 for
   Downstream-on-Demand or Downstream-Unsolicited modes respectively.
   The negotiation of the A-bit is specified in section 3.5.3 of
   [RFC5036] as follows:

     "If one LSR proposes Downstream Unsolicited updates
  [RFC3212], [RFC4447], [RFC5036], [RFC5918], and the other proposes
     Downstream on Demand, the rules for resolving this difference is:

        -  If the session is [RFC6388] to indicate
  for a label-controlled ATM link or a
         label- controlled Frame Relay link, then Downstream on Demand
         MUST be used.

       -  Otherwise, Downstream Unsolicited MUST be used."

   Once label advertisement mode each FEC type that has already been negotiated and agreed, both
   LSR peers must use the same mode for label binding exchange.

3.2. Mode-based Categorization of LDP Applications

   The earlier applications, defined and identified at the time of
   standardization of LDP base specification RFC-3036, using LDP to
   exchange their FEC bindings were:

     .  Dynamic Label Switching for IP Prefixes

     .  Label-controlled ATM/FR

   Since then, several new applications have emerged that use LDP to
   signal their FEC bindings and/or application data. These include:

     .  L2VPN P2P PW   ([RFC4447])
     .  L2VPN P2MP PW  ([P2MP-PW])

     .  mLDP           ([RFC6388])

     .  ICCP           ([ICCP])

   We divide whether the LDP applications into two broad categories from label
   advertisement mode usage point of view:

   1. Session mode-bound Applications

   2. Session mode-independent Applications

3.2.1. Session mode-bound Applications

  We define a "session mode-bound application" to be an application
  which uses the negotiated label advertisement mode. This means that
  the FEC-label
  binding exchange for such an LDP application MUST use
  the label advertisement mode negotiated advertisements for the LDP session.

   The early LDP applications "Dynamic Label Switching for IP Prefixes"
   and "Label-controlled ATM/FR" FEC are included into this category.

3.2.2. Session mode-independent Applications

   We define a "session mode-independent application" to be an
   application which does not care about the negotiated label
   advertisement mode. This means that the FEC-label binding, or any
   other application data, exchange for such an LDP application does
   not care about, nor tied to the "negotiated" label advertisement
   mode of the session; rather, the information exchange is driven constrained by the application need and procedures as described by its
   specification document. For example, [RFC6388] specifies procedures
   to advertise P2MP FEC label binding in an unsolicited manner,
   irrespective of the negotiated
  label advertisement mode of the
   session.

   The applications, PW (P2P and P2MP), MLDP, and ICCP, are included
   into this category of LDP applications.

3.2.2.1. Upstream Label Assignment

  As opposed to downstream assigned label advertisement defined by
  [RFC3031], [RFC6389] specification defines new mode of label
  advertisement where label advertisement and distribution occurs for
  upstream assigned labels.

  As stated earlier in this document, LDP base specification RFC-5036
  only allows specifying Downstream-Unsolicited or Downstream-on-Demand
  mode. This means that any LDP application that requires upstream
  assigned label advertisement also falls under not. Furthermore, this document specifies
  the category of Session
  mode-independent application.

3.3. Unacceptable label advertisement mode

  The procedures related to unacceptable label advertisement mode, as
  defined in RFC-5036 section 3.5.3, continue to apply for any "mode-
  bound" FEC/application. For a "mode-independent" FEC/application,
  mode negotiation does not apply and hence both LSRs MUST operate in
  the mode specified for the given application by the respective
  specification.

  If a session is jointly shared amongst mode-bound and mode-
  independent FEC/applications, session will not be established if the
  label advertisement mode is unacceptable (between the LSRs) for a
  given mode-bound FEC/application type. This is inline with RFC-5036
  section 3.5.3 specification used for unacceptable mode.

4. Clarification on Mode Applicability all currently defined
  LDP FECs.

2. Label Advertisement Discipline

   To remove any ambiguity and conflict amongst different
   specifications with regards to the use of LDP session's regarding label advertisement mode, we propose an update to
   discipline amongst different FEC types sharing a common LDP base specification
   RFC-5036 to clarify the applicability of session's negotiated mode.

   Furthermore, RFC-4447 session,
   this document specifies LDP extensions and procedures to
   exchange a label bindings for P2P PW FECs [RFC4447], and dictates the
   use of Downstream-Unsolicited mode advertisement disciplines for an LDP session related to
   L2VPN PW. FEC
   types.

   This mode dictation creates a direct conflict in
   situations when a PW LDP session is shared with an LDP application
   with Downstream-on-Demand mode (such as Label switching Application document introduces following types for IP prefixes). To remove such specifying a conflict, we also propose an
   update to label
   advertisement discipline for a section of RFC-4447.

4.1. FEC type:

     -  DU (Downstream Unsolicited)
     -  DoD (Downstream On Demand)
     -  As negotiated (DU or DoD)
     -  Upstream ([RFC6389])
     -  Not Applicable

2.1. Update to RFC-5036

   The section 3.5.3 of [RFC5036] is updated to add following two
   statements under the description of "A, Label Advertisement
   Discipline":

     -  The negotiated label advertisement discipline only applies to FEC
     label binding advertisement of "Address Prefix" FECs;

   -  Any new Each document specifying a new defining an LDP FEC MUST must state the applicability
        of the negotiated label advertisement discipline for label
        binding advertisements for that FEC.

4.2. Update If the negotiated label
        advertisement discipline does not apply to the FEC, the
        document must also explicitly state the discipline to RFC-4447

   The section 3 of [RFC4447] states:

     "LDP MUST be used in its downstream unsolicited mode."

   Since PW application falls under session mode-independent
   application category,
        for the FEC.

     - This document defines the above statement in [RFC4447] should be
   read to mean as follows:

   "LDP MUST exchange PW FEC label bindings in downstream unsolicited
   manner, independent of advertisement discipline for
        the following FEC types:

        +----------+----------+--------------------------------+
        | FEC Type | FEC Name | Label advertisement discipline |
        +----------+----------+--------------------------------+
        | 0x01     | Wildcard | Not applicable                 |
        | 0x02     | Prefix   | As negotiated (DU or DoD)      |
        +----------+----------+--------------------------------+

2.2. Specification for LDP FECs

   Following is the specification of label advertisement mode of
   the disciplines to
   be used for currently defined LDP session".

5. FEC types.

   +------+----------------+--------------------------------+------+
   | FEC  | FEC Name       | Label advertisement discipline |RFC   |
   | Type |                |                                |      |
   +------+----------------+--------------------------------+------+
   | 0x01 | Wildcard       | Not applicable                 | 5036 |
   | 0x02 | Prefix         | As negotiated (DU or DoD)      | 5036 |
   | 0x04 | CR-LSP         | DoD                            | 3212 |
   | 0x05 | Typed Wildcard | Not applicable                 | 5918 |
   | 0x06 | P2MP           | DU                             | 6388 |
   | 0x07 | MP2MP-up       | DU                             | 6388 |
   | 0x08 | MP2MP-down     | DU                             | 6388 |
   | 0x80 | PWid           | DU                             | 4447 |
   | 0x81 | Gen. PWid      | DU                             | 4447 |
   +------+----------------+--------------------------------+------+

  The above table also lists the RFC (in which given FEC type is
  defined), and hence this document updates all the above listed RFCs.

3. Security Considerations

   This document specification only clarifies the applicability of LDP
   session's label advertisement mode, and hence does not add any LDP
   security mechanics and considerations to those already defined in
   the LDP specification [RFC5036].

6.

4. IANA Considerations

  None.

7.

  This document mandates the specification of a label advertisement
  discipline for each defined FEC type, and hence extends IANA's
  "Forwarding Equivalence Class (FEC) Type Name Space" registry under
  IANA's "Label Distribution Protocol (LDP) Parameters" as follows:

       - Add a new column titled "Label advertisement discipline" with
          following possible values:
            o DU
            o DoD
            o As negotiated (DU or DoD)
            o Upstream
            o Not applicable

       - For the existing FEC types, populate this column with the
          values listed under section 2.2.

5. References

7.1.

5.1. Normative References

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

   [RFC3212] B. Jamoussi, et al., "Constraint-Based LSP Setup using
             LDP", RFC 3212, January 2002

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

   [RFC3031] E. Rosen, A. Viswanathan, and

   [RFC5918] R. Callon, "Multiprotocol
             Label Switching Architecture", RFC 3031, January 2001.

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", BCP 14, Asati, I. Minei, and B. Thomas, "Label Distribution
             Protocol Typed Wildcard FEC", RFC 2119, March 1997.

7.2. Informative References

   [P2MP-PW] S. Boutros, L. Martini, S. Sivabalan, G. Del Vecchio,
             Kamite, L. Jin, "Signaling Root-Initiated P2MP PWs using
             LDP", draft-ietf-pwe3-p2mp-pw-04.txt, Work in Progress,
             March 2012. 5918, August 2010.

   [RFC6388] I. Minei, I. Wijnand, Wijnands, K. Kompella, B., and B. Thomas, "LDP
             Extensions for P2MP and MP2MP LSPs", RFC 6388, November
             2011.

   [ICCP]    L. Martini, S. Salam, A. Sajassi, and S. Matsushima,
             "Inter-Chassis Communication Protocol for L2VPN PE
             Redundancy", draft-ietf-pwe3-iccp-09.txt, Work in
             Progress, July 2012.

   [RFC6389] R. Aggarwal, and J.L. JL. Le Roux, "MPLS Upstream Label
             Assignment for LDP", RFC 6389, November 2011.

8.

5.2. Informative References

   None.

6. Acknowledgments

   We acknowledge the authors of [RFC5036] and [RFC4447] since some of
   the text in this document is borrowed from their specification. We
   also acknowledge Eric Rosen and Rajiv Asati for their initial review
   and
   input. input on the document.

   This document was prepared using 2-Word-v2.0.template.dot.

Authors' Addresses

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

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

  Luca Martini
  Cisco Systems, Inc.
  9155 East Nichols Avenue, Suite 400,
  Englewood, CO 80112, USA.
  E-mail: lmartini@cisco.com

  Nicolai Leymann
  Deutsche Telekom AG,
  Winterfeldtstrasse 21,
  Berlin 10781, Germany.
  E-mail: N.Leymann@telekom.de