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]