idnits 2.17.1 draft-osborne-mpls-extended-admin-groups-03.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 (January 9, 2014) is 3760 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 2702 Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). 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 4 Intended status: Standards Track January 9, 2014 5 Expires: July 13, 2014 7 Extended Administrative Groups in MPLS-TE 8 draft-osborne-mpls-extended-admin-groups-03 10 Abstract 12 This document provides additional administrative groups (sometimes 13 referred to as "link colors") to the IGP extensions for MPLS-TE. 15 Requirements Language 17 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 18 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 19 document are to be interpreted as described in RFC 2119 [RFC2119]. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on July 13, 2014. 38 Copyright Notice 40 Copyright (c) 2014 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 1.1. Do we need more than 32 bits? . . . . . . . . . . . . . . 2 57 2. Extended Administrative Groups sub-TLV . . . . . . . . . . . 3 58 2.1. Packet Format . . . . . . . . . . . . . . . . . . . . . . 3 59 2.2. Admin group numbering . . . . . . . . . . . . . . . . . . 4 60 2.3. Backward compatability . . . . . . . . . . . . . . . . . 4 61 2.3.1. AG and EAG coexistence . . . . . . . . . . . . . . . 4 62 2.3.2. Desire for unadvertised EAG bits . . . . . . . . . . 4 63 3. Signaling Extended Administrative Groups in RSVP . . . . . . 5 64 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 65 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 66 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 67 7. Normative References . . . . . . . . . . . . . . . . . . . . 6 68 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 70 1. Introduction 72 MPLS-TE advertises 32 administrative groups (commonly referred to as 73 "colors" or "link colors") using the Administrative Group sub-TLV of 74 the Link TLV. This is defined for OSPFv2 [RFC3630], OSPFv3 75 [RFC5329]and ISIS [RFC5305]. 77 This document adds a sub-TLV to the IGP TE extensions, "Extended 78 Administrative Group". This sub-TLV provides for additional 79 administrative groups (link colors) beyond the current limit of 32. 81 1.1. Do we need more than 32 bits? 83 The IGP extensions to support MPLS-TE (RFCs 3630 and 5305) define a 84 link TLV known as Administrative Group (AG) with a limit of 32 AGs 85 per link. This property comes from section 6.2 of RFC 2702 86 [RFC2702]. RFCs 3630 and 5305 describe the mechanics of the TLV; the 87 actual definition of the field comes from RFC 2702. 89 Networks have grown over time, and MPLS-TE has grown right along with 90 them. Implementing network-wide policies such as the ones listed in 91 RFC 2702 section 6.2 with only 32 bits gives the operator only five 92 bits per policy with two bits left over. This can be quite 93 constraining - AGs are a bit mask, so five bits does not mean 32 94 possible values, it means 5. Running a country-wide or worldwide 95 MPLS-TE network with only five possible values for each case is 96 clearly too constraining. 98 Even if an operator wishes to use AGs to implement only a single 99 policy it is possible to run out of bit values. One such use case is 100 #5, using AGs to constrain traffic within specific topological 101 regions of the network. A large network may well have far more than 102 32 geographic regions. One particular operator uses AGs to flag 103 network regions down to the metro scale, e.g. Seattle, San Francisco, 104 Dallas, Chicago, St. Louis, etc. MPLS-TE tunnels are then specified 105 with affinities to include or exclude specific metro regions in their 106 path calculation. It is clear that 32 may not be enough even for a 107 US-based network, nevermind a worldwide network. 109 There may be some opportunity for color reuse; that is, bit 0x8 may 110 mean 'Seattle' and 'Prague' and 'Singapore' depending on the 111 geography in which it is used. In practice, coordinating this reuse 112 is fraught with peril and the reuse effectively becomes the limiting 113 factor in MPLS-TE deployment. With this example it is not possible 114 to build an LSP which avoids Seattle while including Prague, as it is 115 the same AG value. 117 This document provides Extended Administrative Groups (EAGs). The 118 number of EAGs has no fixed limit, it is constrained only by 119 protocol-specific restrictions such as LSA or MTU size. While an 120 operator may one day need to go beyond these protocol-specific 121 restrictions, allow for an arbitrary number of EAGs should easily 122 provide the operator with hundreds or thousands of bit values, thus 123 no longer making the number of AGs an impediment to network growth. 125 2. Extended Administrative Groups sub-TLV 127 The Extended Administrative Groups sub-TLV is used in addition to the 128 Administrative Groups when a node wishes to advertise more than 32 129 colors for a link. The EAG sub-TLV is optional. 131 This document uses the term 'colors' as a shorthand to refer to 132 particular bits with an AG or EAG. The examples in this document use 133 'red' to represent the least significant bit in the AG (red == 0x1), 134 'blue' to represent the second bit (blue == 0x2). To say that a link 135 has a given color or that the specified color is set on the link is 136 to say that the corresponding bit or bits in the link's AG are set to 137 1. 139 2.1. Packet Format 141 The format of the Extended Administrative Groups sub-TLV is the same 142 for both OSPF and ISIS: 144 0 1 2 3 145 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 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 147 | Extended Admin Group | 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 149 | ........... | 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 151 | Extended Admin Group | 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 The Type of the sub-TLV for OSPF and ISIS is TBD. The Length is the 155 size of the Extended Admin Group (EAG) value in bytes. The EAG may 156 be of any length, but MUST be a multiple of 4 bytes. The only limits 157 on EAG size are those which are imposed by protocol-specific or 158 media-specific constraints (e.g. max packet length). 160 2.2. Admin group numbering 162 By convention, the existing Administrative Group TLVs are numbered 0 163 (LSB) to 31 (MSB). The EAG values are a superset of AG. That is, 164 bits 0-31 in the EAG have the same meaning and MUST have the same 165 values as an AG flooded for the same link. 167 2.3. Backward compatability 169 There are two things to consider for backward compatibility with 170 existing AG implementations - how do AG and EAG coexist, and what 171 happens if a node has matching criteria for unadvertised EAG bits? 173 2.3.1. AG and EAG coexistence 175 If a node advertises EAG it MAY also advertise AG. If a node 176 advertises both AG and EAG then the first 32 bits of the EAG MUST be 177 identical to the advertised AG. If the AG and EAG advertised for a 178 link differ, the EAG MUST take priority. This allows nodes which do 179 not support EAG to obtain some link color information from the 180 network, but also allow for an eventual migration away from AG. 182 2.3.2. Desire for unadvertised EAG bits 184 The existing AG sub-TLV is optional; thus a node may be configured 185 with a preference to include red or exclude blue, and be faced with a 186 link that is not advertising a value for either blue or red. What 187 does an implementation do in this case? It shouldn't assume that red 188 is set, but it is also arguably incorrect to assume that red is NOT 189 set, as a bit must first exist before it can be set to 0. 191 Practically speaking this has not been an issue for deployments, as 192 many implementations always advertise the AG bits, often with a 193 default value of 0x00000000. However, this issue may be of more 194 concern once EAGs are added to the network. EAGs may exist on some 195 nodes but not others, and the EAG length may be longer for some links 196 than for others. 198 Each implementation is free to choose its own method for handling 199 this question. However, to encourage maximum interoperability an 200 implementation SHOULD treat specified but unadvertised EAG bits as if 201 they are set to 0. A node MAY provide other (configurable) 202 strategies for handling this case. 204 3. Signaling Extended Administrative Groups in RSVP 206 RSVP provides the ability to signal link affinity via the 207 SESSION_ATTRIBUTE object with C-Type 1 in[RFC3209]. At first glance 208 it seems useful to extend RSVP to provide a session attribute which 209 can signal extended affinities. As it turns out, there are several 210 non-trivial things to tackle were one to provide such an extension. 211 In addition, an informal survey of the field, both MPLS-TE 212 implementors and network operators, suggests that the ability to 213 signal affinity bits in a SESSION_ATTRIBUTE object is not widely 214 deployed today. It is thus likely that signaling EAG in a 215 SESSION_ATTRIBUTE would see virtually no deployment. As this work 216 would be both non-trivial and aimed at a solution unlikely to be 217 deployed, it is not addressed in this document. 219 This document does not preclude solving this problem in the future 220 should it be necessary. 222 4. Security Considerations 224 This extension adds no new security considerations. 226 5. IANA Considerations 228 This document requests a sub-TLV allocation in both OSPF and ISIS. 230 6. Acknowledgements 232 Thanks to Santiago Alvarez, Rohit Gupta, Liem Nguyen, Tarek Saad, and 233 Robert Sawaya for their review and comments. 235 7. Normative References 237 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 238 Requirement Levels", BCP 14, RFC 2119, March 1997. 240 [RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. 241 McManus, "Requirements for Traffic Engineering Over MPLS", 242 RFC 2702, September 1999. 244 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 245 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 246 Tunnels", RFC 3209, December 2001. 248 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 249 (TE) Extensions to OSPF Version 2", RFC 3630, September 250 2003. 252 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 253 Engineering", RFC 5305, October 2008. 255 [RFC5329] Ishiguro, K., Manral, V., Davey, A., and A. Lindem, 256 "Traffic Engineering Extensions to OSPF Version 3", RFC 257 5329, September 2008. 259 Author's Address 261 Eric Osborne 262 Cisco Systems 264 Email: eosborne@cisco.com