| LSR Working Group | C. Xie |
| Internet-Draft | C. Ma |
| Intended status: Standards Track | China Telecom |
| Expires: January 14, 2021 | J. Dong |
| Z. Li | |
| Huawei Technologies | |
| July 13, 2020 |
Using IS-IS Multi-Topology (MT) for Segment Routing based Virtual Transport Network
draft-xie-lsr-isis-sr-vtn-mt-01
Enhanced VPN (VPN+) as defined in I-D.ietf-teas-enhanced-vpn aims to provide enhanced VPN service to support some application's needs of enhanced isolation and stringent performance requirements. VPN+ requires integration between the overlay VPN and the underlay network. A Virtual Transport Network (VTN) is a virtual network which consists of a subset of the network topology and network resources allocated from the underlay network. A VTN could be used as the underlay for one or a group of VPN+ services.
I-D.dong-lsr-sr-enhanced-vpn defines the IGP extensions to build a set of Segment Routing (SR) based VTNs. This document describes a simplified mechanism to build the SR based VTNs using IGP multi-topology together with other well-defined IS-IS extensions.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 14, 2021.
Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
Enhanced VPN (VPN+) is an enhancement to VPN services to support the needs of new applications, particularly including the applications that are associated with 5G services. These applications require enhanced isolation and have more stringent performance requirements than that can be provided with traditional overlay VPNs. These properties cannot be met with pure overlay networks, as they require integration between the underlay and the overlay networks. [I-D.ietf-teas-enhanced-vpn] specifies the framework of enhanced VPN and describes the candidate component technologies in different network planes and layers. An enhanced VPN may be used for 5G transport network slicing, and will also be of use in other generic scenarios.
To meet the requirement of enhanced VPN services, a number of virtual transport networks (VTN) need to be created, each with a subset of the underlay network topology and a set of network resources allocated to meet the requirement of a specific VPN+ service or a group of VPN+ services. Another existing approach is to build a set of point-to-point paths, each with a set of network resource reserved along the path, such paths is called Virtual Transport Path (VTP). Although using a set of dedicated VTPs can provide similar characteristics, it has some scalability issues in large networks.
[I-D.dong-spring-sr-for-enhanced-vpn] specifies how segment routing (SR) [RFC8402] can be used to build virtual transport networks (VTNs) with the required network topology and network resource attributes to support enhanced VPN services. With segment routing based data plane, Segment Identifiers (SIDs) can be used to represent the topology and the set of network resources allocated by network nodes to a virtual network. The SIDs of each VTN and the associated topology and resource attributes need to be distributed using control plane.
[I-D.dong-lsr-sr-enhanced-vpn] defines the IGP mechanisms with necessary extensions to build a set of Segment Routing (SR) based VTNs. The VTNs could be used as the underlay of the enhanced VPN service. The mechanism described in [I-D.dong-lsr-sr-enhanced-vpn] allows flexible combination of the topology and resource attribute to build customized VTNs. In some network scenarios, it is assumed that each VTN has an independent topology and a set of dedicated network resources. This document describes a simplified mechanism to build the SR based VTNs in those scenarios.
The approach is to use IS-IS Multi-Topology [RFC5120] with segment routing [RFC8667] to define the independent network topologies of each VTN. The information of network resources allocated to a VTN can be advertised by using IS-IS MT with the Traffic Engineering (TE) extensions defined in [RFC5305].
Multi-Topology Routing (MTR) [RFC5120] has been defined to create independent topologies in one network. It also has the capability of specifying the customized attributes of each topology. MTR can be used with segment routing based data plane. The IS-IS extensions to support the advertisement of topology-specific MPLS SIDs are specified in [RFC8667]. Topology-specific Prefix-SIDs are advertised by carrying the Prefix-SID sub-TLVs in the IS-IS TLV 235 (MT IP Reachability) and TLV 237 (MT IPv6 IP Reachability). Topology-specific Adj-SIDs are advertised by carrying the Adj-SID sub-TLVs in IS-IS TLV 222 (MT-ISN) and TLV 223 (MT IS Neighbor Attribute).
The IS-IS extensions to support the advertisement of topology-specific SRv6 Locators and SIDs are specified in [I-D.ietf-lsr-isis-srv6-extensions]. The topology-specific SRv6 locators are advertised using SRv6 Locator TLV, and SRv6 End SIDs inherit the MT-ID from the parent locator. The topology-specific End.X SID are advertised by carrying SRv6 End.X SID sub-TLVs in the IS-IS TLV 222 (MT-ISN) and TLV 223 (MT IS Neighbor Attribute).
When each VTN has an independent network topology, the MT-ID could be used as the identifier of VTN in control plane. Thus the topology attribute of a VTN could be advertised using MTR with segment routing.
In order to perform constraint based path computation for each VTN on the network controller or on the ingress nodes, the network resource attribute associated with each VTN needs to be advertised.
On each network link, the information of the network resources associated with a VTN can be specified by carrying the TE attributes sub-TLVs [RFC5305] in the IS-IS TLV 222 (MT-ISN) and TLV 223 (MT IS Neighbor Attribute) of the corresponding topology.
When Maximum Link Bandwidth sub-TLV is carried in the MT-ISN TLV, it indicates the amount of link bandwidth allocated to the corresponding VTN. The bandwidth allocated to a VTN can be exclusive for services carried in the corresponding VTN. The usage of other TE attributes in topology-specific TLVs is for further study.
Editor's note1: It is noted that carrying per-topology TE attributes was considered as a possible feature in future when the encoding of IS-IS multi-topology was defined [RFC5120].
The mechanism described in this document requires that each VTN has an independent topology. Even if multiple VTNs may have the same topology attribute, they would still need to be identified using different MT-IDs in the control plane. This requires that for each VTN, independent path computation would be executed. The number of VTNs supported in a network may be dependent on the control plane computation overhead.
This document introduces no additional security vulnerabilities to IS-IS.
The mechanism proposed in this document is subject to the same vulnerabilities as any other protocol that relies on IGPs.
This document does not request any IANA actions.
The authors would like to thank Zhibo Hu, Dean Cheng, Les Ginsberg and Peter Psenak for the review and discussion of this document.
| [I-D.dong-lsr-sr-enhanced-vpn] | Dong, J., Hu, Z., Li, Z., Tang, X., Pang, R., JooHeon, L. and S. Bryant, "IGP Extensions for Segment Routing based Enhanced VPN", Internet-Draft draft-dong-lsr-sr-enhanced-vpn-04, June 2020. |
| [I-D.ietf-spring-srv6-network-programming] | Filsfils, C., Camarillo, P., Leddy, J., Voyer, D., Matsushima, S. and Z. Li, "SRv6 Network Programming", Internet-Draft draft-ietf-spring-srv6-network-programming-16, June 2020. |
| [I-D.ietf-teas-enhanced-vpn] | Dong, J., Bryant, S., Li, Z., Miyasaka, T. and Y. Lee, "A Framework for Enhanced Virtual Private Networks (VPN+) Services", Internet-Draft draft-ietf-teas-enhanced-vpn-05, February 2020. |