Internet DRAFT - draft-pdutta-mpls-ldp-adj-capability

draft-pdutta-mpls-ldp-adj-capability






MPLS Working Group                                              P. Dutta
Internet-Draft                                               M. Aissaoui
Intended status: Standards Track                          Alcatel-Lucent
Expires: October 7, 2012                                  April 05, 2012


                       LDP Adjacency Capabilities
                draft-pdutta-mpls-ldp-adj-capability-00

Abstract

   This document defines method for negotiation of a set of capabilities
   specific to a Label Distribution Protocol (LDP) Hello Adjacency.  The
   document uses the TLVs for the LDP Capabilities defined in [RFC5561]
   to be used for exchanging capabilities over LDP Hello Adjacencies.
   The Hello Adjacency capabilities can be thought of as "Traffic
   Forwarding Capabilities" (TFC).  Some capabilties already exist that
   can be re-used for hello adjacency specific capabilities and it is
   likely that some may be defined in future.  This document defines the
   mechanism to advertise LDP TFCs for a hello adjacency as well as
   mechanism to enable and disable TFCs after a hello adjacency is
   formed between LDP peers.

Requirements Language

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

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 October 7, 2012.

Copyright Notice




Dutta & Aissaoui         Expires October 7, 2012                [Page 1]

Internet-Draft            LDP Adj Capabilities                April 2012


   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.


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  LDP Adjacency Capability  . . . . . . . . . . . . . . . . . . . 5
   3.  Specifying Capabilities in LDP Hello Message  . . . . . . . . . 5
   4.  Interaction between LDP Session and Adjacency Capabilities  . . 6
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
   6.  Security Considerations . . . . . . . . . . . . . . . . . . . . 6
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 7
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 7
     8.1.  Normative References  . . . . . . . . . . . . . . . . . . . 7
     8.2.  References  . . . . . . . . . . . . . . . . . . . . . . . . 7
   Appendix A.  An Appendix  . . . . . . . . . . . . . . . . . . . . . 7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 7























Dutta & Aissaoui         Expires October 7, 2012                [Page 2]

Internet-Draft            LDP Adj Capabilities                April 2012


1.  Introduction

   [RFC5561] defines LDP Capabilities that are negotiated during
   establishement of a LDP session between two peering Label Switch
   Routers (LSR).  LDP Capability advertisement provides means for an
   LDP speaker to announce what it can receive and process over a LDP
   session.  For example, a speaker may exchange capabilities of
   upstream label allocation, in bound label filtering or support of
   various Forwarding Equivalence Classes (FECs).  Each Capability Type
   defines its own procedures, parameters and TLVs as described in
   [RFC5561].

   The LDP Capabilities defined in [RFC5561] is applicable to all hello
   adjacencies associated with a LDP session.  However, there may be
   certain Capabilities (based on the specific Capability Type) that may
   not be applicable to all hello adjacencies associated with a LDP
   session between two LDP speakers.  For example, It is possible that
   there can be multiple Equal Cost Multi Path (ECMP) nterfaces between
   two LDP speakers and thus multiple Hello Adjacencies are associated
   with the session, one adjacency on each interface.  Certain LDP
   Capabilities negotiated through the session are applicable to all
   such interfaces over which hello adjacencies are formed for the LDP
   session, whereas some capabilities may be applicable only to a sub-
   set of the Interfaces.

   Such interface specific capabilities can be various FEC specific
   capabilities exchanged over the peering session.  It is possible that
   a subset of the interfaces from the ECMP set may not be capable of
   setting up the Label Switched Paths (LSPs) for certain FEC types that
   have been exchanged over the peering session.  Further an operator
   may choose to exclude a subset of the ECMP interfaces from forwarding
   or receiving traffic on certain FEC types for administrative policy
   reasons.  Such separation may be also required for fate separation of
   LDP LSP types in data plane.  Thus it is also required for
   negotiation of capabilities at per interface level whether the
   interface in a peer is capable or willing to forwarding traffic for a
   FEC type on an interface.  Two examples are described below:

         +------+----------------L1------------------+-------+
         |      |                                    |       |
         |LSR-A |----------------L2------------------| LSR-B |
         |      |                                    |       |
         +------+----------------L3------------------+-------+
                Figure 1: Hello Adjacencies over ECMP.

   An LDP session is formed between LSR-A and LSR-B with hello
   adjacencies over three ECMP interfaces respectively as IF1, IF2, and
   IF3.



Dutta & Aissaoui         Expires October 7, 2012                [Page 3]

Internet-Draft            LDP Adj Capabilities                April 2012


   Case 1:

   Let's assume that the hello adjacencies over IF1, IF2 and IF3 are
   using either IPv4 or IPv6 based interfaces but not both (dual-stack).
   Further the interface capability definitions are as follows:

   All the three interfaces are capable of setting up LDP LSPs for IPv4
   FEC Element Types.

   Interface IF1 and IF2 are capable of setting up LDP Multi-point (MP)
   LSPs defined in [RFC6388]

   Interface IF2 and IF3 are capable of setting up LDP LSPs for IPv6 FEC
   Element Types, or the operator decided to enable so.

   Thus the LDP Hellos Messages exchanged over the interfaces need to
   advertise capabilities as below in order to negotiate the LSP types
   to be set-up on the interfaces.

   The LDP Hello Messages exchanged over interface IF1 would advertise
   IPv4 FEC Type Capability and the respective MP FEC Type Capabilities,
   and would exclude IPv6 Capabilities.

   The LDP Hello Messages exchanged over interface IF2 would advertise
   IPV4 FEC Type Capability, MP FEC Type Capability and IPv6 FEC Type
   Capability.

   The LDP Hello Messages exchanged over interface IF3 would advertise
   IPV4 FEC Type Capability and IPv6 FEC Type Capability, and would
   exclude MP FEC Type Capability.

   Case 2:

     Node - A                                     Node - B
    +-------------+                              +--------------+
    |   LSR-A1:0--|============IF 1==============|---LSR-B1:0   |
    |           x |                              | x            |
    |   LSR-A2:0--|============IF 2==============|---LSR-B2:0   |
    |             |                              |              |
    +-------------+                              +--------------+

             Figure 2. Multiple LDP Instances for fate-separation of IPv4 and IPv6 LSPs

   This case refers to section 2.1.3 described in
   draft-pdutta-mpls-multi-ldp-instance-00.  In this case, for fate
   separation of IPv4 traffic and IPv6 traffic over dual stack
   interfaces.  In this case, all the ECMP inrerfaces are participating
   in both the LDP instances, for IPv4 and IPv6 respectively.  Each



Dutta & Aissaoui         Expires October 7, 2012                [Page 4]

Internet-Draft            LDP Adj Capabilities                April 2012


   inteface would originate two sets of Hello Messages.  One set would
   use IPv6 address on the interface as source address of the Hello
   Message for the LSR assigned for IPV6.  Another set would use IPv4
   address on the interface as source address of the Hello Message for
   the LSR assigned to IPv4.

   In such a scenerio, it is required that the Hello Messages originated
   by the IPv4 LDP instance would carry IPv4 FEC Capabilities only
   whereas the Hello Messages originated by the IPv6 LDP instance would
   carry IPv6 FEC Capabilities only.


2.  LDP Adjacency Capability

   The LDP Adjacency Capability or TFC advertisement mechanism operates
   as follows:

   - Each LDP speaker is assumed to implement a set of LDP capabilities
   per Interface.  At any time, a speaker may have none, one or more of
   those capabilities enabled on an interface.  When a capability is
   enabled , the speaker advertises that capability associated on that
   interface on the hello messages originated from that interface.  By
   advertising the capability over the interface, the speaker asserts
   that it shall perform the protocol actions specified for the
   capability on that interface.  Unless the capability has been
   advertised, the speaker will not perform protocol actions specified
   for the capability on that interface.

   - When a LDP speaker had advertised a set of capabilities on the
   Hello Messages sent over an interface, then at any time the speaker
   MAY announce changes to the advertised capabilities by reflecting
   then change in subsequent Hello Messages.


3.  Specifying Capabilities in LDP Hello Message

   This document uses Capabilty Parameter TLV defined in [RFC5561] that
   may be included as an OPTIONAL parameter in a LDP Hello Message to
   advertise a Capability associated with an Interface.  The Hello
   Message can carry a set of such Capability Parameters TLVs, one for
   each capability type.

   The LDP speaker MUST NOT include more than one instance of a
   Capability Parameter (as identified by the same TLV code point) in a
   Hello Message.  If an LDP speaker receives more than one instance of
   the same Capability Parameter type in a message, it SHOULD accept the
   first occurance of that Capability Type and ignore the next
   occurences in that message.



Dutta & Aissaoui         Expires October 7, 2012                [Page 5]

Internet-Draft            LDP Adj Capabilities                April 2012


   To ensure backward compatibility, if a speaker receives a LDP Hello
   Message without any Capability Parameter TLV then the receiver SHOULD
   assume that the interface over which the hello adjacency is formed is
   capable of the entire set of capabilities associated with the session
   established with the peer.  Such capability designer should specify
   rules of that adjacency specific capability.  For example, if a
   received Hello Message does not carry any Capability Parameter then
   receiver should assume that the interface is capable of sending or
   receving of all FEC types advertised by the LDP session between the
   speakers.  If a Hello Message received over an interface carries one
   or more Capability Parameters then receiver SHOULD use that interface
   only as per the received capabilities.

   For dual stack deployments involving IPv4 and IPv6 interfaces between
   LDP peers, the IP Label Switching Capabilities defined in
   [I-D.ietf-mpls-ldp-ip-pw-capability] can be used.

   Note that it may be possible to define some capabilities in future
   that may not be applicable to ber advertised by LDP session but only
   over the Hello Adjacency.  Such capabilities are out of scope of this
   document.


4.  Interaction between LDP Session and Adjacency Capabilities

   Capabilities advertised via LDP session SHOULD be applicable to all
   interfaces unless it is explicitly excluded on a given interface.

   An LDP speaker MAY receive a set of Capabilities over a Hello
   Adjacency with a peer but peer may not have included the Capability
   set while establishing an LDP session.  Such situation may arise in
   multi-acess Interfaces where an LDP speaker may have established
   sessions with multiple LDP peers.  In such a case the LDP speaker
   MUST not exercise the interface capabilities that are not included in
   the LDP session with the peer.


5.  IANA Considerations

   This document makes no request of IANA.

   Note to RFC Editor: this section may be removed on publication as an
   RFC.


6.  Security Considerations

   This document does not specify additional security implications to



Dutta & Aissaoui         Expires October 7, 2012                [Page 6]

Internet-Draft            LDP Adj Capabilities                April 2012


   what has been described in [RFC5561]


7.  Acknowledgements

   The authors would like to thank Wim Henderickx for the insightful
   comments and probing questions.


8.  References

8.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., Minei, I., and B. Thomas, "LDP
              Specification", RFC 5036, October 2007.

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

8.2.  References

   [I-D.ietf-mpls-ldp-ip-pw-capability]
              Raza, K. and S. Boutros, "LDP IP and PW Capability",
              draft-ietf-mpls-ldp-ip-pw-capability-01 (work in
              progress), February 2012.

   [RFC6388]  Wijnands, IJ., Minei, I., Kompella, K., and B. Thomas,
              "Label Distribution Protocol Extensions for Point-to-
              Multipoint and Multipoint-to-Multipoint Label Switched
              Paths", RFC 6388, November 2011.


Appendix A.  An Appendix















Dutta & Aissaoui         Expires October 7, 2012                [Page 7]

Internet-Draft            LDP Adj Capabilities                April 2012


Authors' Addresses

   Pranjal Kumar Dutta
   Alcatel-Lucent
   701 E Middlefield Road
   Mountain View, California  94043
   USA

   Phone:
   Fax:
   Email: pranjal.dutta@alcatel-lucent.com


   Mustapha Aissaoui
   Alcatel-Lucent
   600 May Road
   Kanata, ON
   Canada

   Phone:
   Fax:
   Email: mustapha.aissaoui@alcatel-lucent.com
   URI:




























Dutta & Aissaoui         Expires October 7, 2012                [Page 8]