idnits 2.17.1 draft-ietf-mpls-extended-admin-group-07.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 (May 29, 2014) is 3612 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 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 4 Intended status: Standards Track May 29, 2014 5 Expires: November 30, 2014 7 Extended Administrative Groups in MPLS-TE 8 draft-ietf-mpls-extended-admin-group-07 10 Abstract 12 MPLS-TE advertises 32 administrative groups (commonly referred to as 13 "colors" or "link colors") using the Administrative Group sub-TLV. 14 This is defined for OSPFv2 (RFC3630), OSPFv3 (RFC5329) and ISIS 15 (RFC5305). 17 This document adds a sub-TLV to the IGP TE extensions, "Extended 18 Administrative Group". This sub-TLV provides for additional 19 administrative groups (link colors) beyond the current limit of 32. 21 Requirements Language 23 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 24 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 25 document are to be interpreted as described in RFC 2119 [RFC2119]. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on November 30, 2014. 44 Copyright Notice 46 Copyright (c) 2014 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Extended Administrative Groups sub-TLV . . . . . . . . . . . 3 63 2.1. Packet Format . . . . . . . . . . . . . . . . . . . . . . 4 64 2.2. Admin group numbering . . . . . . . . . . . . . . . . . . 4 65 2.3. Backward compatability . . . . . . . . . . . . . . . . . 4 66 2.3.1. AG and EAG coexistence . . . . . . . . . . . . . . . 4 67 2.3.2. Desire for unadvertised EAG bits . . . . . . . . . . 5 68 3. Security Considerations . . . . . . . . . . . . . . . . . . . 5 69 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 70 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 71 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 72 6.1. Normative References . . . . . . . . . . . . . . . . . . 6 73 6.2. Informative References . . . . . . . . . . . . . . . . . 7 74 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 76 1. Introduction 78 Do we need more than 32 bits? 80 The IGP extensions to support MPLS-TE (RFCs 3630 [RFC3630] and 5305 81 [RFC5305]) define a link TLV known as Administrative Group (AG) with 82 a limit of 32 AGs per link. The concept of Administrative Groups 83 comes from section 6.2 of RFC 2702 [RFC2702], which calls them 84 Resource Classes. RFCs 3630 [RFC3630] and 5305 [RFC5305] describe 85 the mechanics of the TLV and use the term Administrative Groups 86 (sometimes abbreviated herein as AGs), as does this document. 88 Networks have grown over time, and MPLS-TE has grown right along with 89 them. Administrative Groups are advertised as a fixed-length 32-bit 90 bitmask. This can be quite constraining, as it is possible to run 91 out of values rather quickly. One such use case is #5 in Section 6.2 92 of RFC 2702 [RFC2702], using AGs to constrain traffic within specific 93 topological regions of the network. A large network may well have 94 far more than 32 geographic regions. One particular operator builds 95 their network along the lines of this use case, using AGs to flag 96 network regions down to the metro scale, e.g. Seattle, San 97 Francisco, Dallas, Chicago, St. Louis, etc. MPLS-TE tunnels are then 98 specified with affinities to include or exclude specific metro 99 regions in their path calculation. Each metro region is given its 100 own bit in the AG bitmask. This means that 32 bits can only 101 (cleanly) represent 32 metro areas. It should be obvious that 32 may 102 not be enough even for a US-based network, nevermind a worldwide 103 network. 105 There may be some opportunity for color reuse; that is, bit 0x8 may 106 mean 'Seattle' or 'Prague' or 'Singapore' depending on the geography 107 in which it is used. In practice, coordinating this reuse is fraught 108 with peril and the reuse effectively becomes the limiting factor in 109 MPLS-TE deployment. With this example it is not possible to build an 110 LSP which avoids Seattle while including Prague, as it is the same AG 111 value. 113 This document provides Extended Administrative Groups (EAGs). The 114 number of EAGs has no fixed limit, it is constrained only by 115 protocol-specific restrictions such as LSA or MTU size. While an 116 operator may one day need to go beyond these protocol-specific 117 restrictions, allowing for an arbitrary number of EAGs should easily 118 provide the operator with hundreds or thousands of bit values, thus 119 no longer making the number of AGs an impediment to network growth. 121 EAG's intended use case is within a single domain. As such, this 122 document provides no support for signaling EAG. It provides no 123 analog to either the SESSION_ATTRIBUTE of C-Type 1 defined in 124 [RFC3209], nor the LSPA object of the Path Computation Element 125 Communication Protocol (PCEP) defined in [RFC5440]. Since this 126 specification provides no way of signaling an LSP's path requirements 127 in reference to the EAG, such constraints may only be applied at the 128 ingress. 130 2. Extended Administrative Groups sub-TLV 132 This document defines the Extended Administrative Group (EAG) sub-TLV 133 for both OSPF [RFC3630] and ISIS [RFC5305]. The EAG sub-TLV is used 134 in addition to the Administrative Groups when an operator wants to 135 make more than 32 colors available for advertisement in a network. 136 The EAG sub-TLV is optional. Coexistence of EAG and AG TLVs is 137 covered in Section 2.3.1 of this document. 139 This document uses the term 'colors' as a shorthand to refer to 140 particular bits with an AG or EAG. The examples in this document use 141 'red' to represent the least significant bit in the AG (red == 0x1), 142 'blue' to represent the second bit (blue == 0x2). To say that a link 143 has a given color or that the specified color is set on the link is 144 to say that the corresponding bit or bits in the link's AG are set to 145 1. 147 2.1. Packet Format 149 The format of the Extended Administrative Groups sub-TLV is the same 150 for both OSPF and ISIS: 152 0 1 2 3 153 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 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 | Extended Admin Group | 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 | ........... | 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 | Extended Admin Group | 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 The Type of the sub-TLV for OSPF and ISIS is TBD. The Length is the 163 size of the Extended Admin Group (EAG) value in bytes. The EAG may 164 be of any non-zero length, but MUST be a multiple of 4 bytes. The 165 only limits on EAG size are those which are imposed by protocol- 166 specific or media-specific constraints (e.g. max packet length). 168 2.2. Admin group numbering 170 By convention, the existing Administrative Group sub-TLVs are 171 numbered 0 (LSB) to 31 (MSB). The EAG values are a superset of AG. 172 That is, bits 0-31 in the EAG have the same meaning and MUST have the 173 same values as an AG flooded for the same link. If an EAG's length 174 is more than 4 bytes, numbering for these additional bytes picks up 175 where the previous byte left off. For example, the least significant 176 bit in the 5th byte of an 8-byte EAG is referred to as bit 32. 178 2.3. Backward compatability 180 There are two questions to consider for backward compatibility with 181 existing AG implementations - how do AG and EAG coexist, and what 182 happens if a node has matching criteria for unadvertised EAG bits? 184 2.3.1. AG and EAG coexistence 186 If a node advertises EAG it MAY also advertise AG. 188 If a node advertises both AG and EAG then the first 32 bits of the 189 EAG MUST be identical to the advertised AG. 191 If both an AG and EAG are present, a receiving node MUST use the AG 192 as the first 32 bits (0-31) of administrative color and use the EAG 193 for bits 32 and higher if present. 195 A receiving node that notices that the AG differs from the first 32 196 bits of the EAG, SHOULD report this mismatch to the operator. 198 This process allows nodes which do not support EAG to obtain some 199 link color information from the network, but also allow for an 200 eventual migration away from AG. 202 2.3.2. Desire for unadvertised EAG bits 204 The existing AG sub-TLV is optional; thus a node may be configured 205 with a preference to include red or exclude blue, and be faced with a 206 link that is not advertising a value for either blue or red. What 207 does an implementation do in this case? It shouldn't assume that red 208 is set, but it is also arguably incorrect to assume that red is NOT 209 set, as a bit must first exist before it can be set to 0. 211 Practically speaking this has not been an issue for deployments, as 212 many implementations always advertise the AG bits, often with a 213 default value of 0x00000000. However, this issue may be of more 214 concern once EAGs are added to the network. EAGs may exist on some 215 nodes but not others, and the EAG length may be longer for some links 216 than for others. 218 To allow for maximum interoperability, an implementation SHOULD treat 219 desired but unadvertised EAG bits as if they were set to 0. Consider 220 the case where a node wants to only use links where the 127th bit of 221 an EAG is set to 1. If a link is only advertising 64 EAG bits, the 222 setting of the 127th EAG bit is not known - that is, it is neither 223 explicitly 0 nor 1. The node that wants the 127th EAG bit to be 1 224 will not use this link when implementing the recommended behavior, as 225 the assumption is than the unadvertised 127th bit is set to 0. 227 That said, each implementation makes its own choices based on 228 necessary constraints, and there might be reasons to provide other 229 strategies for handling this case. A strategy that deviates from the 230 behavior this document recommends SHOULD be configurable to use the 231 recommended behavior, in order to provide maximum interoperability. 233 3. Security Considerations 235 This extension adds no new security considerations. 237 4. IANA Considerations 239 This document requests a sub-TLV allocation in both OSPF and ISIS. 241 For OSPF, the name space is "Types for sub-TLVs of TE Link TLV (Value 242 2)" in the "Open Shortest Path First (OSPF) Traffic Engineering 243 TLVs". 245 For ISIS, it is "Sub-TLVs for TLV 22, 141, and 222" in the "IS-IS TLV 246 Codepoints" registry. For IS-IS the value should be marked 'y' for 247 Sub-TLVs 22, 141 and 222; this is identical to the allocation for the 248 Administrative Group sub-TLV (value 3). 250 In both registries the first free value should be assigned. As of 251 this writing, that's 26 in the OSPF registry and 14 in the IS-IS 252 registry. The Sub-TLV should be called "Extended Administrative 253 Group". 255 5. Acknowledgements 257 Thanks to Santiago Alvarez, Rohit Gupta, Liem Nguyen, Tarek Saad, 258 Robert Sawaya, Andy Malis, Les Ginsberg and Adrian Farrel for their 259 review and comments. 261 6. References 263 6.1. Normative References 265 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 266 Requirement Levels", BCP 14, RFC 2119, March 1997. 268 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 269 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 270 Tunnels", RFC 3209, December 2001. 272 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 273 (TE) Extensions to OSPF Version 2", RFC 3630, September 274 2003. 276 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 277 Engineering", RFC 5305, October 2008. 279 [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element 280 (PCE) Communication Protocol (PCEP)", RFC 5440, March 281 2009. 283 6.2. Informative References 285 [RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. 286 McManus, "Requirements for Traffic Engineering Over MPLS", 287 RFC 2702, September 1999. 289 Author's Address 291 Eric Osborne 293 Email: eric.osborne@notcom.com