idnits 2.17.1 draft-xu-ospf-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 (January 21, 2014) is 3749 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) == Unused Reference: 'RFC2328' is defined on line 297, but no explicit reference was found in the text == Outdated reference: A later version (-05) exists of draft-psenak-ospf-segment-routing-extensions-03 ** Obsolete normative reference: RFC 4970 (Obsoleted by RFC 7770) Summary: 1 error (**), 0 flaws (~~), 3 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: July 25, 2014 January 21, 2014 7 Advertising Global Labels or SIDs Using OSPF 8 draft-xu-ospf-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., OSPF. 15 One major challenge associated with such global MPLS label or SID 16 advertisement mechanism is how to avoid a given global MPLS label or 17 SID from being allocated by different routers to different prefixes. 18 Although such global label or SID allocation collision problem can be 19 addressed through manual allocation , it is error-prone and 20 nonautomatic therefore may not be suitable in large-scale SR network 21 environments. This document proposes an alternative approach for 22 allocating and advertising global MPLS labels or SIDs via OSPF so as 23 to eliminate the potential risk of label allocation collision. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on July 25, 2014. 42 Copyright Notice 44 Copyright (c) 2014 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. Advertising Label Bindings for Prefixes . . . . . . . . . . . 3 63 4. Advertising SID Bindings for Prefixes . . . . . . . . . . . . 4 64 5. Requesting Label Bindings for Prefixes . . . . . . . . . . . 5 65 6. Requesting SID Bindings for Prefixes . . . . . . . . . . . . 5 66 7. Advertising Mapping Server Capability . . . . . . . . . . . . 5 67 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 68 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 69 10. Security Considerations . . . . . . . . . . . . . . . . . . . 6 70 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 71 11.1. Normative References . . . . . . . . . . . . . . . . . . 6 72 11.2. Informative References . . . . . . . . . . . . . . . . . 7 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 75 1. Introduction 77 Segment Routing (SR) [I-D.filsfils-rtgwg-segment-routing] is a new 78 MPLS paradigm in which each SR-capable router is required to 79 advertise global MPLS labels or Segment IDs (SID) for its attached 80 prefixes by using link-state IGPs, e.g., 81 OSPF[I-D.psenak-ospf-segment-routing-extensions] . One major 82 challenge associated with such global MPLS label or SID advertisement 83 mechanism is how to avoid a given global MPLS label or SID from being 84 allocated by different routers to different prefixes. Although such 85 global label or SID allocation collision problem can be addressed 86 through manual allocation, it is error-prone and nonautomatic 87 therefore may not be suitable in large-scale SR network environments. 89 This document proposes an alternative approach for allocating and 90 advertising global MPLS labels or SIDs via OSPF so as to eliminate 91 the potential risk of label allocation collision. The basic idea of 92 this approach is to allow a particular IGP router to allocate global 93 MPLS labels or SIDs for those prefixes attached to each SR-capable 94 router and meanwhile advertise the corresponding label or SID 95 bindings in the IGP domain scope. That particular IGP rouer is 96 therefore refered to as a mapping server. As for how the mapping 97 server know which prefixes need to be allocated with global labels or 98 SIDs, it can be achieved either by configuration on the mapping 99 server or by advertisement from SR-capable routers. In the multi- 100 area scenario where route summarization between areas is enabled, the 101 IP longest-match algorithm SHOULD be used by SR-capable routers when 102 processing label or SID bindings advertised by the mapping server, 103 just as the mechanism defined in [RFC5283]. 105 1.1. Requirements Language 107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 109 document are to be interpreted as described in RFC 2119 [RFC2119]. 111 2. Terminology 113 This memo makes use of the terms defined in 114 [I-D.filsfils-rtgwg-segment-routing] and [RFC4970]. 116 3. Advertising Label Bindings for Prefixes 118 A new Opaque LSA [RFC5250] of type 11 (with domain-wide flooding 119 scope), referred to as Prefix Opaque LSA, is defined. The opaque 120 type of this Prefix Opaque LSA is TBD. A mapping server could use 121 one or more Prefix Opaque LSAs to advertise label bindings for those 122 prefixes which need to be allocated with global labels. One or more 123 Prefix TLV (type code=TBD) as shown below could be contained in a 124 Prefix Opaque LSA. 126 0 1 2 3 127 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 128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 129 | Type=TBD | Length | 130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 131 | MT-ID | Prefix-Len | Reserved | 132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 133 | IPv4 Prefix (0-4 octets) | 134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 135 // Sub-TLVs (Variable) // 136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 138 Type: TBD. 140 Length: Variable. 142 MT-ID: Multi-Topology ID as defined in [RFC4915]. 144 Prefix-Len: the length of the prefix in bits (i.e., 0-32). 146 IPv4 Prefix: the prefix is encoded in the minimal number of octets 147 (i.e., 0-4) for the given number of significant bits. 149 A Label Binding Sub-TLV (type code=TBD) as shown below is associated 150 with a prefix which is contained in the Prefix TLV. 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 | Type=TBD | Length | 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 |P| Reserved | MPLS Label (20 bit) | 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 Type: TBD. 162 Length: 4. 164 P-Flag: if set, the penultimate hop router MUST perform PHP action 165 on the allocated MPLS label. For a given prefix, the P-Flag in 166 the Label Binding Sub-TLV MUST be set to the same value as that of 167 the P-Flag in the Label Request Sub-TLV if a label request message 168 (see section 5 of this document) for that prefix is received by 169 the mapping server. 171 MPLS Label: a global label which is allocated to the prefix which 172 is contained in the Prefix TLV. 174 4. Advertising SID Bindings for Prefixes 176 A mapping server could use one or more Prefix Opaque LSAs as defined 177 in Section 3 to advertise SID bindings for those prefixes which need 178 to be allocated with global SIDs. One or more Prefix TLV as defined 179 in Section 3 could be contained in a Prefix Opaque LSA. 181 A SID Binding Sub-TLV (type code=TBD) as shown below is associated 182 with a prefix which is contained in the Prefix TLV. 184 0 1 2 3 185 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 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 | Type=TBD | Length | 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 | SID | 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 Type: TBD. 194 Length: 4. 196 SID: a SID for the prefix which is carried in the TLV containing 197 this sub-TLV. 199 5. Requesting Label Bindings for Prefixes 201 SR-capable OSPF routers could use one or more Prefix Opaque LSAs as 202 defined in section 3 of this document to advertise those among their 203 attached prefixes which need to be allocated with global labels. A 204 new Sub-TLV of the Prefix TLV, referred to as Label Request Sub-TLV 205 (type code=TBD) as shown below is associated with a prefix which is 206 contained in a Prefix TLV. 208 0 1 2 3 209 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 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 | Type=TBD | Length | 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 |P| Reserved | 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 Type: TBD. 218 Length: 4. 220 P-Flag: if set, the penultimate hop router MUST perform PHP action 221 on the required label. 223 6. Requesting SID Bindings for Prefixes 225 SR-capable OSPF routers could use one or more Prefix Opaque LSAs as 226 defined in section 3 of this document to advertise those among their 227 attached prefixes which need to be allocated with global SIDs. A new 228 Sub-TLV of the Prefix TLV, referred to as SID Request Sub-TLV (type 229 code=TBD and Length=0) is associated with a prefix which is contained 230 in a Prefix TLV. 232 7. Advertising Mapping Server Capability 234 For redundancy purpose, more than one router could be configured as 235 candidates for mapping servers. Each candidate for mapping servers 236 SHOULD advertise its capability of being a mapping servers by using 237 OSPF Router Capability TLV. The one with the highest priority SHOULD 238 be elected as the primary mapping server which is eligible to 239 allocate and advertise global labels or SIDs for prefixes on behalf 240 of SR-capable routers. The comparison of OSPF router ID breaks the 241 tie between two or more candidates with the same highest priority. 243 Meanwhile, the one with the second highest priority SHOULD be elected 244 as a backup mapping server. This backup mapping server SHOULD 245 advertise the same label bindings as those advertised by the primary 246 mapping server. In this way, the unnecessary changes to the data 247 plane (i.e., MPLS forwarding table) of SR-capable routers can be 248 avoided in the event of mapping server failover. 250 Each candidate mapping server SHOULD advertise its capability of 251 being mapping servers by using an OSPF Router Informational 252 Capabilities TLV [RFC4970] contained in an Opaque LSA of type 11 253 (with domain-wide flooding scope). One of the unreserved OSPF Router 254 Informational Capabilities Bits is reserved for this purpose. 255 Furthermore, a sub-TLV (type code=TBD) as shown below is used to 256 convey the priority value for mapping server election. 258 0 1 2 3 259 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 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 | Type | Length | 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 | Priority | 264 +-+-+-+-+-+-+-+-+ 266 Type: TBD. 268 Length: 1 270 Priority: the priority for mapping server election. 272 8. Acknowledgements 274 The authors would like to thank . 276 9. IANA Considerations 278 TBD. 280 10. Security Considerations 282 This document does not introduce any new security considerations. 284 11. References 286 11.1. Normative References 288 [I-D.psenak-ospf-segment-routing-extensions] 289 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 290 Shakir, R., and W. Henderickx, "OSPF Extensions for 291 Segment Routing", draft-psenak-ospf-segment-routing- 292 extensions-03 (work in progress), October 2013. 294 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 295 Requirement Levels", BCP 14, RFC 2119, March 1997. 297 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 299 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 300 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", RFC 301 4915, June 2007. 303 [RFC4970] Lindem, A., Shen, N., Vasseur, JP., Aggarwal, R., and S. 304 Shaffer, "Extensions to OSPF for Advertising Optional 305 Router Capabilities", RFC 4970, July 2007. 307 [RFC5250] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The 308 OSPF Opaque LSA Option", RFC 5250, July 2008. 310 [RFC5283] Decraene, B., Le Roux, JL., and I. Minei, "LDP Extension 311 for Inter-Area Label Switched Paths (LSPs)", RFC 5283, 312 July 2008. 314 11.2. Informative References 316 [I-D.filsfils-rtgwg-segment-routing] 317 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 318 Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., 319 Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe, 320 "Segment Routing Architecture", draft-filsfils-rtgwg- 321 segment-routing-01 (work in progress), October 2013. 323 Authors' Addresses 325 Xiaohu Xu 326 Huawei 328 Email: xuxiaohu@huawei.com 330 Mach Chen 331 Huawei 333 Email: mach.chen@huawei.com