Internet DRAFT - draft-osborne-isis-cc-stlv

draft-osborne-isis-cc-stlv






Network Working Group                                         E. Osborne
Internet-Draft                                               L. Ginsberg
Intended status: Experimental                              Cisco Systems
Expires: March 23, 2012                               September 20, 2011


            Component and Composite Link Membership in IS-IS
                     draft-osborne-isis-cc-stlv-00

Abstract

   This document defines the means for IS-IS to advertise TE attributes
   of component links and their relationship to the composite link of
   which they are a member.

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 March 23, 2012.

Copyright Notice

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



Osborne & Ginsberg       Expires March 23, 2012                 [Page 1]

Internet-Draft            osborne-isis-cc-stlv            September 2011


   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.  TE Component TLV  . . . . . . . . . . . . . . . . . . . . . . . 3
     2.1.  Inheritance between Extended IS TLV and TE Component
           TLV . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
       2.1.1.  Rules for existing sub-TLVs . . . . . . . . . . . . . . 5
       2.1.2.  Rules for future sub-TLVs . . . . . . . . . . . . . . . 7
     2.2.  Composite identifier  . . . . . . . . . . . . . . . . . . . 7
   3.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
   4.  Security Considerations . . . . . . . . . . . . . . . . . . . . 8
   5.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 8
   6.  Normative References  . . . . . . . . . . . . . . . . . . . . . 8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 9































Osborne & Ginsberg       Expires March 23, 2012                 [Page 2]

Internet-Draft            osborne-isis-cc-stlv            September 2011


1.  Introduction

   Composite links [I-D.ietf-rtgwg-cl-requirement] require the ability
   to place MPLS-TE LSPs across specific components of a composite link.
   One way to do this is to advertise both the composite and components
   as links in the TE database using the mechanisms defined in
   [RFC5305].  In order to do this, a relationship must be established
   between a given composite link and its component links.  This
   document defines a new TLV to be used to advertise the TE attributes
   of component links.  This new TLV is necessary in order to ensure
   that bandwidth reserved from a given component link is properly
   accounted for at the component level, and to do so in a backward-
   compatible manner.  Along with this new TLV, the document defines a
   sub-TLV to identify the composite link to which a component belongs.


2.  TE Component TLV

   The TE Component TLV (C-TLV) is based on the Extended IS Reachability
   TLV [RFC5305].  It is used to advertise Component Links.  The C-TLV
   is intended to mirror the TE functionality provided by the TE-
   specific sub-TLVs of the Extended IS Reachabiliy TLV.

   A C-TLV MUST follow all rules for sub-TLVs that pertain to an
   Extended IS Reachability TLV.  In particular, all sub-TLVs which are
   defined for use in an Extended IS Reachability TLV are usable in the
   C-TLV.  However, unlike the Extended IS Reachability TLV the C-TLV is
   NOT used in the IGP path calculation and therefore MUST be used only
   for MPLS-TE purposes.

   The C-TLV includes entries for component links.  Each component link
   entry is formatted as shown below.  Neighbor system ID/pseudonode
   number and default metric are inherited from the corresponding
   composite link advertisement in an Extended IS Reachability TLV.

   The TE Component TLV format is as shown in the following figure.  The
   composite identifier is defined in Section 2.2.














Osborne & Ginsberg       Expires March 23, 2012                 [Page 3]

Internet-Draft            osborne-isis-cc-stlv            September 2011


         x  CODE - TBD
         x  LENGTH - total length of the value field
         x  VALUE - A set of component link descriptors (16 - 255)

   Each component link descriptor is represented as

                                                        No. of Octets
                    +--------------------------------+
                    | Composite Link ID              |      4
                    +--------------------------------+
                    | sub-TLV length (12 - 250)      |      1
                    +--------------------------------+
                    | sub-TLVs                       |      12 - 250
                    +--------------------------------+


   There is also a multitopology (MT) version of the C-TLV which is
   exactly the same as the TE Component TLV, with the addition of two
   bytes of MT information.  The format of the MT-C-TLV is as follows:


         x  CODE - TBD
         x  LENGTH - total length of the value field
         x  VALUE - 2-byte MT membership plus the format of extended IS
                    reachability TLV, structured as follows:
                                                        No. of Octets
                    +--------------------------------+
                    |R |R |R |R |        MT ID       |      2
                    +--------------------------------+
                    | Component link descriptor      |    17 - 248
                    +--------------------------------+
                    .                                .
                    .                                .
                    +--------------------------------+
                    | Component link descriptor      |    17-148
                    +--------------------------------+


   Sub-TLVs in the MT-C-TLV are formatted as specified in the C-TLV.
   The total space available for sub-TLVs is 248 bytes.

   All rules which apply to the C-TLV also apply to the MT-C-TLV.

2.1.  Inheritance between Extended IS TLV and TE Component TLV

   A C-TLV may not carry all of the sub-TLVs that its parent Extended IS
   TLV does.  There are two reasons for this:




Osborne & Ginsberg       Expires March 23, 2012                 [Page 4]

Internet-Draft            osborne-isis-cc-stlv            September 2011


   1) There is no need for a C-TLV to repeat information which is
   identical across parent and child.  Identical information can simply
   be inherited from the parent by the receiving node.

   2) A sub-TLV may be a property only of the parent and not applicable
   to a child component.

   This section specifies inheritance procedures for all sub-TLVs
   currently defined for use in the Extended IS Reachability TLV.  Any
   documents which define future sub-TLVs MUST specify the inheritance
   rules for that sub-TLV or explicitly state that the default
   inheritance rules are specified.  If a sub-TLV exists in a child TE
   Component TLV, the value of that sub-TLV overrides any value
   specified in a parent

2.1.1.  Rules for existing sub-TLVs

   There are 21 sub-TLVs defined which can be used in TLV 22 [ref.  IANA
   assignment].  They are listed in the table below, along with a rule
   for the inheritance of that sub-TLV.  This section defines four
   rules.  The table below only uses two of them (I, C).  Rules M and P
   are for use by future sub-TLVs.

   M: Mandatory.  If this sub-TLV appears in the parent it MUST appear
   in the C-TLV, and if it appears in the C-TLV it MUST appear in the
   parent.  The values of the parent and child sub-TLVs MAY differ.

   P: Parent only.  This sub-TLV MUST NOT appear in the C-TLV.  It MAY
   appear in the parent.

   I: Inherited.  If this sub-TLV exists in the parent and is not
   specified for a given C-TLV, the C-TLV MUST inherit the value from
   the parent.  If this sub-TLV is specified explicitly in the C-TLV,
   that value overrides any value specified in the parent.

   C: The sub-TLV values are not inherited from parent to child.  The
   values may be optionally present in C-TLV or parent TLV.  The values
   may be optionally missing in C-TLV or parent TLV.  If values are
   present in both C-TLV and parent TLV they MAY differ.

   Ex: Exception.  See footnote [x] below










Osborne & Ginsberg       Expires March 23, 2012                 [Page 5]

Internet-Draft            osborne-isis-cc-stlv            September 2011


   Type  Description                                       Rule
   ============================================================
   3     Administrative group                              I
   4     Link Local/Remote Identifiers                     E1
   6     IPv4 Interface Address                            E1
   8     IPv4 Neighbor Address                             E1
   9     Maximum link bandwidth                            E2
   10    Maximum reservable link bandwidth                 E2
   11    Unreserved bandwidth                              E2
   12    IPv6 Interface Address                            E1
   13    IPv6 Neighbor Address                             E1
   18    TE Default metric                                 I
   19    Link-attributes                                   E3
   20    Link Protection Type                              I
   21    Interface Switching Capability Descriptor         I
   22    Bandwidth Constraints                             E2
   23    Unconstrainted TE LSP Count                       C
   24    remote AS number                                  I
   25    IPv4 remote ASBR Identifier                       E1
   26    IPv6 remote ASBR Identifier                       E1
   27    Interface Adjustment Capabilty Descriptor         I
   28    MTU                                               I
   29    SPB-Metric                                        I
   30    SPB-A-OALOG                                       I

   E1: A C-TLV MUST have a unique identifier for both ends of the link.
   This unique identifier MUST be of the same type (e.g.  IPv4, IPv6,
   other identifier) for both ends of the link.  A C-TLV MUST have only
   one unique identifier.  Assigning and identifying link local and
   remote identifiers is outside the scope of this document.

   E2: This rule applies to bandwidth, both the traditional TE bandwidth
   (types 9-11) and the DS-TE variants (type 22).  For link bandwidth of
   any type, if the parent advertises bandwidth then all children of the
   parent MUST also advertise bandwidth.  The bandwidth values MAY be
   different between parent and child, and from child to child.  The sum
   of the advertised link bandwidths for all children of a given parent
   MUST be lesser than or equal the advertised link bandwidth for the
   parent.

   E3: Whether a child inherits the link attributes specified in the
   parent depends on the specific attribute.  Both of the values
   identified in [RFC5029] (Local Protection Available and Link Excluded
   from Local Protection) follow rule I in this table.

   Any behaviors other than those specified in these rule MUST be
   ignored upon receipt.  For example, rule C says "If the parent does
   not specifiy this sub-TLV then the child MUST NOT specify the sub-



Osborne & Ginsberg       Expires March 23, 2012                 [Page 6]

Internet-Draft            osborne-isis-cc-stlv            September 2011


   TLV."  If, in violation of this rule, a child specifies bandwidth in
   the absence of parent bandwidth, that child bandwidth MUST be ignored
   by any nodes which receive the advertisement.  Ignoring invalid sub-
   TLV usage does not preclude an implementation from issuing warnings
   (e.g. syslogs) about an advertisement in violation of these rules.

2.1.2.  Rules for future sub-TLVs

   Any sub-TLVs defined after the publication of this document MUST
   define the inheritance behavior for the sub-TLV in the presence of
   composite and component links.  The sub-TLV MAY follow one of the
   rules specified above or MAY list its own unique rules.  Future
   standards SHOULD try to use one of the rules defined in this
   document; unnecessarily sophisticated inheritance behaviors will
   likely lead to confusion among implementations.  However, if an
   inheritance behavior specific to a particular sub-TLV is justifiable
   then it MAY be defined.

2.2.  Composite identifier

   The association between a composite link and its component links is
   made using the composite identifier.  The composite identifier is an
   identifier carried in both the Extended IS Reachability TLV for a
   composite link and the TE Component TLV for a given component.In the
   TE Component TLV the composite identifier is part of the component
   link descriptor.  In the Extended IS Reachability TLV the composite
   identifier is a sub-TLV.

   The composite ID is a 32-bit (4 octet) field defined 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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                           Composite ID                        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The composite identifier MUST be unique to the advertising router.
   The method of assignment of the composite identifier is out of the
   scope of this document.

   When carried in an Extended IS Reachability TLV, the composite
   identifier sub-TLV identifies that link as a composite link.  When
   carried in the TE Component TLV, the composite identifier identifies
   the composite link of which the given component is a member.  This
   association is necessary so that implementations which are component-
   aware can decide whether to establish an LSP over a component or one
   of its composites.  All components of a given composite MUST have a
   composite identifier, and the composite identifier of the composite
   and all of its components MUST match.  A node MAY advertise a



Osborne & Ginsberg       Expires March 23, 2012                 [Page 7]

Internet-Draft            osborne-isis-cc-stlv            September 2011


   composite link with no components, but if a node advertises any
   component links the node MUST also advertise an associated composite
   link.  A component link MUST NOT carry the composite identifier as a
   sub-TLV, as the composite identifier is part of the top level of the
   TE Component TLV.

   The composite ID sub-TLV needs a number assigned to it by IANA.  For
   now, the sub-TLV number is TBD.


3.  IANA Considerations

   Things we need from IANA:

   - a TLV number for the C-TLV

   - a TLV number for the C-TLV for use in multitopology (per
   [RFC5120]).

   - a number for the composite identifier when used as a sub-TLV of the
   IS Extended Reachability TLV

   - extension of the table in [http://www.iana.org/assignments/
   isis-tlv-codepoints/isis-tlv-codepoints.xml#isis-tlv-codepoints-3] to
   track the inheritance rules, or some other method to track
   inheritance rules per sub-TLV.


4.  Security Considerations

   There are no security considerations when using this sub-TLV; it is a
   link property like any other, and provides no more and no less
   exposure to security issues than the other sub-TLVs defined in
   [RFC5305].


5.  Acknowledgements

   Peter Psenak, Padma Pilay-Esnault, Stefano Previdi, Tony Li


6.  Normative References

   [I-D.ietf-rtgwg-cl-requirement]
              Villamizar, C., McDysan, D., Ning, S., Malis, A., and L.
              Yong, "Requirements for MPLS Over a Composite Link",
              draft-ietf-rtgwg-cl-requirement-04 (work in progress),
              March 2011.



Osborne & Ginsberg       Expires March 23, 2012                 [Page 8]

Internet-Draft            osborne-isis-cc-stlv            September 2011


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

   [RFC5120]  Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi
              Topology (MT) Routing in Intermediate System to
              Intermediate Systems (IS-ISs)", RFC 5120, February 2008.

   [RFC5305]  Li, T. and H. Smit, "IS-IS Extensions for Traffic
              Engineering", RFC 5305, October 2008.

   [RFC5307]  Kompella, K. and Y. Rekhter, "IS-IS Extensions in Support
              of Generalized Multi-Protocol Label Switching (GMPLS)",
              RFC 5307, October 2008.


Authors' Addresses

   Eric Osborne
   Cisco Systems
   300 Beaver Brook Road
   Boxborough, Massachusetts  01719


   Phone:
   Fax:
   Email: eosborne@cisco.com
   URI:


   Les Ginsberg
   Cisco Systems
   510 McCarthy Blvd.
   Milpitas, California  95035


   Phone:
   Fax:
   Email: ginsberg@cisco.com
   URI:












Osborne & Ginsberg       Expires March 23, 2012                 [Page 9]