MPLS Working Group                                          Rajiv Asati
Internet Draft                                            Cisco Systems
Intended status: Standards Track
Expires: July 2010                                            Ina Minei
                                                       Juniper Networks

                                                             Bob Thomas

                                                          March 4, 2010


        Label Distribution Protocol (LDP) 'Typed Wildcard' Forward
                          Equivalence Class (FEC)
                 draft-ietf-mpls-ldp-typed-wildcard-07.txt


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/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 July 4, 2010.



Copyright Notice

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



Asati, Thomas & Minei    Expires July 4, 2010                  [Page 1]

Internet-Draft    draft-ietf-mpls-ldp-typed-wildcard      March 4, 2010


   (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 BSD License.





Abstract

   The Label Distribution Protocol (LDP) specification for the Wildcard
   Forward Equivalence Class (FEC) element has several limitations.
   This document addresses those limitations by defining a Typed
   Wildcard FEC element and associated procedures. In addition, it
   defines a new LDP capability to address backward compatibility.



Table of Contents


   1. Introduction...................................................3
   2. Specification Language.........................................4
   3. The Typed Wildcard FEC Element.................................4
   4. Procedures for the Typed Wildcard FEC Element..................5
   5. Typed Wildcard FEC Capability..................................6
   6. Typed Wildcard FEC Element for Prefix FEC Element..............7
   7. Typed Wildcard FEC Element for Host and Wildcard FEC Elements..8
   8. IANA Considerations............................................8
   9. Security Considerations........................................9
   10. Acknowledgments...............................................9
   11. References...................................................10
      11.1. Normative References....................................10
      11.2. Informative References..................................10
   Author's Addresses...............................................11










Asati, Thomas & Minei    Expires July 4, 2010                  [Page 2]

Internet-Draft    draft-ietf-mpls-ldp-typed-wildcard      March 4, 2010


1. Introduction

   LDP [RFC5036] distributes labels for Forwarding Equivalence Classes
   (FECs).  LDP uses FEC TLVs in LDP messages to specify FECs.  An LDP
   FEC TLV includes 1 or more FEC Elements.  A FEC element includes a
   FEC type and an optional type-dependent value.

   RFC5036 specifies two FEC types (Prefix and Wildcard), and other
   documents specify additional FEC types; e.g., see [RFC4447] [MLDP].

   As specified by RFC5036, the Wildcard FEC Element refers to all FECs
   relative to an optional constraint.  The only constraint RFC5036
   specifies is one that limits the scope of the Wildcard FEC Element
   to "all FECs bound to a given label".

   The RFC5036 specification of the Wildcard FEC Element has the
   following deficiencies which limit its utility:

   1) The Wildcard FEC Element is untyped. There are situations where
      it would be useful to be able to refer to all FECs of a given
      type (as another constraint).

   2) Use of the Wildcard FEC Element is limited to Label Withdraw and
      Label Release messages only. There are situations where it would
      be useful to have Wildcard FEC Element, with type constraint, in
      Label Request messages.

   This document:

      - Addresses the above limitations by defining a Typed Wildcard
        FEC Element and procedures for its use.

      - Specifies use of the LDP capability mechanism [RFC5561] at
        session establishment time for informing a peer that an LDP
        speaker is capable of handling the Typed Wildcast FEC.

      - Specifies use of Typed Wildcard FEC Element in Label Request
        message.

      - Specifies the Typed Wildcard FEC Element for the Prefix FEC
        Element specified by RFC5036.

   Note that this document does not change procedures specified for the
   LDP Wildcard FEC Element by RFC5036.





Asati, Thomas & Minei    Expires July 4, 2010                  [Page 3]

Internet-Draft    draft-ietf-mpls-ldp-typed-wildcard      March 4, 2010


2. Specification 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 [RFC2119].

   LDP   - Label Distribution Protocol

   FEC   - Forwarding Equivalence Class

   TLV   - Type Length Value

   LSR   - Label Switch Router





3. The Typed Wildcard FEC Element

   The Typed Wildcard FEC Element refers to all FECs of the specified
   type that meet the constraint. It specifies a 'FEC Element Type' and
   an optional constraint, which is intended to provide additional
   information.

   The format of the Typed Wildcard FEC Element is:



   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 2
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Typed  (IANA) | FEC Element   | Len FEC Type  |               |
   | Wildcard      | Type          | Info          |               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               |
   |                                                               |
   ~          Additional FEC Type-specific Information             ~
   |                  (Optional)                                   |
   |                                               +-+-+-+-+-+-+-+-+
   |                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Figure 1 Typed Wildcard FEC Element



   where:


Asati, Thomas & Minei    Expires July 4, 2010                  [Page 4]

Internet-Draft    draft-ietf-mpls-ldp-typed-wildcard      March 4, 2010


     Typed Wildcard     :  One octet FEC Element Type (to be assigned
     by IANA).

     FEC Element Type   :  One octet FEC Element Type that specifies
     the FEC Element Type to be wildcarded. Please see section 3.4.1 of
     RFC5036.

         Any (future) document specifying new FEC Element Type (not
         defined in RFC5630) should prescribe whether typed wildcarding
         is needed for that FEC Element Type.

     Len FEC Type Info  :  One octet that specifies the length in
     octets of the FEC Type Specific information field. It MUST be set
     to 0 if there is no Additional FEC Type-specific Information.

     Additional FEC Type-specific Information:  (Optional) Additional
     information specific to the FEC Element Type required to fully
     specify the Typed Wildcard. If this field is absent, then all FECs
     of the specified FEC Type would be matched.

         Any (future) document specifying Typed wildcarding for any FEC
         Element Type should also specify the length and format of
         Additional FEC Type Specific Information, if included.

   This document specifies one FEC Element Type instance (e.g. Prefix
   FEC) for the 'Typed Wildcard FEC Element' in section 6.



4. Procedures for the Typed Wildcard FEC Element

   When a FEC TLV contains a Typed Wildcard FEC Element, the Typed
   Wildcard FEC Element MUST be the only FEC Element in the TLV. If an
   LDP speaker receives a FEC TLV containing Typed Wildcard FEC Element
   and any other FEC Elements, then the LDP speaker should ignore the
   other FEC Elements and continue processing as if the message had
   contained only the Typed Wildcard FEC Element.

   An LDP implementation that supports the Typed Wildcard FEC Element
   MUST support its use in Label Request, Label Withdraw and Label
   Release messages.

   An LDP implementation that supports the Typed Wildcard FEC Element
   MUST support it for every FEC Element Type implemented for which it
   is defined.




Asati, Thomas & Minei    Expires July 4, 2010                  [Page 5]

Internet-Draft    draft-ietf-mpls-ldp-typed-wildcard      March 4, 2010


   Receipt of a Label Request message with a FEC TLV containing a Typed
   Wildcard FEC Element is interpreted as a request to send one or more
   Label Mappings for all FECs of the type specified by the FEC Element
   Type field in the Typed Wildcard FEC Element encoding.

   An LDP implementation that supports the Typed Wildcard FEC Element
   MUST support the following constraints whenever a Typed Wildcard FEC
   appears in a Label Withdraw or Label Release message:

   1) If the message carries an optional Label TLV the Typed Wildcard
      FEC Element refers to all FECs of the specified FEC type bound to
      the specified label.

   2) If the message has no Label TLV the Typed Wildcard FEC Element
      refers to all FECs of the specified FEC type.

   Backwards compatibility with a router not supporting the Typed
   Wildcard FEC element is ensured by the FEC procedures defined in
   RFC5036. Quoting from RFC5036:

     "If it" [an LSR] "encounters a FEC Element type it cannot decode,
     it SHOULD stop decoding the FEC TLV, abort processing the message
     containing the TLV, and send an "Unknown FEC" Notification message
     to its LDP peer signaling an error."

   A router receiving a FEC TLV containing a Typed Wildcard FEC element
   for a FEC Element Type that it either doesn't support or for a FEC
   Element Type that doesn't support the use of wildcarding, MUST stop
   decoding the FEC TLV, abort processing the message containing the
   TLV, and send an "Unknown FEC" Notification message to its LDP peer
   signaling an error.



5. Typed Wildcard FEC Capability

   As noted above, RFC5056 FEC procedures provide for backward
   compatibility with an LSR not supporting the Typed Wildcard FEC
   Element.  However, they don't provide means for LSR wishing to use
   the Typed Wildcard FEC Element to determine whether a peer supports
   it other than to send a message that uses the FEC Element and to
   wait and see how the peer responds.

   An LDP speaker that supports the Typed Wildcard FEC Element MUST
   inform its peers of the support by including a Typed Wildcard FEC
   Element Capability Parameter [RFC5561] in its Initialization
   messages.


Asati, Thomas & Minei    Expires July 4, 2010                  [Page 6]

Internet-Draft    draft-ietf-mpls-ldp-typed-wildcard      March 4, 2010


   The Capability Parameter for the Typed Wildcard FEC capability is a
   TLV with 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |U|F| Typed WCard FEC Cap (IANA)|            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |S| Reserved    |
   +-+-+-+-+-+-+-+-+

               Figure 2 Typed Wildcard FEC Capability format

   Where:

     U and F bits          : MUST be 1 and 0 respectively as per
     section 3 of LDP Capabilities [RFC5561].

     Typed WCard FEC Cap   : TLV code point to be assigned by IANA.

     S-bit                 : MUST be 1 (indicates that capability is
     being advertised).



6. Typed Wildcard FEC Element for Prefix FEC Element

   RFC5036 defines the Prefix FEC Element but it does not specify a
   Typed Wildcard for it.  This section specifies the Typed Wildcard
   FEC Element for Prefix FEC Elements.

   The format of the Prefix FEC Typed Wildcard FEC Element ("Prefix FEC
   Wildcard" for short), based on Figure 1, is:



   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 2
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Typed Wcard   | Type = Prefix |   Len = 2     |  Address...   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | ...Family     |
   +-+-+-+-+-+-+-+-+

        Figure 3 Format of Prefix FEC Element using Typed Wildcard


Asati, Thomas & Minei    Expires July 4, 2010                  [Page 7]

Internet-Draft    draft-ietf-mpls-ldp-typed-wildcard      March 4, 2010


   Where:

   FEC Element Type  :  "Prefix" FEC Element (0x02, per RFC5036).

   Len FEC Type Info :  Two octets (=0x02).

   Address Family    :  Two octet quantity containing a value from
   ADDRESS FAMILY NUMBERS in [IANA-AF].

   The procedures described in Section 4 apply to the Prefix FEC
   Wildcard processing.



7. Typed Wildcard FEC Element for Host and Wildcard FEC Elements

   There is no need to specify Typed Wildcard FEC Elements for the Host
   FEC Element specified by [RFC3036], nor for the Wildcard FEC Element
   specified by RFC5036. The [RFC3036] Host FEC Element has been
   removed from RFC5036, and the Wildcard FEC Element is untyped by
   definition.

   In other words, the 'FEC Element Type' field in 'Typed Wildcard FEC
   Element' MUST NOT be 0x01.



8. IANA Considerations

   This draft introduces a new LDP FEC Element Type and a new LDP
   Capability both of which require IANA assignment -

      The 'Typed Wildcard' FEC Element requires a code point from the
      LDP FEC Type Name Space.  [RFC5036] partitions the FEC Type Name
      Space into 3 regions:  IETF Consensus region, First Come First
      Served region, and Private Use region.  The authors recommend
      that the code point 0x05 from the IETF Consensus range be
      assigned to the 'Typed Wildcard' FEC Element.

      The 'Typed Wildcard FEC' Capability requires a code point from
      the TLV Type name space.  [RFC5036] partitions the TLV TYPE name
      space into 3 regions:  IETF Consensus region, Vendor Private Use
      region, and Experimental Use region.  The authors recommend that
      a code point from the IETF Consensus range be assigned to the
      'Typed Wildcard FEC' Capability.




Asati, Thomas & Minei    Expires July 4, 2010                  [Page 8]

Internet-Draft    draft-ietf-mpls-ldp-typed-wildcard      March 4, 2010


9. Security Considerations

   No security considerations beyond those that apply to the base LDP
   specification [RFC5036] and further described in [MPLSsec] apply to
   use of the Typed Wildcard FEC Elements as described in this
   document.

   One could deduce that the security exposure is reduced by this
   document, since an LDP speaker using Typed Wildcard FEC Element
   could use a single message to request, withdraw or release all the
   label mappings of a particular type (a particular AFI, for example),
   whereas an LDP speaker using Wildcard FEC Element, as defined in
   based LDP specification [RFC5036], could use a single message to
   request, withdraw or release all the label mappings of all types
   (all AFIs, for example).



10. Acknowledgments

   The authors would like to thank Yakov Rekhter for suggesting that
   the limitations of the Wildcard FEC be addressed. Also, thanks to
   Adrian Farrel and Richard L. Barnes for extensive review of this
   document.

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























Asati, Thomas & Minei    Expires July 4, 2010                  [Page 9]

Internet-Draft    draft-ietf-mpls-ldp-typed-wildcard      March 4, 2010


11. References

11.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 Thomas, B., "LDP
             Specification", RFC 5036, October 2007.

   [RFC5561]   Thomas, B., Aggarwal, S., Aggarwal, R., Le Roux, J.L.,
             "LDP Capabilities", RFC5561, May 2007.



11.2. Informative References

   [RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A. and
             Thomas, B., "LDP Specification", RFC 3036, January 2001.

   [RFC4447] Martini, L., Editor, "Pseudowire Setup and Maintenance
             Using the label Distribution Protocol (LDP)", RFC4447,
             April 2006.

   [MLDP]    Minei, I., Wijnands, I., Editors, "Label Distribution
             Protocol Extensions for Point-to-Multipoint and
             Multipoint-to-Multipoint Label Switched Paths", draft-
             ietf-mpls-ldp-p2mp-08.txt, Work in Progress, Oct 2009.

   [MPLSsec] Fang, L., "Security Framework for MPLS and GMPLS
             Networks", draft-ietf-mpls-mpls-and-gmpls-security-
             framework-07, Work in Progress, Oct 2009.

   [IANA-AF] http://www.iana.org/assignments/address-family-numbers.















Asati, Thomas & Minei    Expires July 4, 2010                 [Page 10]

Internet-Draft    draft-ietf-mpls-ldp-typed-wildcard      March 4, 2010


Author's Addresses

   Ina Minei
   Juniper Networks
   1194 North Mathilda Ave.
   Sunnyvale, CA 94089
   Email: ina@juniper.net


   Bob Thomas
   Email: bobthomas@alum.mit.edu


   Rajiv Asati
   Cisco Systems,
   7025-6 Kit Creek Rd, RTP, NC, 27709-4987
   Email: rajiva@cisco.com
































Asati, Thomas & Minei    Expires July 4, 2010                 [Page 11]

