idnits 2.17.1 draft-xie-lsr-isis-sr-vtn-mt-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 : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 14 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 9, 2020) is 1502 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 276, but no explicit reference was found in the text == Outdated reference: A later version (-13) exists of draft-dong-spring-sr-for-enhanced-vpn-06 ** 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-06 == Outdated reference: A later version (-10) exists of draft-dong-lsr-sr-enhanced-vpn-02 == Outdated reference: A later version (-28) exists of draft-ietf-spring-srv6-network-programming-12 == Outdated reference: A later version (-17) exists of draft-ietf-teas-enhanced-vpn-05 Summary: 2 errors (**), 0 flaws (~~), 7 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: September 10, 2020 J. Dong 6 Z. Li 7 Huawei Technologies 8 March 9, 2020 10 Using IS-IS Multi-Topology (MT) for Segment Routing based Virtual 11 Transport Network 12 draft-xie-lsr-isis-sr-vtn-mt-00 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 applications's needs of 18 enhanced isolation and stringent performance requirements. VPN+ 19 requries 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 toplogy 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 September 10, 2020. 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 3.2. Associating VTNs with L2 Bundle Member Links . . . . . . 4 75 4. Scalability Considerations . . . . . . . . . . . . . . . . . 5 76 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 77 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 78 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5 79 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 80 8.1. Normative References . . . . . . . . . . . . . . . . . . 5 81 8.2. Informative References . . . . . . . . . . . . . . . . . 6 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 84 1. Introduction 86 Enhanced VPN (VPN+) is an enhancement to VPN services to support the 87 needs of new applications, particularly including the applications 88 that are associated with 5G services. These applications require 89 enhanced isolation and have more stringent performance requirements 90 than that can be provided with traditional overlay VPNs. These 91 properties cannot be met with pure overlay networks, as they require 92 integration between the underlay and the overlay networks. 93 [I-D.ietf-teas-enhanced-vpn] specifies the framework of enhanced VPN 94 and describes the candidate component technologies in different 95 network planes and layers. An enhanced VPN may be used for 5G 96 transport network slicing, and will also be of use in other generic 97 scenarios. 99 To meet the requirement of enhanced VPN services, a number of virtual 100 transport networks (VTN) need to be created, each with a subset of 101 the underlay network topology and a set of network resources 102 allocated to meet the requirement of a specific VPN+ service or a 103 group of VPN+ services. Another existing approach is to build a set 104 of point-to-point paths, each with a set of network resource reserved 105 along the path, such paths is called Virtual Transport Path (VTP). 106 Although using a set of dedicated VTPs can provide similar 107 characteristics, it has some scalability issues in large networks. 109 [I-D.dong-spring-sr-for-enhanced-vpn] specifies how segment routing 110 (SR) [RFC8402] can be used to build virtual transport networks (VTNs) 111 with the required network topology and network resource attributes to 112 support enhanced VPN services. With segment routing based data 113 plane, Segment Identifiers (SIDs) can be used to represent the 114 topology and the set of network resources allocated by network nodes 115 to a virtual network. The SIDs of each VTN and the associated 116 topology and resource attributes need to be distributed using control 117 plane. 119 [I-D.dong-lsr-sr-enhanced-vpn] defines the IGP mechanisms with 120 necessary extensions to build a set of Segment Routing (SR) based 121 VTNs. The VTNs could be used as the underlay of the enhanced VPN 122 service. The mechanism described in [I-D.dong-lsr-sr-enhanced-vpn] 123 allows flexible combination of the topology and resource attribute to 124 build customized VTNs. In some network scenarios, it is assumed that 125 each VTN has an independent topology and a set of dedicated network 126 resources. This document describes a simplified mechanism to build 127 the SR based VTNs in those scenarios. 129 The approach is to use IS-IS Multi-Topology [RFC5120] with segment 130 routing [RFC8667] to define the independent network topologies of 131 each VTN. The information of network resources allocated to a VTN 132 can be advertised by using IS-IS MT with the Traffic Engineering (TE) 133 extensions defiend in [RFC5305]. 135 2. Advertisement of SR VTN Topology Attribute 137 Multi-Topology Routing (MTR) [RFC5120] has been defined to create 138 independent topologies in one network. It also has the capability of 139 specifying the customized attributes of each topology. MTR can be 140 used with segment routing based data plane. The IS-IS extensions to 141 support the advertisement of topology-specific MPLS SIDs are 142 specified in [RFC8667]. Topology-specific Prefix-SIDs are advertised 143 by carrying the Prefix-SID sub-TLVs in the IS-IS TLV 235 (MT IP 144 Reachability) and TLV 237 (MT IPv6 IP Reachability). Topology- 145 specific Adj-SIDs are advertised by carrying the Adj-SID sub-TLVs in 146 IS-IS TLV 222 (MT-ISN) and TLV 223 (MT IS Neighbor Attribute). 148 The IS-IS extensions to support the advertisement of topology- 149 specific SRv6 Locators and SIDs are specified in 150 [I-D.ietf-lsr-isis-srv6-extensions]. The topology-specific SRv6 151 locators are advertised using SRv6 Locator TLV, and SRv6 End SIDs 152 inherit the MT-ID from the parent locator. The topology-specific 153 End.X SID are advertised by carrying SRv6 End.X SID sub-TLVs in the 154 IS-IS TLV 222 (MT-ISN) and TLV 223 (MT IS Neighbor Attribute). 156 When each VTN has an independent network topology, the MT-ID could be 157 used as the identifier of VTN in control plane. Thus the topology 158 attribute of a VTN could be advertised using MTR with segment 159 routing. 161 3. Advertisement of SR VTN Resource Attribute 163 In order to perform constraint based path computation for each VTN on 164 the network controller or on the ingress nodes, the network resource 165 attribute associated with of each VTN needs to be advertised. Two 166 optional approaches are described in the following sections. 168 3.1. Advertising Topology specific TE attributes 170 On each network link, the information of the network resources 171 associated with a VTN can be specified by carrying the TE attributes 172 sub-TLVs [RFC5305] in the IS-IS TLV 222 (MT-ISN) and TLV 223 (MT IS 173 Neighbor Attribute) of the corresponding topology. For example, the 174 Maximum Link Bandwidth sub-TLV could be used in the MT-ISN TLV to 175 signal the link bandwidth allocated to the corresponding VTN on a 176 link. 178 Editor's note1: It is noted that carrying per-topology TE attributes 179 was considered as a possible feature in future when the encoding of 180 IS-IS multi-topology was defined [RFC5120]. 182 3.2. Associating VTNs with L2 Bundle Member Links 184 In some network scenarios, the network resources allocated to 185 different VTNs are instantiated using different physical or virtual 186 members links of a Layer 3 interface. The TE attributes of each 187 member link can be advertised using [RFC8668]. In order to describe 188 the association of each VTN with the corresponding Layer 2 bundle 189 member link, the MT-ID TLV as defined in [RFC5120] SHOULD be carried 190 as a sub-TLV in the L2 Bundle Member Attributes TLV (25). The MT-ID 191 TLV contains one or more MT-IDs, each MT-ID is associated with the 192 corresponding Bundle Member Link Local Identifier carried in the L2 193 Bundle Attribute Descriptors. 195 4. Scalability Considerations 197 The mechanism described in this document requires that each VTN has 198 an independent topology. Even if multiple VTNs may have the same 199 topology attribute, they would still need to be identified using 200 different MT-IDs in the control plane. This requires that for each 201 VTN, independent path computation would be executed. The number of 202 VTNs supported in a network may be dependent on the control plane 203 computation overhead. 205 5. Security Considerations 207 This document introduces no additional security vulnerabilities to 208 IS-IS. 210 The mechanism proposed in this document is subject to the same 211 vulnerabilities as any other protocol that relies on IGPs. 213 6. IANA Considerations 215 This document does not request any IANA actions. 217 7. Acknowledgments 219 The authors would like to thank Zhibo Hu and Dean Cheng for the 220 review and discussion of this document. 222 8. References 224 8.1. Normative References 226 [I-D.dong-spring-sr-for-enhanced-vpn] 227 Dong, J., Bryant, S., Miyasaka, T., Zhu, Y., Qin, F., and 228 Z. Li, "Segment Routing for Resource Partitioned Virtual 229 Networks", draft-dong-spring-sr-for-enhanced-vpn-06 (work 230 in progress), December 2019. 232 [I-D.ietf-lsr-isis-srv6-extensions] 233 Psenak, P., Filsfils, C., Bashandy, A., Decraene, B., and 234 Z. Hu, "IS-IS Extension to Support Segment Routing over 235 IPv6 Dataplane", draft-ietf-lsr-isis-srv6-extensions-06 236 (work in progress), March 2020. 238 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 239 Requirement Levels", BCP 14, RFC 2119, 240 DOI 10.17487/RFC2119, March 1997, 241 . 243 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 244 Topology (MT) Routing in Intermediate System to 245 Intermediate Systems (IS-ISs)", RFC 5120, 246 DOI 10.17487/RFC5120, February 2008, 247 . 249 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 250 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 251 2008, . 253 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 254 Decraene, B., Litkowski, S., and R. Shakir, "Segment 255 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 256 July 2018, . 258 [RFC8667] Previdi, S., Ed., Ginsberg, L., Ed., Filsfils, C., 259 Bashandy, A., Gredler, H., and B. Decraene, "IS-IS 260 Extensions for Segment Routing", RFC 8667, 261 DOI 10.17487/RFC8667, December 2019, 262 . 264 [RFC8668] Ginsberg, L., Ed., Bashandy, A., Filsfils, C., Nanduri, 265 M., and E. Aries, "Advertising Layer 2 Bundle Member Link 266 Attributes in IS-IS", RFC 8668, DOI 10.17487/RFC8668, 267 December 2019, . 269 8.2. Informative References 271 [I-D.dong-lsr-sr-enhanced-vpn] 272 Dong, J., Hu, Z., and S. Bryant, "IGP Extensions for 273 Segment Routing based Enhanced VPN", draft-dong-lsr-sr- 274 enhanced-vpn-02 (work in progress), November 2019. 276 [I-D.ietf-spring-srv6-network-programming] 277 Filsfils, C., Camarillo, P., Leddy, J., Voyer, D., 278 Matsushima, S., and Z. Li, "SRv6 Network Programming", 279 draft-ietf-spring-srv6-network-programming-12 (work in 280 progress), March 2020. 282 [I-D.ietf-teas-enhanced-vpn] 283 Dong, J., Bryant, S., Li, Z., Miyasaka, T., and Y. Lee, "A 284 Framework for Enhanced Virtual Private Networks (VPN+) 285 Services", draft-ietf-teas-enhanced-vpn-05 (work in 286 progress), February 2020. 288 Authors' Addresses 290 Chongfeng Xie 291 China Telecom 292 China Telecom Beijing Information Science & Technology, Innovation park, Beiqijia Town 293 Beijing 102209 294 China 296 Email: xiechf@chinatelecom.cn 298 Chenhao Ma 299 China Telecom 300 China Telecom Beijing Information Science & Technology, Innovation park, Beiqijia Town 301 Beijing 102209 302 China 304 Email: machh@chinatelecom.cn 306 Jie Dong 307 Huawei Technologies 308 Huawei Campus, No. 156 Beiqing Road 309 Beijing 100095 310 China 312 Email: jie.dong@huawei.com 314 Zhenbin Li 315 Huawei Technologies 316 Huawei Campus, No. 156 Beiqing Road 317 Beijing 100095 318 China 320 Email: lizhenbin@huawei.com