[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-thomas-mpls-ldp-typed-wildcard) 00 01 02 03 04 05 06 07 RFC 5918

Network Working Group                                         Bob Thomas
Internet Draft                                       Cisco Systems, Inc.
Expiration Date: November 2007
                                                               Ina Minei
                                                        Juniper Networks

                                                                May 2007


                         LDP Typed Wildcard FEC


               draft-ietf-mpls-ldp-typed-wildcard-01.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of 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.

Copyright Notice

   Copyright (C) The IETF TRUST (2007).


Abstract

   The LDP specification [RFC3036] 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 RFC3036.



Thomas & Minei                                                  [Page 1]

Internet Draft draft-ietf-mpls-ldp-typed-wildcard-01.txt        May 2007




Table of Contents

    1  Introduction  ..........................................   2
    2  Specification Language  ................................   3
    3  The Typed Wildcard FEC Element  ........................   3
    4  Procedures for the Typed Wildcard FEC Element  .........   4
    5  Typed Wildcard FEC Element for RFC3036 Prefix FEC Element  5
    6  RFC3036 Host and Wildcard FEC Elements  ................   5
    7  IANA Considerations  ...................................   5
    8  Security Considerations  ...............................   6
    9  Acknowledgements  ......................................   6
   10  References  ............................................   6
   11  Author Information  ....................................   7
   12  Intellectual Property Statement  .......................   7
   13  Full Copyright Statement  ..............................   8





1. Introduction

   LDP [RFC3036] 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.

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

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

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

      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.




Thomas & Minei                                                  [Page 2]

Internet Draft draft-ietf-mpls-ldp-typed-wildcard-01.txt        May 2007


   This document addresses these deficiencies by defining a Typed
   Wildcard FEC Element and procedures for its use.  Note that this
   document does not change procedures specified for the LDP Wildcard
   FEC Element by RFC3036.


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
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Typed  (IANA) | FEC Element   | Len FEC Type  |               |
       | Wildcard      | Type          | Info          |               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               |
       |                                                               |
       |         Additional FEC Type-specific Information              |
       |                                               +-+-+-+-+-+-+-+-+
       |                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   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.



Thomas & Minei                                                  [Page 3]

Internet Draft draft-ietf-mpls-ldp-typed-wildcard-01.txt        May 2007


   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.


4. Procedures for the Typed Wildcard FEC Element

   It is the responsibility of the designer of the FEC Element Type to
   specify whether typed wildcarding is required for the FEC Element
   Type.  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.

   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. 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
   RFC3036. Quoting from RFC3036:

       "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



Thomas & Minei                                                  [Page 4]

Internet Draft draft-ietf-mpls-ldp-typed-wildcard-01.txt        May 2007


   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 Element for RFC3036 Prefix FEC Element

   RFC3036 defines the Prefix FEC Element but it does not specify a
   Typed Wildcard for it.  This section specifies the Typed Wildcard FEC
   Element for RFC3036 Prefix 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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Typed WCard   | Prefix (2)    |      2        |   Address...  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | ...Family     |
       +-+-+-+-+-+-+-+-+

     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.


6. RFC3036 Host and Wildcard FEC Elements

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


7. IANA Considerations

   The Typed Wildcard FEC Element requires a code point from the LDP FEC
   Type Name Space.  IANA manages the FEC TYPE name space as recommended
   by the following from [RFC3036]:

      "FEC Type Name Space

       The range for FEC types is 0 - 255.

       Following the policies outlined in [RFC3036], FEC types in the
       range 0 - 127 are allocated through an IETF Consensus action,
       types in the range 128 - 191 are allocated as First Come First



Thomas & Minei                                                  [Page 5]

Internet Draft draft-ietf-mpls-ldp-typed-wildcard-01.txt        May 2007


       Served, and types in the range 192 - 255 are reserved for Private
       Use."

   The authors recommend that the code point 0x05 from the IETF
   Consensus range be assigned to the Typed Wildcard FEC Element.


8. Security Considerations

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


9. Acknowledgements

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


10. References

   Normative References

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

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

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

   Informative References

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

     [MLDP] Minei, I., Wijnamds, I., Editors, "Label Distribution
     Protocol Extensions for Point-to-Multipoint and Multipoint-to-
     Multipoint Label Switched Paths", draft-ietf-mpls-ldp-p2mp-02.txt,
     Work in Progress, October 2006.

     [RFC3036bis] Andersson, L., Minei, I., Thomas, B., Editors, "LDP
     Specification", draft-ietf-mpls-rfc3036bis-04.txt, Work in
     Progress, September 2006.






Thomas & Minei                                                  [Page 6]

Internet Draft draft-ietf-mpls-ldp-typed-wildcard-01.txt        May 2007


11. Author Information

   Bob Thomas
   Cisco Systems, Inc.
   1414 Massachusetts Ave.
   Boxborough MA 01719
   Email: rhthomas@cisco.com

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


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













Thomas & Minei                                                  [Page 7]

Internet Draft draft-ietf-mpls-ldp-typed-wildcard-01.txt        May 2007


13. Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   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.



































Thomas & Minei                                                  [Page 8]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/