idnits 2.17.1 draft-dong-idr-bgpls-sr-enhanced-vpn-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 (November 4, 2019) is 1632 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-lsr-isis-srv6-extensions' is defined on line 535, but no explicit reference was found in the text == Outdated reference: A later version (-10) exists of draft-dong-lsr-sr-enhanced-vpn-01 == Outdated reference: A later version (-13) exists of draft-dong-spring-sr-for-enhanced-vpn-05 ** Downref: Normative reference to an Informational draft: draft-dong-spring-sr-for-enhanced-vpn (ref. 'I-D.dong-spring-sr-for-enhanced-vpn') == Outdated reference: A later version (-18) exists of draft-ietf-idr-bgp-ls-segment-routing-ext-16 == Outdated reference: A later version (-17) exists of draft-ietf-teas-enhanced-vpn-03 ** Downref: Normative reference to an Informational draft: draft-ietf-teas-enhanced-vpn (ref. 'I-D.ietf-teas-enhanced-vpn') ** Obsolete normative reference: RFC 7752 (Obsoleted by RFC 9552) == Outdated reference: A later version (-14) exists of draft-ietf-idr-bgpls-srv6-ext-01 == Outdated reference: A later version (-26) exists of draft-ietf-lsr-flex-algo-04 == Outdated reference: A later version (-19) exists of draft-ietf-lsr-isis-srv6-extensions-03 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 J. Dong 3 Internet-Draft Z. Hu 4 Intended status: Standards Track Huawei Technologies 5 Expires: May 7, 2020 November 4, 2019 7 BGP-LS Extensions for Segment Routing based Enhanced VPN 8 draft-dong-idr-bgpls-sr-enhanced-vpn-00 10 Abstract 12 Enhanced VPN (VPN+) is an enhancement to VPN services to support the 13 needs of new applications, particularly including the applications 14 that are associated with 5G services. These applications require 15 better isolation and have more stringent performance requirements 16 than that can be provided with traditional overlay VPNs. An enhanced 17 VPN may be used for 5G transport network slicing, and will also be of 18 use in more generic scenarios. This document specifies BGP-LS based 19 mechanism with necessary extensions to advertise the information of 20 Segment Routing (SR) based virtual networks. These virtual networks 21 could be used as the underlay of enhanced VPN service. The proposed 22 mechanism is applicable to both segment routing with MPLS data plane 23 (SR-MPLS) and segment routing with IPv6 data plane (SRv6). 25 Requirements Language 27 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 28 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 29 document are to be interpreted as described in RFC 2119 [RFC2119]. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on May 7, 2020. 48 Copyright Notice 50 Copyright (c) 2019 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (https://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 2. Advertisement of Transport Network Slice Definition . . . . . 3 67 2.1. Sub-TLVs of TNSD TLV . . . . . . . . . . . . . . . . . . 4 68 3. Advertisement of Network Topology and Resource Attributes . . 6 69 3.1. Intra-domain Network Topology Advertisement . . . . . . . 6 70 3.1.1. MTR based Topology Advertisement . . . . . . . . . . 6 71 3.1.2. Flex-Algo based Topology Advertisement . . . . . . . 7 72 3.2. Intra-domain Resource Information Advertisement . . . . . 8 73 3.3. Inter-Domain Topology and Resource Information 74 Advertisement . . . . . . . . . . . . . . . . . . . . . . 9 75 4. Security Considerations . . . . . . . . . . . . . . . . . . . 10 76 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 77 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 78 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 79 7.1. Normative References . . . . . . . . . . . . . . . . . . 11 80 7.2. Informative References . . . . . . . . . . . . . . . . . 12 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 83 1. Introduction 85 Driven largely by needs arising from the 5G mobile network, the 86 concept of network slicing has gained traction 87 [NGMN-NS-Concept][TS23501][TS28530] . Network slicing requires to 88 partition the physical network to several pieces to provide each 89 network slice with the required networking, computing, and storage 90 resources and functions to meet the requirement of slice tenants. As 91 specified in [I-D.ietf-teas-enhanced-vpn], a transport network slice 92 is a virtual (logical) network with a particular network topology and 93 a set of shared or dedicated network resources, which are used to 94 provide the network slice consumer with the required connectivity, 95 appropriate isolation and specific Service Level Agreement (SLA). 97 The enhanced VPN service (VPN+) [I-D.ietf-teas-enhanced-vpn] is 98 targeted at new applications which require better isolation from both 99 control plane and data plane's perspective and have more stringent 100 performance requirements than can be provided with existing overlay 101 VPNs. To meet the requirement of enhance VPN services, a number of 102 virtual networks need be created, each with a subset of the underlay 103 network topology and a set of network resources allocated to meet the 104 requirement of a specific enhanced VPN or a group of enhanced VPNs. 105 In the context of 5G, each virtual network can be considered as a 106 transport network slice. 108 [I-D.dong-spring-sr-for-enhanced-vpn] describes the mechanisms to 109 build Segment Routing (SR) based virtual networks, which could be 110 used to as the underlay of different enhanced VPN services. 111 [I-D.dong-lsr-sr-enhanced-vpn] specifies the IGP mechanism and 112 extensions to build a set of SR based virtual networks with 113 customized topology and resource attributes. When the virtual 114 networks span multiple areas or multiple Autonomous Systems(ASes), 115 BGP-LS is needed to advertise the virtual network information of each 116 IGP area or AS to the network controller to build the inter-area or 117 inter-AS SR based transport network slices. 119 This document describes BGP-LS [RFC7752] based mechanism with 120 necessary extensions to advertise the topology and resource 121 information of intra-domain and inter-domain Segment Routing (SR) 122 based transport network slices. The definition of transport network 123 slice is advertised as a node attribute using BGP-LS. The attributes 124 of network resources allocated to a transport network slice is 125 advertised as a link attribute using BGP-LS. 127 2. Advertisement of Transport Network Slice Definition 129 The definition of a transport network slice or virtual network 130 consists of the combination of a set of network attributes. The 131 topology attribute and resource attribute are two major types of 132 attributes of a transport network slice, and they can be decoupled in 133 the control plane advertisement and processing. Transport Network 134 Slice Definition (TNSD) TLV is a new TLV of the optional BGP-LS 135 Attribute which is associated with the node NLRI. 137 The format of TNSD TLV is as follows: 139 0 1 2 3 140 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 141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 142 | Type | Length | 143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 144 | Flags | Reserved | 145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 146 | Transport Network Slice Identifier | 147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 148 | Sub-TLVs | 149 ~ ... ~ 150 | | 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 153 Where: 155 o Type: TBD 157 o Length: the length of the value field of the sub-TLV. It is 158 variable dependent on the included Sub-TLVs. 160 o Flags: 16-bit flags to indicate the attributes of the transport 161 network slice. All flags are reserved and MUST be set to zero on 162 transmission and ignored on reception. 164 o Reserved: this field is reserved for future use, MUST be set to 165 zero on transmission and ignored on reception. 167 o Transport Network Slice Identifier (TNSI): A 32-bit identifier 168 which is used to identify a transport network slice. 170 o Sub-TLVs: optional sub-TLVs to specify the attributes of a virtual 171 network. 173 2.1. Sub-TLVs of TNSD TLV 175 The sub-TLVs of the TNSD TLV is used to advertise the identifiers of 176 different types of attributes of the transport network slice. Two 177 sub-TLVs of the TNSD TLV are defined in this document: Network 178 Topology sub-TLV and Network Resource sub-TLV. 180 The format of the Network Topology sub-TLV is as below: 182 0 1 2 3 183 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 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 | Type | Length | 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 |M|A| Flags | MT-ID | 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 | Algorithm | Reserved | 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 Where: 194 o Type: 1 196 o Length: the length of the value field of the sub-TLV. 198 o Flags: 16-bit flags to indicate the attribute of the virtual 199 network topology. Where: 201 M flag: indicates the topology is determined by the MT-ID when 202 set. 204 A flag: indicates the topology is determined by the Algorithm 205 when set. In this case, the value of the Algorithm field 206 SHOULD be between 128 and 255. 208 o MT-ID: 16-bit identifier which indicates the multi-topology 209 identifier of the IGP topology. 211 o Algorithm: 8-bit identifier which indicates the algorithm which is 212 used within this network topology. 214 o Reserved: this field is reserved for future use, MUST be set to 215 zero on transmission and ignored on reception. 217 The format of the Network Resource sub-TLV is as below: 219 0 1 2 3 220 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 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 | Type | Length | 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 | Flags | Reserved | 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 | Resource Identifier | 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 Where: 231 Type: 2 233 Length: 6 octets. 235 Flags: 16 bit flags. All the bits are reserved, which MUST be set 236 to 0 on transmission and ignored on receipt. 238 Reserved: this field is reserved for future use, MUST be set to 239 zero on transmission and ignored on reception. 241 Resource Identifier: A 32-bit identifier which is used to identify 242 the group of network resources allocated to a transport network 243 slice. 245 3. Advertisement of Network Topology and Resource Attributes 247 [I-D.dong-lsr-sr-enhanced-vpn] describes the candidate IGP mechanisms 248 to distribute the topology attributes of SR based transport network 249 slices. This section describes the BGP-LS mechanism to distribute 250 both the intra-domain and inter-domain topology and resource 251 attribute of SR based transport network slices. 253 3.1. Intra-domain Network Topology Advertisement 255 3.1.1. MTR based Topology Advertisement 257 In section 3.2.1.5 of [RFC7752], the Multi-Topology Identifier (MT- 258 ID) TLV is defined, which can contain one or more IS-IS or OSPF 259 Multi-Topology IDs. The MT-ID TLV MAY be present in a Link 260 Descriptor, a Prefix Descriptor, or the BGP-LS attribute of a Node 261 NLRI. 263 [I-D.ietf-idr-bgp-ls-segment-routing-ext] defines the BGP-LS 264 extensions to carry the segment routing information using TLVs of 265 BGP-LS Attribute. When MTR is used with SR-MPLS data plane, 266 topology-specific prefix SIDs and topology-specific adjacency SIDs 267 can be carried in the BGP-LS Attribute associated with the prefix 268 NLRI and link NLRI respectively, the MT-ID TLV is carried in the 269 prefix descriptor and link descriptor to identify the corresponding 270 topology of the SIDs. 272 [I-D.ietf-idr-bgpls-srv6-ext] defines the BGP-LS extensions to 273 advertise SRv6 segments along with their functions and attributes. 274 When MTR is used with SRv6 data plane, the SRv6 Locator TLV is 275 carried in the BGP-LS Attribute associated with the prefix-NLRI, the 276 MT-ID TLV can be carried in the prefix descriptor to identify the 277 corresponding topology of the SRv6 Locator. The SRv6 End.X SIDs are 278 carried in the BGP-LS Attribute associated with the link NLRI, the 279 MT-ID TLV can be carried in the link descriptor to identify the 280 corresponding topology of the SIDs. The SRv6 SID NLRI is defined to 281 advertise other types of SRv6 SIDs, in which the SRv6 SID Descriptors 282 can include the MT-ID TLV so as to advertise topology-specific SRv6 283 SIDs. 285 [RFC7752] also defines the rules of the usage of MT-ID TLV: 287 "In a Link or Prefix Descriptor, only a single MT-ID TLV containing 288 the MT-ID of the topology where the link or the prefix is reachable 289 is allowed. In case one wants to advertise multiple topologies for a 290 given Link Descriptor or Prefix Descriptor, multiple NLRIs need to be 291 generated where each NLRI contains an unique MT-ID. In the BGP-LS 292 attribute of a Node NLRI, one MT-ID TLV containing the array of MT- 293 IDs of all topologies where the node is reachable is allowed." 295 This indicates that only one MT-ID is allowed to be carried the Link 296 or Prefix descriptors. When a link or prefix participates in 297 multiple topologies, multiple NLRIs needs to be generated to report 298 all the topologies a link or prefix participates in, together with 299 the topology-specific segment routing information. This would 300 increase the number of BGP Updates and may introduce additional 301 processing burden to both the sending BGP speaker and the receiving 302 network controller. When the number of topologies in a network is 303 not a small number, some optimization may be introduced for the 304 reporting of multi-topology information and the associated segment 305 routing information in BGP-LS. This will be elaborated in a future 306 version. 308 3.1.2. Flex-Algo based Topology Advertisement 310 As specified in [I-D.dong-lsr-sr-enhanced-vpn], Flex-Algo 311 [I-D.ietf-lsr-flex-algo] can also be used to advertise the 312 topological constraints of a virtual network. The BGP-LS extensions 313 for SR-MPLS [I-D.ietf-idr-bgp-ls-segment-routing-ext] and SRv6 314 [I-D.ietf-idr-bgpls-srv6-ext]provide the mechanisms to advertise the 315 Flex-Algo definition information and the algorithm-specific segment 316 routing information. 318 The Flex-Algo definition can be used to describe the topological 319 constraints for path computation. According to the network nodes' 320 participation of a Flex-Algo, and the rules of including or excluding 321 specific Admin Groups (colors), a network topology can be determined 322 by a Flex-Algo. 324 In[I-D.ietf-idr-bgp-ls-segment-routing-ext], algorithm-specific 325 prefix-SIDs can be advertised as Link attributes of the associated 326 Link NLRI. In [I-D.ietf-idr-bgpls-srv6-ext], algorithm-specific SRv6 327 Locators can be advertised as Link attributes of the associated 328 prefix NLRI, and algorithm-specific End.X SIDs can be advertised as 329 Link attributes of the associated Link NLRI. Other types of SRv6 330 SIDs are advertised using SRv6 SID NLRI and can also be algorithm- 331 specific. 333 3.2. Intra-domain Resource Information Advertisement 335 [I-D.dong-lsr-sr-enhanced-vpn] specifies the mechanism to advertise 336 the resource information associated with each transport network 337 slice. It is based on the extensions to the advertisement of L2 338 bundle member links information. This section defines the 339 corresponding BGP-LS extensions. 341 In [I-D.ietf-idr-bgp-ls-segment-routing-ext], L2 bundle member 342 Attribute TLV is used to advertise the attributes of a member link of 343 a parent L3 link. Two new sub-TLVs are defined under the L2 bundle 344 member Attribute TLV. 346 The link attribute sub-TLV is use to carry the link characteristics 347 of a L2 member link. The format of the sub-TLV is as below: 349 0 1 2 3 350 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 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 | Type | Length | 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 | Flags | 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 Where: 359 Type: TBD 361 Length: 4 octets. 363 Flags: 16-bit flags. This field is consistent with the Flag field 364 in IS-IS Link Attribute sub-TLV in [RFC5029]. In addition to the 365 flags defined in [RFC5029], A new Flag V is defined in this 366 document. When the V flag is set, it indicates this link is a L2 367 virtual member link. 369 The Resource Identifier (ResID) sub-TLV is used to describe to which 370 resource group a particular member links belongs to. 372 A global-significant Resource Identifier (ResID) is introduced to 373 identify a resource group which is the collection of all the network 374 resources allocated to a transport network slice. 376 The format of Resource Identifier sub-TLV is as below: 378 0 1 2 3 379 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 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 | Type | Length | 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 | Flags | Reserved | 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 | Resource Identifier | 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 Where: 390 o Type: TBD 392 o Length: 12 octets. 394 o Flags: 16 bit flags. All the bits are reserved, which MUST be set 395 to 0 on transmission and ignored on receipt. 397 o Reserved: this field is reserved for future use. MUST be set to 0 398 on transmission and ignored on receipt. 400 o Bundle Member Link Local Identifier: A 32-bit local identifier of 401 a member link. The link can be physical or virtual. 403 o Resource Identifier: A 32-bit global-significant identifier to 404 identify the resource group this member link belongs to. 406 3.3. Inter-Domain Topology and Resource Information Advertisement 408 [I-D.ietf-idr-bgpls-segment-routing-epe] defines the BGP-LS 409 extensions for advertisement of BGP Peering Segments and the peering 410 topology information between ASes. Such information could be used by 411 a network controller for the computation and instantiation of inter- 412 AS traffic engineering SR paths. 414 In some scenarios, transport network slices which spans multiple ASes 415 need to be created. The inter-domain network slices may have 416 different inter-domain connectivity, and may be associated with 417 different set of network resources in each domain and on the inter- 418 domain links. In order to build the inter-domain transport network 419 slices using segment routing, it is necessary to advertise the 420 topology and resource attribute of the inter-domain links and the 421 associated BGP Peering Segments. 423 Depending on the requirement of inter-domain network slices, 424 different levels of isolation on the inter-domain connection can be 425 achieved: 427 o One EBGP session between two ASes can be established over several 428 underlying links. In this case, different underlying links can be 429 used for different inter-domain transport network slices which 430 requires hard isolation between each other. In another similar 431 case, the EBGP session is established over a single link, while 432 the resource on this link can be splited into several pieces, each 433 of which can be considered as a virtual member link. In both 434 cases, different BGP Peer-Adj-SIDs are allocated to each 435 underlying physical or virtual link, and the ASBRs SHOULD 436 advertise the transport network slice identifiers associated with 437 each BGP Peer-Adj-SID. 439 o For inter-domain connection between two ASes, multiple EBGP 440 sessions can be established between different peering ASBRs. It 441 is possible that some of these BGP sessions are used for one 442 inter-domain transport network slice, while some other BGP 443 sessions are used for another inter-domain transport network 444 slice. Different BGP peer-node-SIDs are allocated to each BGP 445 session, and ASBR SHOULD advertise the information of topology 446 identifiers associated with different BGP Peer-node-SIDs. 448 o Different inter-domain transport network slices can have different 449 inter-domain connectivity at the AS level. Different BGP Peer- 450 Set-SID can be allocated to represent the groups of BGP peers 451 which can be used for load-balancing in each transport network 452 slice. 454 The detailed protocol extensions for advertising the inter-domain 455 network slice information will be specified in a future version. 457 4. Security Considerations 459 This document introduces no additional security vulnerabilities to 460 BGP-LS. 462 The mechanism proposed in this document is subject to the same 463 vulnerabilities as any other protocol that relies on BGP-LS. 465 5. IANA Considerations 467 TBD 469 6. Acknowledgments 471 The authors would like to thank Shunwan Zhuang for the review and 472 discussion of this document. 474 7. References 476 7.1. Normative References 478 [I-D.dong-lsr-sr-enhanced-vpn] 479 Dong, J. and S. Bryant, "IGP Extensions for Segment 480 Routing based Enhanced VPN", draft-dong-lsr-sr-enhanced- 481 vpn-01 (work in progress), October 2018. 483 [I-D.dong-spring-sr-for-enhanced-vpn] 484 Dong, J., Bryant, S., Miyasaka, T., Zhu, Y., Qin, F., and 485 Z. Li, "Segment Routing for Enhanced VPN Service", draft- 486 dong-spring-sr-for-enhanced-vpn-05 (work in progress), 487 October 2019. 489 [I-D.ietf-idr-bgp-ls-segment-routing-ext] 490 Previdi, S., Talaulikar, K., Filsfils, C., Gredler, H., 491 and M. Chen, "BGP Link-State extensions for Segment 492 Routing", draft-ietf-idr-bgp-ls-segment-routing-ext-16 493 (work in progress), June 2019. 495 [I-D.ietf-idr-bgpls-segment-routing-epe] 496 Previdi, S., Talaulikar, K., Filsfils, C., Patel, K., Ray, 497 S., and J. Dong, "BGP-LS extensions for Segment Routing 498 BGP Egress Peer Engineering", draft-ietf-idr-bgpls- 499 segment-routing-epe-19 (work in progress), May 2019. 501 [I-D.ietf-teas-enhanced-vpn] 502 Dong, J., Bryant, S., Li, Z., Miyasaka, T., and Y. Lee, "A 503 Framework for Enhanced Virtual Private Networks (VPN+) 504 Service", draft-ietf-teas-enhanced-vpn-03 (work in 505 progress), September 2019. 507 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 508 Requirement Levels", BCP 14, RFC 2119, 509 DOI 10.17487/RFC2119, March 1997, 510 . 512 [RFC5029] Vasseur, JP. and S. Previdi, "Definition of an IS-IS Link 513 Attribute Sub-TLV", RFC 5029, DOI 10.17487/RFC5029, 514 September 2007, . 516 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 517 S. Ray, "North-Bound Distribution of Link-State and 518 Traffic Engineering (TE) Information Using BGP", RFC 7752, 519 DOI 10.17487/RFC7752, March 2016, 520 . 522 7.2. Informative References 524 [I-D.ietf-idr-bgpls-srv6-ext] 525 Dawra, G., Filsfils, C., Talaulikar, K., Chen, M., 526 daniel.bernier@bell.ca, d., and B. Decraene, "BGP Link 527 State Extensions for SRv6", draft-ietf-idr-bgpls- 528 srv6-ext-01 (work in progress), July 2019. 530 [I-D.ietf-lsr-flex-algo] 531 Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and 532 A. Gulko, "IGP Flexible Algorithm", draft-ietf-lsr-flex- 533 algo-04 (work in progress), September 2019. 535 [I-D.ietf-lsr-isis-srv6-extensions] 536 Psenak, P., Filsfils, C., Bashandy, A., Decraene, B., and 537 Z. Hu, "IS-IS Extension to Support Segment Routing over 538 IPv6 Dataplane", draft-ietf-lsr-isis-srv6-extensions-03 539 (work in progress), October 2019. 541 [NGMN-NS-Concept] 542 "NGMN NS Concept", 2016, . 546 [TS23501] "3GPP TS23.501", 2016, 547 . 550 [TS28530] "3GPP TS28.530", 2016, 551 . 554 Authors' Addresses 556 Jie Dong 557 Huawei Technologies 559 Email: jie.dong@huawei.com 560 Zhibo Hu 561 Huawei Technologies 563 Email: huzhibo@huawei.com