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

Abstract

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.

Requirements Language

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.

Status of This Memo

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 Notice

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.


Table of Contents

1. Introduction

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].

2. Advertisement of SR VTN Topology Attribute

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.

3. Advertisement of SR VTN Resource Attribute

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.

3.1. Advertising Topology-specific TE attributes

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].

4. Scalability Considerations

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.

5. Security Considerations

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.

6. IANA Considerations

This document does not request any IANA actions.

7. Acknowledgments

The authors would like to thank Zhibo Hu, Dean Cheng, Les Ginsberg and Peter Psenak for the review and discussion of this document.

8. References

8.1. Normative References

[I-D.dong-spring-sr-for-enhanced-vpn] Dong, J., Bryant, S., Miyasaka, T., Zhu, Y., Qin, F. and Z. Li, "Segment Routing for Resource Guaranteed Virtual Networks", Internet-Draft draft-dong-spring-sr-for-enhanced-vpn-08, June 2020.
[I-D.ietf-lsr-isis-srv6-extensions] Psenak, P., Filsfils, C., Bashandy, A., Decraene, B. and Z. Hu, "IS-IS Extension to Support Segment Routing over IPv6 Dataplane", Internet-Draft draft-ietf-lsr-isis-srv6-extensions-08, April 2020.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997.
[RFC5120] Przygienda, T., Shen, N. and N. Sheth, "M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs)", RFC 5120, DOI 10.17487/RFC5120, February 2008.
[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic Engineering", RFC 5305, DOI 10.17487/RFC5305, October 2008.
[RFC8402] Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., Litkowski, S. and R. Shakir, "Segment Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, July 2018.
[RFC8667] Previdi, S., Ginsberg, L., Filsfils, C., Bashandy, A., Gredler, H. and B. Decraene, "IS-IS Extensions for Segment Routing", RFC 8667, DOI 10.17487/RFC8667, December 2019.

8.2. Informative References

[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.

Authors' Addresses

Chongfeng Xie China Telecom China Telecom Beijing Information Science & Technology, Beiqijia Beijing, 102209 China EMail: xiechf@chinatelecom.cn
Chenhao Ma China Telecom China Telecom Beijing Information Science & Technology, Beiqijia Beijing, 102209 China EMail: machh@chinatelecom.cn
Jie Dong Huawei Technologies Huawei Campus, No. 156 Beiqing Road Beijing, 100095 China EMail: jie.dong@huawei.com
Zhenbin Li Huawei Technologies Huawei Campus, No. 156 Beiqing Road Beijing, 100095 China EMail: lizhenbin@huawei.com