idnits 2.17.1 draft-wang-idr-bgpls-inter-as-topology-ext-02.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 14, 2018) is 2082 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: 'I-D.ietf-idr-bgp-ls-segment-routing-ext' is defined on line 348, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-teas-native-ip-scenarios' is defined on line 365, but no explicit reference was found in the text == Unused Reference: 'RFC2328' is defined on line 380, but no explicit reference was found in the text == Unused Reference: 'RFC7794' is defined on line 408, but no explicit reference was found in the text == Unused Reference: 'RFC8362' is defined on line 413, but no explicit reference was found in the text == Outdated reference: A later version (-18) exists of draft-ietf-idr-bgp-ls-segment-routing-ext-08 == Outdated reference: A later version (-19) exists of draft-ietf-idr-bgpls-segment-routing-epe-15 == Outdated reference: A later version (-12) exists of draft-ietf-teas-native-ip-scenarios-01 ** Downref: Normative reference to an Informational draft: draft-ietf-teas-native-ip-scenarios (ref. 'I-D.ietf-teas-native-ip-scenarios') ** Obsolete normative reference: RFC 5316 (Obsoleted by RFC 9346) ** Obsolete normative reference: RFC 7752 (Obsoleted by RFC 9552) Summary: 3 errors (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IDR Working Group A. Wang 3 Internet-Draft China Telecom 4 Intended status: Standards Track H. Chen 5 Expires: February 15, 2019 Huawei Technologies 6 August 14, 2018 8 BGP-LS Extension for Inter-AS Topology Retrieval 9 draft-wang-idr-bgpls-inter-as-topology-ext-02 11 Abstract 13 This document describes the process to build BGP-LS key parameters in 14 Native IP multi-domain scenario and defines some new inter-AS TE 15 related TLVs for BGP-LS to let SDN controller retrieve the network 16 topology automatically under various environments. 18 Such process and extension can expand the usage of BGP-LS protocol to 19 multi- domain, enable the network operator to collect the connection 20 relationship between different AS domains and then calculate the 21 overall network topology automatically based on the information 22 provided by BGP-LS protocol. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on February 15, 2019. 41 Copyright Notice 43 Copyright (c) 2018 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Conventions used in this document . . . . . . . . . . . . . . 3 60 3. Inter-AS Domain Scenarios. . . . . . . . . . . . . . . . . . 3 61 3.1. IS-IS/OSPF Inter-AS Native IP Scenario . . . . . . . . . 3 62 3.2. IS-IS/OSPF Inter-AS TE Scenario . . . . . . . . . . . . . 4 63 4. Inter-AS TE related TLVs . . . . . . . . . . . . . . . . . . 5 64 4.1. Remote AS Number TLV . . . . . . . . . . . . . . . . . . 5 65 4.2. IPv4 Remote ASBR ID . . . . . . . . . . . . . . . . . . . 6 66 4.3. IPv6 Remote ASBR ID . . . . . . . . . . . . . . . . . . . 6 67 5. Topology Reconstruction. . . . . . . . . . . . . . . . . . . 7 68 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 69 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 70 8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 8 71 9. Normative References . . . . . . . . . . . . . . . . . . . . 8 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 74 1. Introduction 76 BGP-LS [RFC7752] describes the methodology that using BGP protocol to 77 transfer the Link-State information. Such method can enable SDN 78 controller to collect the underlay network topology automatically, 79 but normally it can only get the information within one IGP domain. 80 If the operator has more than one IGP domain, and these domains 81 interconnect with each other, there is no general TLV within current 82 BGP- LS to transfer the interconnect information. 84 Draft [I-D.ietf-idr-bgpls-segment-routing-epe] defines some 85 extensions for exporting BGP peering node topology information 86 (including its peers, interfaces and peering ASs) in a way that is 87 exploitable in order to compute efficient BGP Peering Engineering 88 policies and strategies. Such information can also be used to 89 calculate the interconnection topology among different IGP domains, 90 but it requires the border routers to run BGP-LS protocol to collect 91 this information and report them to the PCE/SDN controller, which 92 restricts the deployment flexibility of BGP-LS protocol. 94 This draft analysizes the situations that the PCE/SDN controller 95 needs to get about the inter-connected information between different 96 AS domains, defines new TLVs to extend the BGP-LS protocol to 97 transfer the key information related to the interconnect TE topology. 98 After that, the SDN controller can then deduce the multi-domain 99 topology automatically based on the information from BGP-LS protocol. 101 2. Conventions used in this document 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 105 document are to be interpreted as described in RFC 2119 [RFC2119] . 107 3. Inter-AS Domain Scenarios. 109 Fig.1 illustrates the multi-domain scenarios that this draft 110 discussed. Normally, SDN Controller can get the topology of IGP A 111 and IGP B individually via the BGP-LS protocol, but it can't get the 112 topology connection information between these two IGP domains because 113 there is generally no IGP protocol run on the connected links. 115 +-----------------+ 116 +----+IP SDN Controller+----+ 117 | +-----------------+ | 118 | | 119 |BGP-LS |BGP-LS 120 | | 121 +---------------+-----+ +-----+--------------+ 122 | +--+ +-++ ++-+ +-++ +|-+ +--+| 123 | |S1+--------+S2+---+B1+-----------+B2+---+T1+--------+T2|| 124 | +-++ N1 +-++ ++-+ +-++ ++++ N2 +-++| 125 | | | | | || | | 126 | | | | | || | | 127 | +-++ +-++ ++-+ +-++ ++++ +-++| 128 | |S4+--------+S3+---+B3+-----------+B4+---+T3+--------+T4|| 129 | +--+ +--+ ++-+ +-++ ++-+ +--+| 130 | | | | 131 | | | | 132 | IGP A | | IGP B | 133 +---------------------+ +--------------------+ 135 Figure 1: Inter-AS Domain Scenarios 137 3.1. IS-IS/OSPF Inter-AS Native IP Scenario 139 When the IGP A or IGP B runs native IS-IS/OSPF protocol, the operator 140 often redistributes the IPv4/IPv6 prefixes of interconnect links into 141 IS-IS/OSPF protocol to ensure the inter-domain connectivity. 143 If the IGP runs IS-IS protocol, the redistributed link information 144 will be carried in IP External Reachability Information TLV within 145 the Level 2 PDU type that defined in [RFC1195], every router within 146 the IGP domain can deduce the redistributed router from the IS-IS 147 LSDB. 149 If the IGP runs OSPF protocol,[RFC2328]defines the type 5 external 150 LSA to transfer the external IPv4 routes; 151 [I-D.ietf-ospf-ospfv3-lsa-extend] defines the "External-Prefix TLV" 152 to transfer the external IPv6 routes; these LSAs have also the 153 advertising router information that initiates the redistribute 154 activity. Every router within IGP domain can also deduce the 155 redistributed router from the OSPF LSDB. 157 For prefix information that associated with each router, BGP-LS 158 [RFC7752] defines the Prefix NLRI which is illustrated below: 160 0 1 2 3 161 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 162 +-+-+-+-+-+-+-+-+ 163 | Protocol-ID | 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 | Identifier | 166 | (64 bits) | 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 // Local Node Descriptors (variable) // 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 // Prefix Descriptors (variable) // 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 Figure 2: The IPv4/IPv6 Topology Prefix NLRI Format 175 For these redistributed inter-domain links, their prefix information 176 should be included in the "Prefix Descriptor", and the associated 177 redistributed router information should be included in the "Local 178 Node Descriptors". 180 When such information is reported via the BGP-LS protocol, the PCE/ 181 SDN controller can construct the underlay inter-domain topology 182 according to procedure described in section 5 184 3.2. IS-IS/OSPF Inter-AS TE Scenario 186 [RFC5316] and [RFC5392] define the IS-IS and OSPF extensions 187 respectively to deal with the requirements for inter-AS traffic 188 engineering. They define some new sub-TLVs(Remote AS 189 Number、IPv4 Remote ASBR ID、IPv6 Remote ASBR ID) which 190 are associated with the inter-AS TE link TLVs to report the TE 191 topology between different domains. 193 These TLVs are flooded within the IGP domain automatically. If the 194 PCE/SDN controller can know these information via one of the interior 195 router that runs BGP-LS protocol, the PCE/SDN controller can rebuild 196 the inter-AS TE topology correctly. 198 4. Inter-AS TE related TLVs 200 This draft proposes to add three new TLVs that is included within the 201 inter-AS TE link NLRI to transfer the information via BGP-LS, which 202 are required to build the inter-AS related topology by the PCE/SDN 203 controller. 205 The following Link Descriptor TLVs are added into the Link NLRI in 206 BGP-LS protocol : 208 +-----------+---------------------+--------------+----------------+ 209 | TLV Code | Description |IS-IS/OSPF TLV| Reference | 210 | Point | | /Sub-TLV | (RFC/Section) | 211 +-----------+---------------------+--------------+----------------+ 212 | TBD |Remote AS Number | 24/21 | [RFC5316]/3.3.1| 213 | | | | [RFC5392]/3.3.1| 214 | TBD |IPv4 Remote ASBR ID | 25/22 | [RFC5316]/3.3.2| 215 | | | | [RFC5392]/3.3.2| 216 | TBD |IPv6 Remote ASBR ID | 26/24 | [RFC5316]/3.3.3| 217 | | | | [RFC5392]/3.3.3| 218 +-----------+---------------------+--------------+----------------+ 220 Detail encoding of these TLVs are synchronized with the corresponding 221 parts in [RFC5316] and [RFC5392], which keeps the BGP-LS protocol is 222 agnostic to the underly protocol. 224 4.1. Remote AS Number TLV 226 A new TLV, the remote AS number TLV, is defined for inclusion in the 227 link descriptor when advertising inter-AS links. The remote AS 228 number TLV specifies the AS number of the neighboring AS to which the 229 advertised link connects. 231 The remote AS number TLV is TLV type TBD (see Section 7) and is 4 232 octets in length. The format is as follows: 234 0 1 2 3 235 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 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 | Type | Length | 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 | Remote AS Number | 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 The Remote AS number field has 4 octets. When only 2 octets are used 242 for the AS number, as in current deployments, the left (high-order) 2 243 octets MUST be set to 0. The remote AS number TLV MUST be included 244 when a router advertises an inter-AS TE link. 246 4.2. IPv4 Remote ASBR ID 248 A new TLV, which is referred to as the IPv4 remote ASBR ID TLV, is 249 defined for inclusion in the link descriptor when advertising inter- 250 AS links. The IPv4 remote ASBR ID TLV specifies the IPv4 identifier 251 of the remote ASBR to which the advertised inter-AS link connects. 252 This could be any stable and routable IPv4 address of the remote 253 ASBR. Use of the TE Router ID as specified in the Traffic 254 Engineering router ID TLV [RFC5305] is RECOMMENDED. 256 The IPv4 remote ASBR ID TLV is TLV type TBD (see Section 7) and is 4 257 octets in length. The format of the IPv4 remote ASBR ID sub-TLV is 258 as follows: 260 0 1 2 3 261 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 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 | Type | Length | 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 | Remote ASBR ID | 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 The IPv4 remote ASBR ID TLV MUST be included if the neighboring ASBR 269 has an IPv4 address. If the neighboring ASBR does not have an IPv4 270 address (not even an IPv4 TE Router ID), the IPv6 remote ASBR ID TLV 271 MUST be included instead. An IPv4 remote ASBR ID TLV and IPv6 remote 272 ASBR ID TLV MAY both be present in an extended IS reachability TLV. 274 4.3. IPv6 Remote ASBR ID 276 A new TLV, which is referred to as the IPv6 remote ASBR ID TLV, is 277 defined for inclusion in the inter-AS reachability TLV when 278 advertising inter-AS links. The IPv6 remote ASBR ID TLV specifies 279 the IPv6 identifier of the remote ASBR to which the advertised inter- 280 AS link connects. This could be any stable and routable IPv6 address 281 of the remote ASBR. Use of the TE Router ID as specified in the IPv6 282 Traffic Engineering router ID TLV [RFC6119] is RECOMMENDED. 284 The IPv6 remote ASBR ID TLV is TLV type TBD (see Section 7) and is 16 285 octets in length. The format of the IPv6 remote ASBR ID TLV is as 286 follows: 288 0 1 2 3 289 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 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 | Type | Length | 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 | Remote ASBR ID | 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | Remote ASBR ID (continued) | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | Remote ASBR ID (continued) | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 | Remote ASBR ID (continued) | 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 The IPv6 remote ASBR ID TLV MUST be included if the neighboring ASBR 303 has an IPv6 address. If the neighboring ASBR does not have an IPv6 304 address, the IPv4 remote ASBR ID TLV MUST be included instead. An 305 IPv4 remote ASBR ID TLV and IPv6 remote ASBR ID TLV MAY both be 306 present in an extended IS reachability TLV. 308 5. Topology Reconstruction. 310 When SDN Controller gets such information from BGP-LS protocol, it 311 should compares the proximity of the redistributed prefixes. If they 312 are under the same network scope, then it should find the 313 corresponding associated router information, build the link between 314 these two border routers. 316 After iterating the above procedures for all of the redistributed 317 prefixes, the SDN controller can then retrieve the connection 318 topology between different domains automatically. 320 6. Security Considerations 322 It is common for one operator to occupy several IGP domains that 323 composited by its backbone network and several MAN(Metrio-Area- 324 Network)s/IDCs. When they do traffic engineering from end to end 325 that spans MAN-backbone-IDC, they need to know the inter-as topology 326 via the process described in this draft. Then it is naturally to 327 redistribute the interconnection prefixes in Native IP scenario. 329 If these IGP domains belong to different operators, it is uncommon do 330 inter-as traffic engineering under one PCE/SDN controller, then it is 331 unnecessary to get the inter-as topology. But redistributing the 332 interconnection prefixes will do no harm to their networks, because 333 the redistributed interconnection link prefixes belongs to both of 334 them, they are also the interfaces addresses on the border routers. . 336 7. IANA Considerations 338 TBD. 340 8. Acknowledgement 342 The author would like to thank Acee Lindem, Ketan Talaulikar, Jie 343 Dong, Jeff Tantsura and Dhruv Dhody for their valuable comments and 344 suggestions. 346 9. Normative References 348 [I-D.ietf-idr-bgp-ls-segment-routing-ext] 349 Previdi, S., Talaulikar, K., Filsfils, C., Gredler, H., 350 and M. Chen, "BGP Link-State extensions for Segment 351 Routing", draft-ietf-idr-bgp-ls-segment-routing-ext-08 352 (work in progress), May 2018. 354 [I-D.ietf-idr-bgpls-segment-routing-epe] 355 Previdi, S., Filsfils, C., Patel, K., Ray, S., and J. 356 Dong, "BGP-LS extensions for Segment Routing BGP Egress 357 Peer Engineering", draft-ietf-idr-bgpls-segment-routing- 358 epe-15 (work in progress), March 2018. 360 [I-D.ietf-ospf-ospfv3-lsa-extend] 361 Lindem, A., Roy, A., Goethals, D., Vallem, V., and F. 362 Baker, "OSPFv3 LSA Extendibility", draft-ietf-ospf-ospfv3- 363 lsa-extend-23 (work in progress), January 2018. 365 [I-D.ietf-teas-native-ip-scenarios] 366 Wang, A., Huang, X., Qou, C., Li, Z., Huang, L., and P. 367 Mi, "CCDR Scenario, Simulation and Suggestion", draft- 368 ietf-teas-native-ip-scenarios-01 (work in progress), June 369 2018. 371 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 372 dual environments", RFC 1195, DOI 10.17487/RFC1195, 373 December 1990, . 375 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 376 Requirement Levels", BCP 14, RFC 2119, 377 DOI 10.17487/RFC2119, March 1997, 378 . 380 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 381 DOI 10.17487/RFC2328, April 1998, 382 . 384 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 385 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 386 2008, . 388 [RFC5316] Chen, M., Zhang, R., and X. Duan, "ISIS Extensions in 389 Support of Inter-Autonomous System (AS) MPLS and GMPLS 390 Traffic Engineering", RFC 5316, DOI 10.17487/RFC5316, 391 December 2008, . 393 [RFC5392] Chen, M., Zhang, R., and X. Duan, "OSPF Extensions in 394 Support of Inter-Autonomous System (AS) MPLS and GMPLS 395 Traffic Engineering", RFC 5392, DOI 10.17487/RFC5392, 396 January 2009, . 398 [RFC6119] Harrison, J., Berger, J., and M. Bartlett, "IPv6 Traffic 399 Engineering in IS-IS", RFC 6119, DOI 10.17487/RFC6119, 400 February 2011, . 402 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 403 S. Ray, "North-Bound Distribution of Link-State and 404 Traffic Engineering (TE) Information Using BGP", RFC 7752, 405 DOI 10.17487/RFC7752, March 2016, 406 . 408 [RFC7794] Ginsberg, L., Ed., Decraene, B., Previdi, S., Xu, X., and 409 U. Chunduri, "IS-IS Prefix Attributes for Extended IPv4 410 and IPv6 Reachability", RFC 7794, DOI 10.17487/RFC7794, 411 March 2016, . 413 [RFC8362] Lindem, A., Roy, A., Goethals, D., Reddy Vallem, V., and 414 F. Baker, "OSPFv3 Link State Advertisement (LSA) 415 Extensibility", RFC 8362, DOI 10.17487/RFC8362, April 416 2018, . 418 Authors' Addresses 420 Aijun Wang 421 China Telecom 422 Beiqijia Town, Changping District 423 Beijing, Beijing 102209 424 China 426 Email: wangaj.bri@chinatelecom.cn 427 Huaimo Chen 428 Huawei Technologies 429 Boston, MA 430 USA 432 Email: Huaimo.chen@huawei.com