NetworkMPLS Working Group                                           Bob Thomas
Internet Draft                                       Cisco Systems, Inc.
Expiration Date: September 2008
Intended Status: Proposed Standard status: Standards Track
Expires: Feb 2010                                             Ina Minei
                                                       Juniper Networks

                                                            Rajiv Asati
                                                           Cisco Systems

                                                      September 5, 2009

                          LDP Typed Wildcard FEC

               draft-ietf-mpls-ldp-typed-wildcard-03.txt
                 draft-ietf-mpls-ldp-typed-wildcard-04.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of which he BCP 78 and BCP 79. This document may contain material
   from IETF Documents or she is aware
   have been IETF Contributions published or will made publicly
   available before November 10, 2008. The person(s) controlling the
   copyright in some of this material may not have granted the IETF
   Trust the right to allow modifications of such material outside the
   IETF Standards Process. Without obtaining an adequate license from
   the person(s) controlling the copyright in such materials, this
   document may not be disclosed, modified outside the IETF Standards Process, and any
   derivative works of which he or she becomes
   aware will it may not be disclosed, in accordance with Section 6 of BCP 79. created outside the IETF Standards
   Process, except to format it for publication as an RFC or to
   translate it into languages other than English.

   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.
        http://www.ietf.org/shadow.html

   This Internet-Draft will expire on Feb 5, 2010.

Copyright Notice

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

   This document is subject to BCP 78 and the IETF TRUST (2008). Trust's Legal
   Provisions Relating to IETF Documents in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

Abstract

   The LDP specification [RFC5036] for the Wildcard FEC element has
   several deficiencies.  This document corrects those deficiencies. In
   addition, it specifies the Typed Wildcard FEC for the Prefix FEC
   Element Type defined in RFC5036.

Table of Contents

    1    Introduction  .......................................   2
    2

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

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

   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.

      2.

   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 in Label Request messages.

   This document:

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

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

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

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

3. The Typed Wildcard FEC Element

   The Typed Wildcard FEC Element refers to all FECs of a given type
   relative to an optional constraint.  The constraint, if present, is
   determined from the context in which the Typed Wildcard FEC Element
   appears.

   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             ~
   |                                                               |
   |                                               +-+-+-+-+-+-+-+-+
   |                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Figure 1 Typed Wildcard FEC Element

   where:

     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.

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

     Additional FEC Type-specific Information:  Additional information
     specific to the FEC Element Type required to fully specify the
     Typed Wildcard.

     Specification of the length and format of Additional FEC Type
     Specific Information for particular FEC Element Types is outside of
     the scope of this document.  It is the responsibility of the
     designer of the FEC Element Type to specify the length and format
     of any Additional FEC Type Specific Information.

   This document discusses two instances of Typed Wildcard FEC Elements
   in section 6 and 7.

4. Procedures for the Typed Wildcard FEC Element

   It is the responsibility of the designer of the FEC Element Type to
   determine whether typed wildcarding makes sense the FEC Element Type.
   If typed wildcarding does make sense the specification for the FEC
   Element Type MUST include support for it.

   When typed wildcarding is supported for a FEC Element Type it is the
   responsibility of the designer to specify the length and format of
   any Additional FEC Type Specific Information.

   When a FEC TLV contains a Typed Wildcard FEC Element the Typed
   Wildcard FEC Element MUST be the only FEC Element in the TLV.

   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.

   Receipt of a Label Request message with a FEC TLV containing a Typed
   Wildcard FEC Element is interpreted as a request to send a Label
   Mapping 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.

   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.

   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 above, RFC5056 FEC procedures provide for backward
   compatibility with a 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 [LDPCap] [RFC5561] in its Initialization
   messages.

   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
   |U|F| Typed WCard FEC Cap (IANA) | (IANA)|            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |S| Reserved    |
   +-+-+-+-+-+-+-+-+

   where:

               Figure 2 Typed Wildcard FEC Capability format

   Where:

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

     Typed WCard FEC Cap: Cap   : TLV code point for the Typed Wildcard FEC
       capability (to to be assigned by IANA).

     S-bit: Must 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 ("Prefix FEC
   Wildcard" for short) 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 Wcard   | Prefix (2)    |      2        |  Address...   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | ...Family     |
   +-+-+-+-+-+-+-+-+

        Figure 3 Format of Prefix FEC Element using Typed Wildcard

   Where:

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

   The procedures of Section 4 apply to the Prefix FEC Wildcard.

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

8. IANA Considerations

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

      The Typed Wildcard 'Typed Wildcard' FEC Element requires a code point from the
      LDP FEC Type name space. Name Space.  [RFC5036] partitions the FEC TYPE name space 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 'Typed Wildcard' FEC Element.

      The Typed 'Typed Wildcard FEC 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, First Come First Served
      region, and Private Use region.  The authors recommend that a code
      point from the IETF Consensus range be assigned to the Typed 'Typed
      Wildcard FEC FEC' Capability.

9. Security Considerations

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

10. Acknowledgements Acknowledgments

   The authors wish would like to thank Yakov Rehkter Rekhter for suggesting that the
   deficiencies of the Wildcard FEC be addressed.

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

11. References

11.1. Normative References

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

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

     [LDPCap]

   [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", draft-ietf-mpls-ldp-capabilities-01, Work in
     Progress, February 2008. 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.

     [PWE3]

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

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

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

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

12. Author Information

   Bob Thomas
   Cisco Systems, Inc.
   1414 Massachusetts Ave.
   Boxborough MA 01719
   Email: rhthomas@cisco.com http://www.iana.org/assignments/address-family-numbers.

Author's Addresses

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

13. Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at ietf-
   ipr@ietf.org.

14. Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST
   AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
   EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
   THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY
   IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR
   PURPOSE.

   Bob Thomas
   Email: bobthomas@alum.mit.edu

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