MPLS Working Group                                          Kamran Raza
Internet Draft                                             Sami Boutros
Intended status: Standards Track
Expires: August 14, 2012 February 17, 2013                                Cisco Systems

                                                       February 15,

                                                        August 18, 2012

                         LDP IP

               Disabling IPoMPLS and P2P PW Capability

                draft-ietf-mpls-ldp-ip-pw-capability-01.txt LDP Applications

                draft-ietf-mpls-ldp-ip-pw-capability-02.txt

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, 2012. February 17, 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
   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.

Abstract

   Currently, no LDP capability is exchanged for LDP applications like
   IP label switching and L2VPN/PW L2VPN P2P PW signaling. When an LDP session
   comes up, an LDP speaker may unnecessarily advertise its local state
   for such LDP applications even when the peer session may be
   established for some other applications like ICCP. This document
   proposes a solution by which an LDP speaker announces its disinterest or non-
   support for IP label switching or L2VPN/PW application, hence
   disabling
   in such non-negotiated application. This, in turn, disables the
   advertisement of corresponding application state exchange state, which would have
   otherwise be advertised by default, over the established LDP session.

Table of Contents

  1. Introduction ...................................................                                                     3
  2. Conventions used in this document ..............................                                4
  3. Non-negotiated LDP applications ................................                                  4
  4. Application Control Capabilities ............................... Controlling State Exchange for Non-negotiated LDP Applications   5
     4.1. IP Label Switching Application Control Capability TLV .........................                              5
     4.2. PW Signaling Capability TLV ............................... 6
  5. Capabilities Procedures .......................................                                          7
     5.1. Application Control Capabilities Capability in an Initialization msg . message 7
     5.2. Application Control capabilities capability in a Capability msg ...... message      8
  6. Operational Examples ...........................................                                             8
     6.1. Disabling IP/PW label applications IPoMPLS and P2P PW application on an ICCP session ..... 8
     6.2. Disabling IP Label Switching app. IPoMPLS application on a L2VPN/PW T-LDP session ...   9
     6.3. Disabling IP app. IPoMPLS appl. dynamically on an estab. IP/PW session ..     9
     6.4. Disabling unwanted state advert. by an IP dual-stack LSR   10
  7. Security Considerations .......................................                                         10
  8. IANA Considerations ...........................................                                             10
  9. Conclusions ................................................... 10                                                     11
  10. References ................................................... 10                                                     11
     10.1. Normative References .................................... 10                                      11
     10.2. Informative References ..................................                                    11
  11. Acknowledgments .............................................. 11                                                12

1. Introduction

  LDP Capabilities [RFC5561] introduced a mechanism to negotiate LDP
  capabilities for a given feature amongst peer LSRs. This The capability
  mechanism insures that no unnecessary state is exchanged between peer
  LSRs unless corresponding feature capability is successfully
  negotiated between peers.

  While new LDP features and applications, such as Typed Wildcard FEC
  [RFC5918], Inter-Chassis Communication Protocol [ICCP], and mLDP
  [RFC6388]
  [RFC6388], and P2MP PW [P2MP-PW] make use of LDP capabilities
  framework for their feature negotiation, the earlier LDP features and
  applications like IP label switching and L2VPN/PW L2VPN P2P PW signaling
  [RFC4447] [RFC4762] may cause unnecessary state exchange between LDP
  peers even when the given application is not enabled on one of the
  LDP speakers participating in a given session.

  For example, when bringing up and using an LDP peer session with a
  remote PE LSR for purely ICCP signaling purposes, the LDP speaker may
  unnecessarily advertise labels for IP (unicast) prefixes to this ICCP
  related LDP peer as per its default behavior.

  Another example of unnecessary state advertisement can be cited when
  LDP is used in (IP) an IP dual-stack environment. For instance, an LSR
  that is locally enabled for both IPv4 and IPv6 label switching may
  advertise address/label bindings for both IPv4 and IPv6 address
  families towards an IPv4-only LDP peer (i.e. a peer which is enabled
  for IPv4 LDP only and with which hello adjacencies and transport
  connection that is formed using interested in IPv4 only). only. In this
  case, the advertisement of IPv6 addresses and IPv4 prefix labels to
  the peer is unnecessary, as well as wasteful from LSR memory/CPU and
  network resource consumption point of view.

  To avoid this unnecessary state advertisement and exchange, currently
  customers are
  an operator is typically required to configure/define configure and define some sort
  of LDP
  state (e.g. label) filtering policies on the box, box for LDP state exchange, which
  introduces operational overhead and complexity.

  This document proposes an LDP Capabilities [RFC5561] based solution
  by which an LDP speaker may announce its disinterest (or non-
  support/disability) to its peer for IP Label Switching and/or
  L2VPN/PW L2VPN
  P2P PW Signaling application at the time of session establishment time. establishment.
  This helps avoiding unnecessary state exchange for such feature
  applications. The proposal also states the mechanics to disable or
  enable a
  previously disabled an application to be enabled later dynamically during the session lifetime. The
  document introduces two a new LDP Capabilities
  for IP label switching and L2VPN/PW applications capability to implement this proposal.

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 term "IP" in this document refers to "IP unicast", and refers to both IPv4 "IPv4 unicast" and IPv6
   "IPv6 unicast" address families.

   This document uses shorthand terms "IPoMPLS" to refer to IP Label
   switching application, and "P2P PW" to refer to L2VPN PW signaling
   for FEC 128 and FEC 129 P2P PWs.

3. Non-negotiated LDP applications

   For the applications that existed before LDP Capabilities [RFC5561]
   mechanics
   procedures were defined, an LDP speaker may advertise typically advertises relevant
   application state to its peers after session establishment without
   waiting for any capabilities exchange and negotiation.

   Amongst non-negotiated features and applications, the two most
   important non-negotiated These LDP
   applications are:

   o  IP [v4 and v6]  IPv4/IPv6 label switching ("IPoMPLS")

   o  L2VPN/PW  L2VPN P2P PW signaling ("P2P PW")

   To disable unnecessary state exchange for such LDP applications, two a
   new capabilities are capability is being introduced in this document. These This new
   capabilities control
   capability controls the advertisement of application state advertisement and allow
   enables an LDP speaker to notify its LDP peer at the session establishment time when its disinterest in one
   or more of these "Non-negotiated" LDP applications are not
   required/configured on at the sender side. time of
   session establishment. Upon receipt of such capability, if supported, the receiving
   LDP speaker speaker, if supporting the capability, MUST disable the
   advertisement of any state related to the application towards the
   sender. These capabilities can also be Moreover, the sender LSR SHOULD also disable the
   advertisement of corresponding application state towards the peer.
   This new capability can also be sent later in a Capability message to
   either disable these applications, or to enable previously disabled applications.
   applications dynamically.

4. Application Control Capabilities Controlling State Exchange for Non-negotiated LDP Applications

   To control advertisement of state related to non-negotiated LDP
   applications, namely IP Label switching IPoMPLS and L2VPN/PW P2P PW signaling, two a new capability
   TLVs are is defined as described in the following sub-
   sections. follows.

4.1. IP Label Switching Application Control Capability TLV

   The "IP Label Switching "Application Control Capability" is a new Capability Parameter
   TLV defined in accordance with the following format: section 3 of LDP Capabilities
   specification [RFC5561]. The format of this new TLV is as follows:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |1|0| IP Label Sw.
   |U|F| App Control Cap.  (IANA)  |           Length (4)              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |1|
   |S|  Reserved   | AF Bitmap                                               |        Reserved
   +-+-+-+-+-+-+-+-+
   |                                                               |
   ~               Application Control Element(s)                  ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Figure 1: Format of an "Application Control Capability" TLV

   The value of the U-bit for the IP capability parameter TLV MUST be set to 1 so that a
   receiver MUST silently ignore this TLV if unknown to it, and continue
   processing the rest of the message. Whereas, The value of F-bit MUST
   be set to 0. Once advertised, this capability cannot be withdrawn and
   hence the S-bit
   must always MUST be set to 1 both in Initialization message and
   Capability message.

   The capability data associated with this TLV is 1 octet long
   "Address Family Bitmap" and 2 octects "Reserved" field one or more
   Application Control Elements, where each element defines
   enabling/disabling of state advertisement for future
   use, and hence the TLV length MUST be set to 4. a given application.
   The Capability data "Address Family Bitmap" format of an Application Control Element is defined as follows:

    0                   1
    0 1 2 3 4 5 6 7
   +-+-+-+-+-+-+-+-+ 8 9 0 1 2 3 4 5
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   AF bitmap  App  |D|Rsvd1|    Rsvd2      |
   +-+-+-+-+-+-+-+-+
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

          Figure 2: Format of an "Application Control Element"

  Where:

       bit0:

  App: Defines the (non-negotiated) application type. The value of this
    field is defined as:
       0: IPv4 label Label switching application
       bit1:
       1: IPv6 label Label switching
       2: P2P PW FEC128 signaling
       3: P2P PW FEC129 signaling
    4-15: Reserved.

   D bit: Controls the advertisement of state for the application
       bit2-7: Unused. as
    follows
       1: Disable state advertisement
       0: Enable state advertisement

   Rsvd1, Rsvd2: Reserved for future use. MBZ on transmit and ignored on
    receipt.

   A bit

   The "Length" field of "Application Control Capability" TLV depends on
   the number of Application Control Elements present in the bitmap TLV. For
   example, if there are two elements present, then the Length field is
   set to 0 or 1 5 octets. A receiver of this capability TLV can deduce number
   of application control elements present in the TLV by using Length
   field.

   For now onward, this document uses term "element" to disable or enable
   respectively a corresponding IP application.

   The "Reserved" field is reserved for future use and MBZ on transmit
   and ignored on receipt. refer to an
   application control element.

   As described earlier, "IP Label Switching "Application Control Capability" Parameter TLV MAY be
   included by an LDP speaker in an Initialization message to signal to
   its peer LSR that state exchange for IPv4 and/or IPv6 one or more application(s) need
   to be disabled on a given peer session. This TLV can also be sent
   later in a Capability message to selectively enable or disable IPv4/v6 label switching application(s).

4.2. PW Signaling Capability TLV

   The "PW Signaling these
   applications. An "Application Control Capability" is a new Capability Parameter defined TLV MUST contain
   elements with distinct application types and the following format:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |1|0|  PW Signaling Cap. (IANA) |           Length (4)          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |1| Reserved    |E|  Unused     |            Reserved           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The value of the U-bit for TLV MUST NOT contain
   the PW same application type more than once.

   To control more than one application, a sender LSR can either send a
   single capability parameter TLV MUST be
   set to 1 so that in a receiver message with multiple elements present, or
   can send separate messages with capability TLV specifying one or more
   elements. A receiving LSR, however, MUST silently ignore this treat each incoming message
   with capability TLV if unknown as an incremental update to it, and continue processing the rest of the message. Once
   advertised, this existing control.

   To understand capability cannot be withdrawn updates from an example, let us consider 2
   LSR peers, R1 (sender) and hence R2 (receiver), both of which support all
   the S-bit
   MUST always be set non-negotiated applications listed earlier. By default, these LSR
   will advertise state for these applications to 1 their peer as soon as
   an LDP session is established. Now assume that R2 receives an
   Application Control capability in the Initialization message or Capability
   message. The capability data associated with this TLV is 3 octets
   long
   "IPv6 Label switching" and hence the TLV length MUST be set to 4.

   The capability data is defined as follows:

    0 1 2 3 4 5 6 7
   +-+-+-+-+-+-+-+-+
   |E| Unused      |
   +-+-+-+-+-+-+-+-+

   Where:

    E-bit: Enable bit. Used to control "P2P PW signaling application by
       setting it FEC129" applications disabled.
   This updates R2's outbound policy towards R1 to 0 and 1 advertise state
   related to disable only "IPv4 Label switching" and enable the application
       respectively.

    Unused: Unused bits. MBZ on transmit "P2P PW FEC 128"
   applications.  Now, R2 receives a capability update from R1 via a
   Capability message with "IPv6 Label switching" enabled and ignored on receipt.

   The "Reserved" field is reserved for future use "P2P PW
   FEC128" disabled. This updates R2's outbound policy towards R1 to
   advertise both IPv4 and MBZ on transmit IPv6 Label switching state, and ignored on receipt.

   As described earlier, disable both
   P2P PW Signaling FEC128 and FEC 129 signaling. Finally, R2 receives another
   update from R1 via Capability Parameter TLV MAY be
   included by an LDP speaker in an Initialization message that specifies to signal disable all 4
   non-negotiated applications, resulting R2 outbound policy towards R1
   to
   its peer LSR that block/disable state exchange for PW application need to be
   disabled on given peer session. This TLV can also be sent later in a
   Capability message to enable/disable the PW Signaling application. all these applications, and only advertise
   state for any other application, if present.

5. Capabilities Procedures

5.1. Application Control Capabilities in an Initialization message

   LDP Capabilities [RFC5561] dictate that

   The "Application Control" capability conveys the S-bit desire of a sending
   LSR to disable receipt of unwanted/unnecessary state from a peer.
   Hence, this capability
   parameter is unilateral and uni-directional in an Initialization message MUST be set to 1 nature,
   and SHOULD be
   ignored on receipt.

   An LDP speaker determines (e.g. via some local configuration or
   default policy) if they need to disable IP and/or L2VPN/PW
   applications with a peer LSR. If there receiving LSR is a need not required to disable, then the
   IP and/or PW application send a similar capability TLVs need to be included TLV
   in the an Initialization or Capability message with respective application bits set to 0 to
   indicate application disable, where towards the application bit refers sender. This
   unilateral behavior also conforms to a
   bit in "Address Family Bitmap" of the "IP Label Switching" Capability
   or E-bit procedures defined in the "PW Signaling" Capability.

   An
   Section 6 of LDP speaker that supports the "IP Label Switching" and/or "PW
   Signaling" Capabilities [RFC5561].

   After this capability MUST interpret those TLVs in is successfully negotiated (i.e. sent by a received
   Initialization message such that it disables the advertisement of
   sender and received/understood by the
   application receiver), then both
   participating LSRs MUST NOT exchange any state towards related to the sender LSR for IP (v4 and/or v6) and/or
   L2VPN/PW
   disabled applications until and unless these applications if their application control bits are set to 0.
   explicitly enabled again via a capability update.

   If a receiving LDP speaker does not understand the Application
   Control capability TLVs, TLV, then it MUST respond to the sender with
   "Unsupported TLV" Notification as described in LDP Capabilities
   [RFC5561]. Upon receipt of such Notification, the sender MAY still
   continue to block/disable its outbound state advertisement towards
   the peer for the requested disabled applications.

   Once this capability has been sent by sender LSR and received If a receiving LDP
   speaker does not understand or does not support an application
   specified in an application control element, it SHOULD silently
   ignore/skip such an element and
   understood by continue processing rest of the receiver LSR, then both these LSRs TLV.

5.1. Application Control Capability in an Initialization message

   LDP Capabilities [RFC5561] dictate that the S-bit of capability
   parameter in an Initialization message MUST NOT
   exchange any state related be set to the disabled applications until 1 and
   unless these applications are explicitly enabled again SHOULD be
   ignored on receipt.

   An LDP speaker determines (e.g. via some local configuration or
   default policy) if they need to disable IPoMPLS and/or P2P PW
   applications with a peer LSR. If there is a need to disable, then the
   same Capability
   "Application Control Capability" TLV sent needs to be included in a Capability the
   Initialization message with corresponding respective application control elements
   included with their D bit set to 1).

   "IP Label Switching" and "PW Signaling" 1.

   An LDP speaker that supports the "Application Control" capability TLVs are
   unilateral and uni-directional in nature -- i.e. a receiving LSR may
   not need to send a similar
   MUST interpret the capability TLV in an a received Initialization or
   Capability
   message towards such that it disables the sender. This unilateral behavior also
   conforms to advertisement of the procedures defined in application
   state towards the Section 6 of LDP
   Capabilities [RFC5561]. sender LSR for IPoMPLS and/or P2P PW applications
   if their application control element's D bit is set to 1.

5.2. Application Control capabilities capability in a Capability message

   If the LDP peer supports "Dynamic Announcement Capability" [RFC5561],
   then an LDP speaker can may send IP Label Switching and/or PW Signaling Application Control capability in a
   Capability message. message towards the peer. Once advertised, these
   capabilities cannot be withdrawn and hence the S-bit of the TLV MUST
   be set to 1 when sent in a Capability message.

   An LDP speaker may decide to send this TLV towards an LDP peer if any
   of its IP IPoMPLS and/or L2VPN/PW P2P PW signaling applications gets get disabled, or
   if previously disabled IP and/or L2VPN/PW application gets enabled again. In this case,
   LDP speaker constructs the TLVs TLV with appropriate application control bitmap
   elements and sends the corresponding capability
   TLVs TLV in a Capability
   message. Furthermore, the LDP speaker also
   withdraws withdraws/advertises
   application(s) related advertised state (such as label address/label bindings) from from/to
   its peer. peer according to the capability update.

   Upon receipt of those TLVs this TLV in a Capability message, the receiving LDP
   speaker reacts in the same manner as it reacts upon the receipt of
   those TLVs
   this TLV in an Initialization message. Additionally, the receiving
   LDP speaker withdraws the application(s) related advertised withdraws/advertises application state
   (such as label bindings) from from/to the
   sending LDP speaker. If the
   receiving LDP speaker does not understand or support either Dynamic
   Announcement capability or received Application Control capability
   TLV ("IP Label Switching" or "PW Signaling"), it MUST respond with
   "Unsupported Capability" notification peer according to the sender of the Capability
   message. capability update.

6. Operational Examples

6.1. Disabling IP/PW label IPoMPLS and P2P PW applications on an ICCP session

   Consider two PE routers, LSR1 and LSR2, which understand/support "IP
   Label Switching" and "PW Signaling"
   "Application Control" capability TLVs. These LSR TLV, and have an established LDP
   session due to ICCP application in order to exchange ICCP state
   related to dual-homed devices connected to these LSRs. Let us assume
   that LSR1 is provisioned not to exchange any
   label bindings related to IP (v4/v6) prefixes state for IPoMPLS
   (IPv4/IPv6) and P2P PW layer2 FEC (FEC128/129) application with LSR2.

   To indicate its "disability" for the IP/PW disinterest in these applications, the LSR1 will
   include both the "IP Label Switching" an "Application Control" capability TLV (with
   bit0-1 of "Address Family Bitmap" set 4 application
   control elements corresponding to 0) and "PW Signaling"
   capability TLV (with E-bit these 4 applications with D bit
   set to 0) 1 for each one) in the Initialization message. Upon receipt
   of those TLVs this TLV in Initialization message, the LSR2 will disable any IP/PW address/label binding state
   advertisement of IPv4/IPv6 bindings (addresses and labels), as well
   as P2P PW FEC128/129 signaling, towards LSR1 after session
   establishment.

   The LSR1 will also disable any IP/PW address/label binding similar state advertisement for these
   applications towards LSR2, LSR2 independently, irrespective of the fact
   whether or not LSR2 could disable the corresponding application
   state advertisement towards LSR1.

6.2. Disabling IP Label Switching IPoMPLS application on a L2VPN/PW T-LDP session

   Now, consider LSR1 and LSR2 have an established session due to
   L2VPN/PW T-LDP session for
   P2P PW application just to exchange PW (FEC128/129) label bindings for VPWS/VPLS services amongst them. FEC 128/129.
   Since in most typical deployments, there is no need to exchange IP
   (v4/v6) address/label bindings amongst the PE LSRs, let us assume
   that LSR1 is provisioned to disable IP (v4/v6) application IPoMPLS (IPv4/IPv6)application
   on given PW session towards LSR2.

   To indicate its disinterest in IP label switching, IPoMPLS application over PW T-LDP
   session, the LSR1 will
   include the "IP Label Switching" capability TLV in follow/apply the
   Initialization message with bit0-1 (IPv4, IPv6) in "Address Family
   Bitmap" set same procedures to zero. Upon receipt of this TLV disable
   IPv4 and IPv6 label switching as described in Initialization
   message, the previous section.
   Similarly, LSR2 will disable any IP address/label binding behave accordingly by disabling state
   advertisement towards LSR1.

   The LSR1 will also disable any IP address/label binding state
   towards LSR2, irrespective of the fact whether or not LSR2 could
   disable the corresponding IP for IPoMPLS application state advertisement towards LSR1.

6.3. Disabling IP IPoMPLS application dynamically on an established IP/PW
   session

   Assume that LSRs from previous sections were initially provisioned to
   exchange both IP IPoMPLS and P2P PW state over the session between them,
   and also support "Dynamic Announcement Capability" Announcement" Capability [RFC5561]. Now,
   assume that LSR1 is dynamically provisioned to disable IP label switching IPoMPLS
   (IPv4/IPv6) over T-LDP session with LSR2. In this case, LSR1 will
   first disable its future outbound application state towards LSR2, and
   also withdraw all its IP label previously advertised IPoMPLS state (labels and
   addresses) by sending a single Prefix FEC Typed Wildcard Label
   Withdraw message [RFC5918], and an Address Withdraw message
   respectively towards LSR2. LSR1 will also send Application Control
   capability TLV in a Capability message towards LSR2 with application
   control elements defined for IPv4 and IPv6 label switching with D bit
   set to 1. Upon receipt of this TLV, LSR2 will also disable IPoMPLS
   applications towards LSR1 and withdraw all previous IP "Prefix Typed
   Wildcard FEC" label/address
   state using the same mechanics as described in [RFC5918], earlier for LSR1. This
   dynamic disability of IPoMPLS application will not impact L2VPN P2P
   PW application on the given session, and Address
   Withdraw message both LSRs should continue to
   exchange PW Signaling application related state.

6.4. Disabling unwanted state advertisement by an IP dual-stack LSR

   In IP dual-stack scenarios, an LSR2 may advertise unnecessary state
   (label/address bindings) towards peer LSR1 corresponding to IPv6
   label switching application once a session is established mainly for
   exchanging state for IPv4. The similar scenario also applies when
   advertising IPv4 label switching state on a session meant for IPv6.
   The Application Control capability and its procedures defined in this
   document can help to withdraw its addresses. avoid such unnecessary state advertisement.

   Consider IP dual-stack environment where LSR2 is enabled for IPoMPLS
   application for both IPv4 and IPv6, but LSR1 will also is enabled for (or
   interested in) only IPv4oMPLS. To avoid receiving unwanted state
   advertisement for IPv6oMPLS application from LSR2, LSR1 can send IP
   Label Switching
   "Application Control" capability TLV with element for IPv6 label
   switching with D bit set to 1 in Capability the Initialization message towards
   LSR2
   with bit0-1 (IPv4, IPv6) in "Address Family Bitmap" set to zero. at the time of session establishment. Upon receipt of this TLV,
   capability, LSR2 will also disable IP all IPv6 label switching
   towards LSR1 and withdraw all previous IP label/address state using
   the same mechanics as described earlier for address binding
   advertisement towards LSR1. The disability of
   IP label switching dynamically should not impact L2VPN/PW application If IPv6oMPLS is later enabled on given session, and both LSRs should continue LSR1,
   LSR1 can update the capability by sending Application Control
   capability in Capability message towards LSR2 to exchange PW
   Signaling enable IPv6oMPLS
   application related state. dynamically.

   [LDPv6] specification section 7 also suggests an alternate way to
   avoid the unnecessary state advertisement in the above scenario.

7. Security Considerations

  The proposal introduced in this document does not introduce any new
  security considerations beyond that already apply to the base LDP
  specification [RFC5036] and [RFC5920].

8. IANA Considerations

  The document defines following two a new capability parameter TLVs TLV and
  requests following LDP TLV code point assignment by IANA from LDP
  "TLV Type Name Space" registry:

   o  "IP Label Switching  "Application Control Capability" TLV (requested codepoint: 0x50C)

   o  "PW Signaling Capability" TLV       (requested codepoint: 0x50D)

9. Conclusions

   The document proposed a solution using LDP Capabilities [RFC5561]
   mechanics to disable unnecessary state exchange, if/as desired,
   between LDP peers for currently non-negotiated IP/PW LDP
   applications.

10. References

10.1. Normative References

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

   [RFC5561] B. Thomas, K. Raza, S. Aggarwal, R. Aggarwal, and JL. Le
             Roux, "LDP Capabilities", RFC 5561, July 2009.

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

10.2. Informative References

   [RFC5918] R. Asati, I. Minei, and B. Thomas, "Label Distribution
             Protocol Typed Wildcard FEC", RFC 5918, August 2010.

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

   [RFC4762] M. Lasserre, and V. Kompella,  "Virtual Private LAN Service
             (VPLS) Using Label Distribution Protocol (LDP) Signaling",
             RFC 4762, January 2007.

  [RFC2119] S. Bradner, "Key words for use

   [P2MP-PW] Martini, L. et. al, "Signaling Root-Initiated Point-to-
             Multipoint Pseudowires using LDP", draft-ietf-pwe3-p2mp-pw-
             04.txt, Work in RFCs to Indicate
             Requirement Levels", BCP 14, RFC2119, March 1997.

10.2. Informative References

   [RFC5918] R. Asati, I. Minei, and B. Thomas, "Label Distribution
             Protocol Typed Wildcard FEC", RFC 5918, August 2010. Progress, October 2011.

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

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

   [LDPv6]   R. Asati, et al., "Updates to LDP for IPv6", draft-ietf-
             mpls-ldp-ipv6-07.txt, Work in Progress, June 2012.

   [RFC5920] L. Fang, et al., "Security Framework for MPLS and GMPLS
             Networks", RFC 5920, July 2010.

11. Acknowledgments

   The authors would like to thank Eric Rosen for his valuable input and
   comments.

   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