idnits 2.17.1 draft-xie-lsr-isis-sr-vtn-mt-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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 13, 2020) is 1380 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-spring-srv6-network-programming' is defined on line 260, but no explicit reference was found in the text == Outdated reference: A later version (-13) exists of draft-dong-spring-sr-for-enhanced-vpn-08 ** 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 (-19) exists of draft-ietf-lsr-isis-srv6-extensions-08 == Outdated reference: A later version (-10) exists of draft-dong-lsr-sr-enhanced-vpn-04 == Outdated reference: A later version (-28) exists of draft-ietf-spring-srv6-network-programming-16 == Outdated reference: A later version (-17) exists of draft-ietf-teas-enhanced-vpn-05 Summary: 1 error (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 LSR Working Group C. Xie 3 Internet-Draft C. Ma 4 Intended status: Standards Track China Telecom 5 Expires: January 14, 2021 J. Dong 6 Z. Li 7 Huawei Technologies 8 July 13, 2020 10 Using IS-IS Multi-Topology (MT) for Segment Routing based Virtual 11 Transport Network 12 draft-xie-lsr-isis-sr-vtn-mt-01 14 Abstract 16 Enhanced VPN (VPN+) as defined in I-D.ietf-teas-enhanced-vpn aims to 17 provide enhanced VPN service to support some application's needs of 18 enhanced isolation and stringent performance requirements. VPN+ 19 requires integration between the overlay VPN and the underlay 20 network. A Virtual Transport Network (VTN) is a virtual network 21 which consists of a subset of the network topology and network 22 resources allocated from the underlay network. A VTN could be used 23 as the underlay for one or a group of VPN+ services. 25 I-D.dong-lsr-sr-enhanced-vpn defines the IGP extensions to build a 26 set of Segment Routing (SR) based VTNs. This document describes a 27 simplified mechanism to build the SR based VTNs using IGP multi- 28 topology together with other well-defined IS-IS extensions. 30 Requirements Language 32 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 33 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 34 document are to be interpreted as described in RFC 2119 [RFC2119]. 36 Status of This Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at https://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on January 14, 2021. 53 Copyright Notice 55 Copyright (c) 2020 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (https://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 71 2. Advertisement of SR VTN Topology Attribute . . . . . . . . . 3 72 3. Advertisement of SR VTN Resource Attribute . . . . . . . . . 4 73 3.1. Advertising Topology-specific TE attributes . . . . . . . 4 74 4. Scalability Considerations . . . . . . . . . . . . . . . . . 4 75 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 76 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 77 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5 78 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 79 8.1. Normative References . . . . . . . . . . . . . . . . . . 5 80 8.2. Informative References . . . . . . . . . . . . . . . . . 6 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 83 1. Introduction 85 Enhanced VPN (VPN+) is an enhancement to VPN services to support the 86 needs of new applications, particularly including the applications 87 that are associated with 5G services. These applications require 88 enhanced isolation and have more stringent performance requirements 89 than that can be provided with traditional overlay VPNs. These 90 properties cannot be met with pure overlay networks, as they require 91 integration between the underlay and the overlay networks. 92 [I-D.ietf-teas-enhanced-vpn] specifies the framework of enhanced VPN 93 and describes the candidate component technologies in different 94 network planes and layers. An enhanced VPN may be used for 5G 95 transport network slicing, and will also be of use in other generic 96 scenarios. 98 To meet the requirement of enhanced VPN services, a number of virtual 99 transport networks (VTN) need to be created, each with a subset of 100 the underlay network topology and a set of network resources 101 allocated to meet the requirement of a specific VPN+ service or a 102 group of VPN+ services. Another existing approach is to build a set 103 of point-to-point paths, each with a set of network resource reserved 104 along the path, such paths is called Virtual Transport Path (VTP). 105 Although using a set of dedicated VTPs can provide similar 106 characteristics, it has some scalability issues in large networks. 108 [I-D.dong-spring-sr-for-enhanced-vpn] specifies how segment routing 109 (SR) [RFC8402] can be used to build virtual transport networks (VTNs) 110 with the required network topology and network resource attributes to 111 support enhanced VPN services. With segment routing based data 112 plane, Segment Identifiers (SIDs) can be used to represent the 113 topology and the set of network resources allocated by network nodes 114 to a virtual network. The SIDs of each VTN and the associated 115 topology and resource attributes need to be distributed using control 116 plane. 118 [I-D.dong-lsr-sr-enhanced-vpn] defines the IGP mechanisms with 119 necessary extensions to build a set of Segment Routing (SR) based 120 VTNs. The VTNs could be used as the underlay of the enhanced VPN 121 service. The mechanism described in [I-D.dong-lsr-sr-enhanced-vpn] 122 allows flexible combination of the topology and resource attribute to 123 build customized VTNs. In some network scenarios, it is assumed that 124 each VTN has an independent topology and a set of dedicated network 125 resources. This document describes a simplified mechanism to build 126 the SR based VTNs in those scenarios. 128 The approach is to use IS-IS Multi-Topology [RFC5120] with segment 129 routing [RFC8667] to define the independent network topologies of 130 each VTN. The information of network resources allocated to a VTN 131 can be advertised by using IS-IS MT with the Traffic Engineering (TE) 132 extensions defined in [RFC5305]. 134 2. Advertisement of SR VTN Topology Attribute 136 Multi-Topology Routing (MTR) [RFC5120] has been defined to create 137 independent topologies in one network. It also has the capability of 138 specifying the customized attributes of each topology. MTR can be 139 used with segment routing based data plane. The IS-IS extensions to 140 support the advertisement of topology-specific MPLS SIDs are 141 specified in [RFC8667]. Topology-specific Prefix-SIDs are advertised 142 by carrying the Prefix-SID sub-TLVs in the IS-IS TLV 235 (MT IP 143 Reachability) and TLV 237 (MT IPv6 IP Reachability). Topology- 144 specific Adj-SIDs are advertised by carrying the Adj-SID sub-TLVs in 145 IS-IS TLV 222 (MT-ISN) and TLV 223 (MT IS Neighbor Attribute). 147 The IS-IS extensions to support the advertisement of topology- 148 specific SRv6 Locators and SIDs are specified in 149 [I-D.ietf-lsr-isis-srv6-extensions]. The topology-specific SRv6 150 locators are advertised using SRv6 Locator TLV, and SRv6 End SIDs 151 inherit the MT-ID from the parent locator. The topology-specific 152 End.X SID are advertised by carrying SRv6 End.X SID sub-TLVs in the 153 IS-IS TLV 222 (MT-ISN) and TLV 223 (MT IS Neighbor Attribute). 155 When each VTN has an independent network topology, the MT-ID could be 156 used as the identifier of VTN in control plane. Thus the topology 157 attribute of a VTN could be advertised using MTR with segment 158 routing. 160 3. Advertisement of SR VTN Resource Attribute 162 In order to perform constraint based path computation for each VTN on 163 the network controller or on the ingress nodes, the network resource 164 attribute associated with each VTN needs to be advertised. 166 3.1. Advertising Topology-specific TE attributes 168 On each network link, the information of the network resources 169 associated with a VTN can be specified by carrying the TE attributes 170 sub-TLVs [RFC5305] in the IS-IS TLV 222 (MT-ISN) and TLV 223 (MT IS 171 Neighbor Attribute) of the corresponding topology. 173 When Maximum Link Bandwidth sub-TLV is carried in the MT-ISN TLV, it 174 indicates the amount of link bandwidth allocated to the corresponding 175 VTN. The bandwidth allocated to a VTN can be exclusive for services 176 carried in the corresponding VTN. The usage of other TE attributes 177 in topology-specific TLVs is for further study. 179 Editor's note1: It is noted that carrying per-topology TE attributes 180 was considered as a possible feature in future when the encoding of 181 IS-IS multi-topology was defined [RFC5120]. 183 4. Scalability Considerations 185 The mechanism described in this document requires that each VTN has 186 an independent topology. Even if multiple VTNs may have the same 187 topology attribute, they would still need to be identified using 188 different MT-IDs in the control plane. This requires that for each 189 VTN, independent path computation would be executed. The number of 190 VTNs supported in a network may be dependent on the control plane 191 computation overhead. 193 5. Security Considerations 195 This document introduces no additional security vulnerabilities to 196 IS-IS. 198 The mechanism proposed in this document is subject to the same 199 vulnerabilities as any other protocol that relies on IGPs. 201 6. IANA Considerations 203 This document does not request any IANA actions. 205 7. Acknowledgments 207 The authors would like to thank Zhibo Hu, Dean Cheng, Les Ginsberg 208 and Peter Psenak for the review and discussion of this document. 210 8. References 212 8.1. Normative References 214 [I-D.dong-spring-sr-for-enhanced-vpn] 215 Dong, J., Bryant, S., Miyasaka, T., Zhu, Y., Qin, F., and 216 Z. Li, "Segment Routing for Resource Guaranteed Virtual 217 Networks", draft-dong-spring-sr-for-enhanced-vpn-08 (work 218 in progress), June 2020. 220 [I-D.ietf-lsr-isis-srv6-extensions] 221 Psenak, P., Filsfils, C., Bashandy, A., Decraene, B., and 222 Z. Hu, "IS-IS Extension to Support Segment Routing over 223 IPv6 Dataplane", draft-ietf-lsr-isis-srv6-extensions-08 224 (work in progress), April 2020. 226 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 227 Requirement Levels", BCP 14, RFC 2119, 228 DOI 10.17487/RFC2119, March 1997, 229 . 231 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 232 Topology (MT) Routing in Intermediate System to 233 Intermediate Systems (IS-ISs)", RFC 5120, 234 DOI 10.17487/RFC5120, February 2008, 235 . 237 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 238 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 239 2008, . 241 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 242 Decraene, B., Litkowski, S., and R. Shakir, "Segment 243 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 244 July 2018, . 246 [RFC8667] Previdi, S., Ed., Ginsberg, L., Ed., Filsfils, C., 247 Bashandy, A., Gredler, H., and B. Decraene, "IS-IS 248 Extensions for Segment Routing", RFC 8667, 249 DOI 10.17487/RFC8667, December 2019, 250 . 252 8.2. Informative References 254 [I-D.dong-lsr-sr-enhanced-vpn] 255 Dong, J., Hu, Z., Li, Z., Tang, X., Pang, R., JooHeon, L., 256 and S. Bryant, "IGP Extensions for Segment Routing based 257 Enhanced VPN", draft-dong-lsr-sr-enhanced-vpn-04 (work in 258 progress), June 2020. 260 [I-D.ietf-spring-srv6-network-programming] 261 Filsfils, C., Camarillo, P., Leddy, J., Voyer, D., 262 Matsushima, S., and Z. Li, "SRv6 Network Programming", 263 draft-ietf-spring-srv6-network-programming-16 (work in 264 progress), June 2020. 266 [I-D.ietf-teas-enhanced-vpn] 267 Dong, J., Bryant, S., Li, Z., Miyasaka, T., and Y. Lee, "A 268 Framework for Enhanced Virtual Private Networks (VPN+) 269 Services", draft-ietf-teas-enhanced-vpn-05 (work in 270 progress), February 2020. 272 Authors' Addresses 274 Chongfeng Xie 275 China Telecom 276 China Telecom Beijing Information Science & Technology, Beiqijia 277 Beijing 102209 278 China 280 Email: xiechf@chinatelecom.cn 281 Chenhao Ma 282 China Telecom 283 China Telecom Beijing Information Science & Technology, Beiqijia 284 Beijing 102209 285 China 287 Email: machh@chinatelecom.cn 289 Jie Dong 290 Huawei Technologies 291 Huawei Campus, No. 156 Beiqing Road 292 Beijing 100095 293 China 295 Email: jie.dong@huawei.com 297 Zhenbin Li 298 Huawei Technologies 299 Huawei Campus, No. 156 Beiqing Road 300 Beijing 100095 301 China 303 Email: lizhenbin@huawei.com