idnits 2.17.1 draft-ietf-idr-bgpls-inter-as-topology-ext-01.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 (March 7, 2019) is 1874 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 386, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-teas-native-ip-scenarios' is defined on line 403, but no explicit reference was found in the text == Unused Reference: 'RFC2328' is defined on line 418, but no explicit reference was found in the text == Unused Reference: 'RFC7794' is defined on line 446, but no explicit reference was found in the text == Unused Reference: 'RFC8362' is defined on line 451, 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-11 == Outdated reference: A later version (-19) exists of draft-ietf-idr-bgpls-segment-routing-epe-17 == Outdated reference: A later version (-12) exists of draft-ietf-teas-native-ip-scenarios-02 ** 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: September 8, 2019 Huawei Technologies 6 S. Ma 7 Juniper Networks 8 March 7, 2019 10 BGP-LS Extension for Inter-AS Topology Retrieval 11 draft-ietf-idr-bgpls-inter-as-topology-ext-01 13 Abstract 15 This document describes the process to build BGP-LS key parameters in 16 multi-domain scenario, defines one new BGP-LS NLRI type(Inter-AS TE 17 Link NLRI) and some new inter-AS TE related TLVs for BGP-LS to let 18 SDN controller retrieve the network topology automatically under 19 various environments. 21 Such process and extension can enable the network operator to collect 22 the connection information between different domains and then 23 calculate the overall network topology automatically based on the 24 information provided by BGP-LS protocol. 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 https://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 September 8, 2019. 43 Copyright Notice 45 Copyright (c) 2019 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 (https://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 2. Conventions used in this document . . . . . . . . . . . . . . 3 62 3. Inter-AS Domain Scenarios. . . . . . . . . . . . . . . . . . 3 63 3.1. IS-IS/OSPF Inter-AS Native IP Scenario . . . . . . . . . 4 64 3.2. IS-IS/OSPF Inter-AS TE Scenario . . . . . . . . . . . . . 5 65 4. Inter-AS TE Link NLRI . . . . . . . . . . . . . . . . . . . . 5 66 5. Inter-AS TE NLRI related TLVs . . . . . . . . . . . . . . . . 5 67 5.1. Remote AS Number TLV . . . . . . . . . . . . . . . . . . 6 68 5.2. IPv4 Remote ASBR ID . . . . . . . . . . . . . . . . . . . 7 69 5.3. IPv6 Remote ASBR ID . . . . . . . . . . . . . . . . . . . 7 70 6. Topology Reconstruction. . . . . . . . . . . . . . . . . . . 8 71 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 72 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 73 9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 9 74 10. Normative References . . . . . . . . . . . . . . . . . . . . 9 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 77 1. Introduction 79 BGP-LS [RFC7752] describes the methodology that using BGP protocol to 80 transfer the Link-State information. Such method can enable SDN 81 controller to collect the underlay network topology automatically, 82 but normally it can only get the information within one IGP domain. 83 If the operator has more than one IGP domain, and these domains 84 interconnect with each other, there is no general TLV within current 85 BGP- LS to transfer the interconnect topology information. 87 Draft [I-D.ietf-idr-bgpls-segment-routing-epe] defines some 88 extensions for exporting BGP peering node topology information 89 (including its peers, interfaces and peering ASs) in a way that is 90 exploitable in order to compute efficient BGP Peering Engineering 91 policies and strategies. Such information can also be used to 92 calculate the interconnection topology among different IGP domains, 93 but it requires the border routers to run BGP-LS protocol and report 94 the information to the PCE/SDN controller, which restricts the 95 solution deployment flexibility. 97 This draft analysis the situations that the PCE/SDN controller needs 98 to get the inter-connected topology information between different AS 99 domains, defines the new Inter-AS TE Link NLRI and some new TLVs 100 within the BGP-LS protocol to transfer the key information related to 101 them. After that, the SDN controller can then deduce the multi- 102 domain topology automatically based on the information from BGP-LS 103 protocol. 105 2. Conventions used in this document 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 3. Inter-AS Domain Scenarios. 113 Fig.1 illustrates the multi-domain scenarios that this draft 114 discussed. Normally, SDN Controller can get the topology of IGP A 115 and IGP B individually via the BGP-LS protocol, but it can't get the 116 topology connection information between these two IGP domains because 117 there is generally no IGP protocol run on the connected links. 119 +-----------------+ 120 +----+IP SDN Controller+----+ 121 | +-----------------+ | 122 | | 123 |BGP-LS |BGP-LS 124 | | 125 +---------------+-----+ +-----+--------------+ 126 | +--+ +-++ ++-+ +-++ +|-+ +--+| 127 | |S1+--------+S2+---+B1+-----------+B2+---+T1+--------+T2|| 128 | +-++ N1 +-++ ++-+ +-++ ++++ N2 +-++| 129 | | | | | || | | 130 | | | | | || | | 131 | +-++ +-++ ++-+ +-++ ++++ +-++| 132 | |S4+--------+S3+---+B3+-----------+B4+---+T3+--------+T4|| 133 | +--+ +--+ ++-+ +-++ ++-+ +--+| 134 | | | | 135 | | | | 136 | IGP A | | IGP B | 137 +---------------------+ +--------------------+ 139 Figure 1: Inter-AS Domain Scenarios 141 3.1. IS-IS/OSPF Inter-AS Native IP Scenario 143 When the IGP A or IGP B runs native IS-IS/OSPF protocol, the operator 144 can redistributes the IPv4/IPv6 prefixes of interconnect links into 145 IS-IS/OSPF protocol to ensure the inter-domain connectivity. 147 If the IGP runs IS-IS protocol, the redistributed link information 148 will be carried in IP External Reachability Information TLV within 149 the Level 2 PDU type that defined in [RFC1195], every router within 150 the IGP domain can deduce the redistributed router from the IS-IS 151 LSDB. 153 If the IGP runs OSPF protocol[RFC2328]defines the type 5 external LSA 154 to transfer the external IPv4 routes; 155 [I-D.ietf-ospf-ospfv3-lsa-extend] defines the "External-Prefix TLV" 156 to transfer the external IPv6 routes; these LSAs have also the 157 advertising router information that initiates the redistribute 158 activity. Every router within IGP domain can also deduce the 159 redistributed router from the OSPF LSDB. 161 For prefix information that associated with each router, BGP-LS 162 [RFC7752] defines the Prefix NLRI which is illustrated below: 164 0 1 2 3 165 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 166 +-+-+-+-+-+-+-+-+ 167 | Protocol-ID | 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 | Identifier | 170 | (64 bits) | 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 // Local Node Descriptors (variable) // 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 174 // Prefix Descriptors (variable) // 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 Figure 2: The IPv4/IPv6 Topology Prefix NLRI Format 179 For these redistributed inter-domain links, their prefix information 180 should be included in the "Prefix Descriptor", and the associated 181 redistributed router information should be included in the "Local 182 Node Descriptors". 184 When such information is reported via the BGP-LS protocol, the PCE/ 185 SDN controller can construct the underlay inter-domain topology 186 according to procedure described in section 6. 188 3.2. IS-IS/OSPF Inter-AS TE Scenario 190 [RFC5316] and [RFC5392] define the IS-IS and OSPF extensions 191 respectively to deal with the requirements for inter-AS traffic 192 engineering. They define some new sub-TLVs(Remote AS 193 Number、IPv4 Remote ASBR ID、IPv6 Remote ASBR ID) which 194 are associated with the inter-AS TE link TLVs to report the TE 195 topology between different domains. 197 These TLVs are flooded within the IGP domain automatically. If the 198 PCE/SDN controller can know these information via one of the interior 199 router that runs BGP-LS protocol, the PCE/SDN controller can rebuild 200 the inter-AS TE topology correctly. 202 4. Inter-AS TE Link NLRI 204 [RFC7752] defines four NLRI types(Node NLRI, Link NLRI, IPv4 Topology 205 Prefix NLRI, IPv6 Topology Prefix NLRI) to transfer the topology and 206 prefix information. For inter-as TE link, the two ends of the link 207 locates in different IGP domains, then it is not appropriate to 208 transfer their information within the current defined NLRI types. 210 This draft defines then one new NLRI type, called Inter-AS TE Link 211 NLRI, which is coded as the following format: 213 0 1 2 3 214 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 215 +-+-+-+-+-+-+-+-+ 216 | Protocol-ID | 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 | Identifier | 219 | (64 bits) | 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 // Local Node Descriptors (variable) // 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 // Inter-AS TE Link Descriptors (variable) // 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 Figure 3: The Inter-AS TE Link NLRI Format 228 The semantics of "Inter-AS TE Link Descriptors" is same as that 229 defined in [RFC7752] for "Link Descriptor". 231 5. Inter-AS TE NLRI related TLVs 233 This draft proposes to add three new TLVs that is included within the 234 inter-AS TE Link NLRI to transfer the information via BGP-LS, which 235 are required to build the inter-AS related topology by the PCE/SDN 236 controller. 238 The following Link Descriptor TLVs are added into the Inter-AS TE 239 Link NLRI in BGP-LS protocol : 241 +-----------+---------------------+--------------+----------------+ 242 | TLV Code | Description |IS-IS/OSPF TLV| Reference | 243 | Point | | /Sub-TLV | (RFC/Section) | 244 +-----------+---------------------+--------------+----------------+ 245 | TBD |Remote AS Number | 24/21 | [RFC5316]/3.3.1| 246 | | | | [RFC5392]/3.3.1| 247 | TBD |IPv4 Remote ASBR ID | 25/22 | [RFC5316]/3.3.2| 248 | | | | [RFC5392]/3.3.2| 249 | TBD |IPv6 Remote ASBR ID | 26/24 | [RFC5316]/3.3.3| 250 | | | | [RFC5392]/3.3.3| 251 +-----------+---------------------+--------------+----------------+ 252 Figure 4: Link Descriptor TLVs for Inter-AS TE Link NLRI Format 254 Detail encoding of these TLVs are synchronized with the corresponding 255 parts in [RFC5316] and [RFC5392], which keeps the BGP-LS protocol is 256 agnostic to the underly protocol. 258 5.1. Remote AS Number TLV 260 A new TLV, the remote AS number TLV, is defined for inclusion in the 261 link descriptor when advertising inter-AS TE links. The remote AS 262 number TLV specifies the AS number of the neighboring AS to which the 263 advertised link connects. 265 The remote AS number TLV is TLV type TBD (see Section 7) and is 4 266 octets in length. The format is as follows: 268 0 1 2 3 269 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 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 | Type | Length | 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 | Remote AS Number | 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 Figure 5: Remote AS Number TLV Format 277 The Remote AS number field has 4 octets. When only 2 octets are used 278 for the AS number, as in current deployments, the left (high-order) 2 279 octets MUST be set to 0. The remote AS number TLV MUST be included 280 when a router advertises an inter-AS TE link. 282 5.2. IPv4 Remote ASBR ID 284 A new TLV, which is referred to as the IPv4 remote ASBR ID TLV, is 285 defined for inclusion in the link descriptor when advertising inter- 286 AS TE links. The IPv4 remote ASBR ID TLV specifies the IPv4 287 identifier of the remote ASBR to which the advertised inter-AS link 288 connects. This could be any stable and routable IPv4 address of the 289 remote ASBR. Use of the TE Router ID as specified in the Traffic 290 Engineering router ID TLV [RFC5305] is RECOMMENDED. 292 The IPv4 remote ASBR ID TLV is TLV type TBD (see Section 7) and is 4 293 octets in length. The format of the IPv4 remote ASBR ID sub-TLV is 294 as follows: 296 0 1 2 3 297 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 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 | Type | Length | 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 | Remote ASBR ID | 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 Figure 6: IPv4 Remote ASBR ID TLV Format 305 The IPv4 remote ASBR ID TLV MUST be included if the neighboring ASBR 306 has an IPv4 address. If the neighboring ASBR does not have an IPv4 307 address (not even an IPv4 TE Router ID), the IPv6 remote ASBR ID TLV 308 MUST be included instead. An IPv4 remote ASBR ID TLV and IPv6 remote 309 ASBR ID TLV MAY both be present in an inter-AS TE link NLRI. 311 5.3. IPv6 Remote ASBR ID 313 A new TLV, which is referred to as the IPv6 remote ASBR ID TLV, is 314 defined for inclusion in the inter-AS reachability TLV when 315 advertising inter-AS links. The IPv6 remote ASBR ID TLV specifies 316 the IPv6 identifier of the remote ASBR to which the advertised inter- 317 AS link connects. This could be any stable and routable IPv6 address 318 of the remote ASBR. Use of the TE Router ID as specified in the IPv6 319 Traffic Engineering router ID TLV [RFC6119] is RECOMMENDED. 321 The IPv6 remote ASBR ID TLV is TLV type TBD (see Section 7) and is 16 322 octets in length. The format of the IPv6 remote ASBR ID TLV is as 323 follows: 325 0 1 2 3 326 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 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 | Type | Length | 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 | Remote ASBR ID | 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 | Remote ASBR ID (continued) | 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 | Remote ASBR ID (continued) | 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 | Remote ASBR ID (continued) | 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 Figure 7: IPv6 Remote ASBR ID TLV Format 340 The IPv6 remote ASBR ID TLV MUST be included if the neighboring ASBR 341 has an IPv6 address. If the neighboring ASBR does not have an IPv6 342 address, the IPv4 remote ASBR ID TLV MUST be included instead. An 343 IPv4 remote ASBR ID TLV and IPv6 remote ASBR ID TLV MAY both be 344 present in an inter-AS TE link NLRI. 346 6. Topology Reconstruction. 348 When SDN Controller gets such information from BGP-LS protocol, it 349 should compares the proximity of the redistributed prefixes. If they 350 are under the same network scope, then it should find the 351 corresponding associated router information, build the link between 352 these two border routers. 354 After iterating the above procedures for all of the redistributed 355 prefixes, the SDN controller can then retrieve the connection 356 topology between different domains automatically. 358 7. Security Considerations 360 It is common for one operator to occupy several IGP domains that are 361 composited by its backbone network and several MAN(Metrio-Area- 362 Network)s/IDCs. When they do traffic engineering from end to end 363 that spans MAN-backbone-IDC, they need to know the inter-as topology 364 via the process described in this draft. Then it is naturally to 365 redistribute the interconnection prefixes in Native IP scenario. 367 If these IGP domains belong to different operators, it is uncommon do 368 inter-as traffic engineering under one PCE/SDN controller, then it is 369 unnecessary to get the inter-as topology. But redistributing the 370 interconnection prefixes will do no harm to their networks, because 371 the redistributed interconnection link prefixes belongs to both of 372 them, they are also the interfaces addresses on the border routers. . 374 8. IANA Considerations 376 TBD. 378 9. Acknowledgement 380 The author would like to thank Acee Lindem, Ketan Talaulikar, Jie 381 Dong, Jeff Tantsura and Dhruv Dhody for their valuable comments and 382 suggestions. 384 10. Normative References 386 [I-D.ietf-idr-bgp-ls-segment-routing-ext] 387 Previdi, S., Talaulikar, K., Filsfils, C., Gredler, H., 388 and M. Chen, "BGP Link-State extensions for Segment 389 Routing", draft-ietf-idr-bgp-ls-segment-routing-ext-11 390 (work in progress), October 2018. 392 [I-D.ietf-idr-bgpls-segment-routing-epe] 393 Previdi, S., Talaulikar, K., Filsfils, C., Patel, K., Ray, 394 S., and J. Dong, "BGP-LS extensions for Segment Routing 395 BGP Egress Peer Engineering", draft-ietf-idr-bgpls- 396 segment-routing-epe-17 (work in progress), October 2018. 398 [I-D.ietf-ospf-ospfv3-lsa-extend] 399 Lindem, A., Roy, A., Goethals, D., Vallem, V., and F. 400 Baker, "OSPFv3 LSA Extendibility", draft-ietf-ospf-ospfv3- 401 lsa-extend-23 (work in progress), January 2018. 403 [I-D.ietf-teas-native-ip-scenarios] 404 Wang, A., Huang, X., Qou, C., Li, Z., and P. Mi, 405 "Scenario, Simulation and Suggestion of PCE in Native IP 406 Network", draft-ietf-teas-native-ip-scenarios-02 (work in 407 progress), October 2018. 409 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 410 dual environments", RFC 1195, DOI 10.17487/RFC1195, 411 December 1990, . 413 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 414 Requirement Levels", BCP 14, RFC 2119, 415 DOI 10.17487/RFC2119, March 1997, 416 . 418 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 419 DOI 10.17487/RFC2328, April 1998, 420 . 422 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 423 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 424 2008, . 426 [RFC5316] Chen, M., Zhang, R., and X. Duan, "ISIS Extensions in 427 Support of Inter-Autonomous System (AS) MPLS and GMPLS 428 Traffic Engineering", RFC 5316, DOI 10.17487/RFC5316, 429 December 2008, . 431 [RFC5392] Chen, M., Zhang, R., and X. Duan, "OSPF Extensions in 432 Support of Inter-Autonomous System (AS) MPLS and GMPLS 433 Traffic Engineering", RFC 5392, DOI 10.17487/RFC5392, 434 January 2009, . 436 [RFC6119] Harrison, J., Berger, J., and M. Bartlett, "IPv6 Traffic 437 Engineering in IS-IS", RFC 6119, DOI 10.17487/RFC6119, 438 February 2011, . 440 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 441 S. Ray, "North-Bound Distribution of Link-State and 442 Traffic Engineering (TE) Information Using BGP", RFC 7752, 443 DOI 10.17487/RFC7752, March 2016, 444 . 446 [RFC7794] Ginsberg, L., Ed., Decraene, B., Previdi, S., Xu, X., and 447 U. Chunduri, "IS-IS Prefix Attributes for Extended IPv4 448 and IPv6 Reachability", RFC 7794, DOI 10.17487/RFC7794, 449 March 2016, . 451 [RFC8362] Lindem, A., Roy, A., Goethals, D., Reddy Vallem, V., and 452 F. Baker, "OSPFv3 Link State Advertisement (LSA) 453 Extensibility", RFC 8362, DOI 10.17487/RFC8362, April 454 2018, . 456 Authors' Addresses 458 Aijun Wang 459 China Telecom 460 Beiqijia Town, Changping District 461 Beijing, Beijing 102209 462 China 464 Email: wangaj.bri@chinatelecom.cn 465 Huaimo Chen 466 Huawei Technologies 467 Boston, MA 468 USA 470 Email: Huaimo.chen@huawei.com 472 Shaowen Ma 473 Juniper Networks 475 Email: mashao@juniper.net