idnits 2.17.1 draft-xu-isis-global-label-sid-adv-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 (December 25, 2013) is 3774 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) == Outdated reference: A later version (-05) exists of draft-previdi-isis-segment-routing-extensions-04 ** Obsolete normative reference: RFC 4971 (Obsoleted by RFC 7981) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group X. Xu 3 Internet-Draft M. Chen 4 Intended status: Standards Track Huawei 5 Expires: June 28, 2014 December 25, 2013 7 Advertising Global Labels or SIDs Using IS-IS 8 draft-xu-isis-global-label-sid-adv-00 10 Abstract 12 Segment Routing (SR) is a new MPLS paradigm in which each SR-capable 13 router is required to advertise global MPLS labels or Segment IDs 14 (SID ) for its attached prefixes by using link-state IGPs, e.g., IS- 15 IS. One major challenge associated with such global MPLS label or 16 SID advertisement mechanism is how to avoid a given global MPLS label 17 or SID from being allocated by different routers to different 18 prefixes. Although such global label or SID allocation collision 19 problem can be addressed through manual allocation , it is error- 20 prone and nonautomatic therefore may not be suitable in large-scale 21 SR network environments. This document proposes an alternative 22 approach for allocating and advertising global MPLS labels or SIDs 23 via IS-IS so as to eliminate the potential risk of label allocation 24 collision. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on June 28, 2014. 43 Copyright Notice 45 Copyright (c) 2013 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 3. Advertising Label Bindings for Prefixes using IS-IS . . . . . 3 64 4. Advertising SID Bindings for Prefixes using IS-IS . . . . . . 4 65 5. Requesting Label Bindings for Prefixes using IS-IS . . . . . 5 66 6. Requesting SID Bindings for Prefixes using IS-IS . . . . . . 5 67 7. Mapping Server Redundancy . . . . . . . . . . . . . . . . . . 6 68 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 69 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 70 10. Security Considerations . . . . . . . . . . . . . . . . . . . 7 71 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 72 11.1. Normative References . . . . . . . . . . . . . . . . . . 7 73 11.2. Informative References . . . . . . . . . . . . . . . . . 7 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 76 1. Introduction 78 Segment Routing (SR) [I-D.filsfils-rtgwg-segment-routing] is a new 79 MPLS paradigm in which each SR-capable router is required to 80 advertise global MPLS labels or Segment IDs (SID) for its attached 81 prefixes by using link-state IGPs, e.g., IS- 82 IS[I-D.previdi-isis-segment-routing-extensions] . One major challenge 83 associated with such global MPLS label or SID advertisement mechanism 84 is how to avoid a given global MPLS label or SID from being allocated 85 by different routers to different prefixes. Although such global 86 label or SID allocation collision problem can be addressed through 87 manual allocation , it is error-prone and nonautomatic therefore may 88 not be suitable in large-scale SR network environments. 90 This document proposes an alternative approach for allocating and 91 advertising global MPLS labels or SIDs via IS-IS so as to eliminate 92 the potential risk of label allocation collision. The basic idea of 93 this approach is to allow a particular IGP router to allocate global 94 MPLS labels or SIDs for those prefixes attached to each SR-capable 95 router and meanwhile advertise the corresponding label or SID 96 bindings in the IGP domain scope. That particular IGP rouer is 97 therefore refered to as a mapping server. As for how the mapping 98 server know which prefixes need to be allocated with global labels or 99 SIDs, it can be achieved either by configuration on the mapping 100 server or by advertisement from SR-capable routers. In the multi- 101 level scenario where route summarization between levels is enabled, 102 the IP longest-match algorithm SHOULD be used by SR-capable routers 103 when processing label or SID bindings advertised by the mapping 104 server, just as the mechanism defined in [RFC5283] . 106 1.1. Requirements Language 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 110 document are to be interpreted as described in RFC 2119 [RFC2119]. 112 2. Terminology 114 This memo makes use of the terms defined in 115 [I-D.filsfils-rtgwg-segment-routing] and [RFC4971]. 117 3. Advertising Label Bindings for Prefixes using IS-IS 119 A mapping server could uses one or more of the following TLVs to 120 advertise global labels for those prefixes which need to be allocated 121 with global labels. 123 o TLV-135 (IPv4) [RFC5305] 125 o TLV-235 (MT-IPv4) [RFC5120] 127 o TLV-236 (IPv6) [RFC5308] 129 o TLV-237 (MT-IPv6) [RFC5120] 131 A Label Binding Sub-TLV (TBD) as shown below is associated with a 132 prefix which is contained in one of the above TLVs: 134 0 1 2 3 135 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 136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 137 | Type=TBD | Length | 138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 139 |P| Reserved | MPLS Label (20 bit) | 140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 142 Type: TBD 143 Length: 4 145 P-Flag: if set, the penultimate hop router MUST perform PHP action 146 on the allocated MPLS label. For a given prefix, the P-Flag in 147 the Label Binding Sub-TLV MUST be set to the same value as that of 148 the P-Flag in the Label Request Sub-TLV if a label request message 149 (See Section 5 of this document) for that prefix is received by 150 the mapping server. 152 MPLS Label: a global label for the prefix which is carried in the 153 TLV containing this sub-TLV. 155 Since the mapping server uses these TLVs for label binding 156 advertisement purpose other than building the normal IP routing 157 table, the Metric field MUST be set to a value larger than 158 MAX_PATH_METRIC (i.e., 0xFE000000) according to the following 159 specification as defined in [RFC5305] "...If a prefix is advertised 160 with a metric larger then MAX_PATH_METRIC (0xFE000000, see paragraph 161 3.0), this prefix MUST NOT be considered during the normal SPF 162 computation. This allows advertisement of a prefix for purposes 163 other than building the normal IP routing table...". In addition, 164 when propagating those TLVs across levels, the Label Binding Sub-TLVs 165 contained in them MUST be preserved. 167 4. Advertising SID Bindings for Prefixes using IS-IS 169 A mapping server could uses one or more of the Extended IP 170 Reachability TLVs (i.e., TLV-135, TLV-235, TLV-236 and TLV-237) to 171 advertise SIDs for those prefixes which need to be allocated with 172 SIDs. 174 A SID Binding Sub-TLV (TBD) as shown below is associated with a 175 prefix which is contained in one of the above TLVs: 177 0 1 2 3 178 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 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 | Type=TBD | Length | 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 | SID | 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 Type: TBD 187 Length: 4 189 SID: a SID for the prefix which is carried in the TLV containing 190 this sub-TLV. 192 Since the mapping server uses these TLVs for label binding 193 advertisement purpose other than building the normal IP routing 194 table, the Metric field MUST be set to a value larger than 195 MAX_PATH_METRIC (i.e., 0xFE000000). In addition, when propagating 196 those TLVs across levels, the SID Binding Sub-TLVs contained in them 197 MUST be preserved. 199 5. Requesting Label Bindings for Prefixes using IS-IS 201 When advertising IP reachability information by using one of the 202 Extended IP Reachability TLVs (i.e., TLV-135, TLV-235, TLV-236 and 203 TLV-237), SR-capable IS-IS routers SHOULD mark those attached 204 prefixes which need to be allocated with global labels by associating 205 each of these prefixes with a Label Request sub-TLV (type code=TBD) 206 as shown below. In addition, when propagating those TLVs across 207 levels, the Label Request Sub-TLVs contained in them MUST be 208 preserved. 210 0 1 2 3 211 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 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 | Type=TBD | Length | 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 |P| Reserved | 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 Type: TBD 220 Length: 4 222 P-Flag: if set, the penultimate hop router MUST perform PHP action 223 on the required label. 225 In the multi-level scenario where route summarization between levels 226 is required, separate Extended IP Reachability TLVs other than those 227 for IP reachability advertisement purpose SHOULD be used for label 228 binding request purpose. Since these separate TLVs are not used for 229 the purpose of building the normal IP routing table, the Metric field 230 MUST be set to a value larger than MAX_PATH_METRIC (i.e., 231 0xFE000000). In addition, when propagating those TLVs across levels, 232 the Label Request Sub-TLVs contained in them MUST be preserved. 234 6. Requesting SID Bindings for Prefixes using IS-IS 236 When advertising IP reachability information by using one of the 237 Extended IP Reachability TLVs (i.e., TLV-135, TLV-235, TLV-236 and 238 TLV-237), SR-capable IS-IS routers SHOULD mark those attached 239 prefixes which need to be allocated with SIDs by associating each of 240 these prefixes with a SID Request sub-TLV (Type Code=TBD and 241 Length=0) 243 In the multi-level scenario where route summarization between levels 244 is required, separate Extended IP Reachability TLVs other than those 245 for IP reachability advertisement purpose SHOULD be used for SID 246 binding request purpose. Since these separate TLVs are not used for 247 the purpose of building the normal IP routing table, the Metric field 248 MUST be set to a value larger than MAX_PATH_METRIC (i.e., 249 0xFE000000). In addition, when propagating those TLVs across levels, 250 the SID Request Sub-TLVs contained in them MUST be preserved. 252 7. Mapping Server Redundancy 254 For redundancy purpose, more than one router could be configured as 255 candidates for mapping servers. Each candidate for mapping servers 256 SHOULD advertise its capability of being a mapping servers by using 257 IS-IS Router Capability TLV. The one with the highest priority 258 SHOULD be elected as the primary mapping server which is eligible to 259 allocate and advertise global labels or SIDs for prefixes on behalf 260 of SR-capable routers. The comparison of IS-IS System ID breaks the 261 tie between two or more candidates with the same highest priority. 262 Meanwhile, the one with the second highest priority SHOULD be elected 263 as a backup mapping server. This backup mapping server SHOULD 264 advertise the same label bindings as those advertised by the primary 265 mapping server. In this way, the unnecessary changes to the data 266 plane (i.e., MPLS forwarding table) of SR-capable routers can be 267 avoided in the event of mapping server failover. 269 Each candidate mapping server SHOULD advertise its capability of 270 being a mapping server and the corresponding priority for mapping 271 server election by attaching a Mapping Server Capability Sub-TLV 272 (type code=TBD) shown as below to an IS-IS Router Capability TLV 273 [RFC4971] with the S flag set (with domain-wide flooding scope). 275 0 1 2 3 276 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 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 | Type=TBD | Length | Priority | 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 Type: TBD 283 Length: 1 285 Priority: the priority for mapping server election. 287 8. Acknowledgements 289 The authors would like to thank . 291 9. IANA Considerations 293 TBD. 295 10. Security Considerations 297 This document does not introduce any new security considerations. 299 11. References 301 11.1. Normative References 303 [I-D.previdi-isis-segment-routing-extensions] 304 Previdi, S., Filsfils, C., Bashandy, A., Gredler, H., and 305 S. Litkowski, "IS-IS Extensions for Segment Routing", 306 draft-previdi-isis-segment-routing-extensions-04 (work in 307 progress), October 2013. 309 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 310 Requirement Levels", BCP 14, RFC 2119, March 1997. 312 [RFC4971] Vasseur, JP., Shen, N., and R. Aggarwal, "Intermediate 313 System to Intermediate System (IS-IS) Extensions for 314 Advertising Router Information", RFC 4971, July 2007. 316 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 317 Topology (MT) Routing in Intermediate System to 318 Intermediate Systems (IS-ISs)", RFC 5120, February 2008. 320 [RFC5283] Decraene, B., Le Roux, JL., and I. Minei, "LDP Extension 321 for Inter-Area Label Switched Paths (LSPs)", RFC 5283, 322 July 2008. 324 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 325 Engineering", RFC 5305, October 2008. 327 [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, October 328 2008. 330 11.2. Informative References 332 [I-D.filsfils-rtgwg-segment-routing] 333 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 334 Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., 335 Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe, 336 "Segment Routing Architecture", draft-filsfils-rtgwg- 337 segment-routing-01 (work in progress), October 2013. 339 Authors' Addresses 341 Xiaohu Xu 342 Huawei 344 Email: xuxiaohu@huawei.com 346 Mach Chen 347 Huawei 349 Email: mach.chen@huawei.com