idnits 2.17.1 draft-ospf-cc-stlv-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 4, 2011) is 4649 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-16) exists of draft-ietf-rtgwg-cl-requirement-04 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Osborne 3 Internet-Draft Cisco Systems, Inc. 4 Intended status: Experimental P. Psenak 5 Expires: February 5, 2012 Cisco Systems. 6 August 4, 2011 8 Component and Composite Link Membership in OSPF 9 draft-ospf-cc-stlv-00 11 Abstract 13 This document provides a TLV and sub-TLV for OSPF to establish a 14 relationship between component and composite links in MPLS-TE opaque 15 LSAs. 17 Requirements Language 19 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 20 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 21 document are to be interpreted as described in RFC 2119 [RFC2119]. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on February 5, 2012. 40 Copyright Notice 42 Copyright (c) 2011 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Component TLV . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2.1. Removing link type and link ID sub-TLVs from C-TLV . . . . 3 60 2.2. Inheritance between Link TLV and C-TLV . . . . . . . . . . 3 61 2.3. Component/composite ID sub-TLV . . . . . . . . . . . . . . 5 62 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 63 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 64 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 65 6. Normative References . . . . . . . . . . . . . . . . . . . . . 6 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 68 1. Introduction 70 Composite links [I-D.ietf-rtgwg-cl-requirement] require the ability 71 to place MPLS-TE LSPs across specific components of a composite link. 72 One way to do this is to advertise both the composite and components 73 as links in the TE database using the mechanisms defined in 74 [RFC3630]. In order to do this, a relationship must be established 75 between a given composite link and its components. This document 76 provides a new top-level TLV to be advertised in the Traffic 77 Engineering LSA. This new TLV is necessary in order to ensure that 78 bandwidth reserved from a given component link is properly accounted 79 for at the component level, and to do so in a backward-compatible 80 manner. Along with this new top-level TLV, we define a sub-TLV to 81 identify the composite link to which a component belongs. 83 2. Component TLV 85 The component TLV (C-TLV) is very similar to the Link TLV [RFC3630]. 86 The C-TLV defines a component link which belongs to a single 87 composite. A C-TLV MUST carry a CC-sTLV (see Section 2.3). A C-TLV 88 MUST NOT carry a Link Type or Link ID sub-TLV (see Section 2.1 for 89 the rationale). A C-TLV MUST otherwise follow all rules for sub-TLVs 90 that pertain to a Link TLV. In particular, all sub-TLVs which are 91 defined for use in a Link TLV are usable in the C-TLV. 93 2.1. Removing link type and link ID sub-TLVs from C-TLV 95 RFC3630 requires that a Link TLV carry both a Link Type and Link ID 96 sub-TLV. The Link Type describes the link as either p2p or 97 multiaccess. Composite and component links are p2p by definition, 98 and thus explicating this is unnecessary. For p2p links the Link ID 99 of the component is the Router ID of the neighbor at the other end; 100 as all components of a composite terminate on the same node, the Link 101 ID of the parent composite is inherited by the component link and 102 thus does not need to be specified. 104 2.2. Inheritance between Link TLV and C-TLV 106 A component may or may not carry all of the sub-TLVs that its parent 107 Link TLV does. For example, a component may share an administrative 108 group with its parent composite and thus can inherit the 109 administrative group from the parent, or might not have an IP 110 address. This section specifies inheritance rules used to determine 111 the value of various sub-TLVs inside the component link based on 112 their status in the parent composite: 114 Link type: per section 3.1, a C-TLV MUST NOT carry a Link Type sub- 115 TLV. 117 Link ID: per section 3.1, a C-TLV MUST NOT carry a Link ID sub-TLV. 119 Local and remote interface IP addresses: if these are not specified 120 in the parent composite link then they MAY be omitted from the 121 component. Practically speaking it is not useful to advertise a link 122 without some sort of unique identifier, so it is expected that most 123 implementations will advertise a parent link with some sort of 124 identifier, either local/remote IP addresses or some other unique 125 identifier such as Link Local and Remote Identifiers [RFC4203]. If a 126 parent composite link carries a unique identifier a component link 127 SHOULD also carry a unique identifier. However, there is no 128 requirement that the types match; a composite MAY advertise a Link 129 Local/Remote Identifier while the component advertises local/remote 130 IP addresses, or vice versa. Deciding on the identifier used for a 131 component link is outside the scope of this document and is 132 implementation-specific. 134 Traffic engineering metric: if this is not included in the C-TLV, it 135 is inherited from the parent 137 Maximum bandwidth: if this is specified in the parent composite it 138 MUST be explicitly specified (that is, not inherited) in the 139 component link. If it is not specified in the parent it MAY be 140 specified in the component. 142 Maximum reservable bandwidth: if this is specified in the parent 143 composite it MUST be explicitly specified (that is, not inherited) in 144 the component link. If it is not specified in the parent it MAY be 145 specified in the component. 147 Unreserved bandwidth: if this is specified in the parent composite it 148 MUST be explicitly specified (that is, not inherited) in the 149 component link. If it is not specified in the parent it MAY be 150 specified in the component. 152 Administrative group: if this is not included in the C-TLV, it is 153 inherited from the parent. 155 Other sub-TLV types SHOULD follow a similar approach to the sub-TLVs 156 listed here. In general, the idea is that a component link should 157 advertise any properties which are unique to that component and 158 should inherit from the parent composite any properties which are 159 shared between the parent composite and the component. 161 2.3. Component/composite ID sub-TLV 163 The association between a composite link and its components is made 164 using the component/composite ID sub-TLV (CC-ID sTLV). The CC-ID 165 sTLV is a sub-TLV carried in both the Link TLV of the OSPF Opaque TE 166 LSA and the C-TLV. It is a 32-bit field (4 octets) defined as 167 follows: 169 0 1 2 3 170 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 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 | Composite ID | 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 The Composite ID is a 32-bit value assigned to a composite on a given 176 system. The Composite ID MUST be unique to the advertising router. 177 The method of assignment of the Composite ID is out of the scope of 178 this document. 180 When carried in a Link TLV, the Composite ID identifies that link as 181 a composite link. When carried in a C-TLV, the Composite ID 182 identifies the composite link of which the given component is a 183 member. This association is necessary so that implementations which 184 are component-aware can decide whether to establish an LSP over a 185 composite or one of its components. All components of a given 186 composite MUST have an CC-ID sTLV, and the Composite ID of the 187 composite and all of its components MUST match. A link (component or 188 composite) MUST contain only one CC-ID sTLV. A node MAY advertise a 189 composite link with no components, but if a node advertises any 190 component links the node MUST also advertise an associated composite 191 link. 193 The CC-ID sTLV needs a number assigned to it by IANA. For now, the 194 sub-TLV number is TBD. 196 3. IANA Considerations 198 tbd 200 4. Security Considerations 202 There are no security considerations when using this sub-TLV; it is a 203 link property like any other, and provides no more and no less 204 exposure to security issues than the other sub-TLVs defined in 205 [RFC3630]. 207 5. Acknowledgements 209 Les Ginsberg, Padma Pilay-Esnault, Stefano Previdi, Tony Li, Abhay 210 Roy 212 6. Normative References 214 [I-D.ietf-rtgwg-cl-requirement] 215 Villamizar, C., McDysan, D., Ning, S., Malis, A., and L. 216 Yong, "Requirements for MPLS Over a Composite Link", 217 draft-ietf-rtgwg-cl-requirement-04 (work in progress), 218 March 2011. 220 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 221 Requirement Levels", BCP 14, RFC 2119, March 1997. 223 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 224 (TE) Extensions to OSPF Version 2", RFC 3630, 225 September 2003. 227 [RFC4203] Kompella, K. and Y. Rekhter, "OSPF Extensions in Support 228 of Generalized Multi-Protocol Label Switching (GMPLS)", 229 RFC 4203, October 2005. 231 Authors' Addresses 233 Eric Osborne 234 Cisco Systems, Inc. 235 300 Beaver Brook Road 236 Boxborough, Massachusetts 01719 238 Phone: 239 Fax: 240 Email: eosborne@cisco.com 241 URI: 243 Peter Psenak 244 Cisco Systems. 245 Mlynske Nivy 43 246 Bratislava, 821 09 247 Slovakia 249 Phone: 250 Fax: 251 Email: eosborne@cisco.com 252 URI: