LSR Working Group J. Dong Internet-Draft Z. Hu Intended status: Standards Track Huawei Technologies Expires: May 7, 2020 S. Bryant Futurewei Technologies November 4, 2019 IGP Extensions for Segment Routing based Enhanced VPN draft-dong-lsr-sr-enhanced-vpn-02 Abstract 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 better isolation and have more stringent performance requirements than that can be provided with traditional overlay VPNs. An enhanced VPN may be used for 5G transport network slicing, and will also be of use in more generic scenarios. This document specifies the IGP mechanisms with necessary extensions to build a set of Segment Routing (SR) based virtual networks with customized topology and resource attributes in the network. These virtual networks could be used as the underlay of enhanced VPN service. The proposed mechanism is applicable to both Segment Routing with MPLS data plane (SR-MPLS) and segment routing with IPv6 data plane (SRv6). 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 [RFC2119]. 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." Dong, et al. Expires May 7, 2020 [Page 1] Internet-Draft IGP Extensions for SR VPN+ November 2019 This Internet-Draft will expire on May 7, 2020. Copyright Notice Copyright (c) 2019 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Transport Network Slice Definition Advertisement . . . . . . 3 3. Advertisement of Network Topology Attribute . . . . . . . . . 6 3.1. MTR based Topology Advertisement . . . . . . . . . . . . 6 3.2. Flex-Algo based Topology Advertisement . . . . . . . . . 6 4. Advertisement of Network Resource Attribute . . . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 8.1. Normative References . . . . . . . . . . . . . . . . . . 10 8.2. Informative References . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 1. Introduction Driven largely by needs arising from the 5G mobile network, the concept of network slicing has gained traction. There is a need to provide VPN service with enhanced isolation and performance characteristics. Specifically, there is a need for a transport network to provide a set of virtual networks, each of which provides the tenant with a customized network topology, the required degree of isolation and performance guarantee to meet the tenant's requirement. 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. Dong, et al. Expires May 7, 2020 [Page 2] Internet-Draft IGP Extensions for SR VPN+ November 2019 To meet the requirement of enhance VPN services, a number of virtual networks need 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 enhanced VPN or a group of enhanced VPNs. In the context of 5G, each virtual network can be considered as a transport network slice. Depending on the service requirement and the physical network infrastructure, different virtual networks may share the same network links or nodes, or use separate links or nodes, in both cases the level of isolation and service performance required by the tenant should be met. [I-D.dong-spring-sr-for-enhanced-vpn] specifies how segment routing (SR) [RFC8402] can be used to build virtual networks with the required network topology and network resources 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 and the associated topology and resource information need to be distributed using a control plane. [I-D.dong-teas-enhanced-vpn-control-plane] describes the requirements and considerations about the control plane of enhanced VPN. In order to support the increasing number of transport network slices in one network, the proposed approach is to separate the topology and resource attributes of the virtual network in control plane, so that the advertisement and processing of each type of attribute could be decoupled. This document specifies the IGP control plane mechanism with necessary extensions to build a set of SR based transport network slices with customized topology and resource attributes. The proposed mechanism is applicable to both segment routing with MPLS data plane (SR-MPLS) and segment routing with IPv6 data plane (SRv6). In general this approach applies to both IS-IS and OSPF, while the specific protocol extensions and encodings are different. In the current version of this document, the required IS-IS extensions are described. The required OSPF extensions will be described in a future version or a separate document. 2. Transport Network Slice Definition Advertisement According to the definition in [I-D.ietf-teas-enhanced-vpn], a transport network slice is the combination of a set of network attributes, and the topology attribute and resource attributes are two major types of attributes of a transport network slice. In order to improve the control plane scalability, different types of attributes can be advertised and processed separately. IS-IS Dong, et al. Expires May 7, 2020 [Page 3] Internet-Draft IGP Extensions for SR VPN+ November 2019 Transport Network Slice Definition (TNSD) sub-TLV is used to advertise the definition of a transport network slice. It is a sub- TLV of the IS-IS Router-Capability TLV 242 as defined in [RFC7981]. The format of IS-IS TNSD sub-TLV is as below: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Transport Network Slice Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-TLVs | ~ ... ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Where: o Type: TBD o Length: the length of the value field of the sub-TLV. It is variable dependent on the included sub-TLVs. o Flags: 16-bit flags to indicate the attributes of the virtual network. All flags are reserved and MUST be set to zero on transmission and ignored on receipt. o Transport Network Slice Identifier (TNSI): A 32-bit identifier which is used to identify a transport network slice. o Sub-TLVs: optional sub-TLVs to specify the attributes of a transport network slice. Two sub-TLVs are defined in this document: Network Topology sub-TLV and Network Resource sub-TLV. The format of the Network Topology sub-TLV is as below: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length |M|A| Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MT-ID | Algorithm | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Dong, et al. Expires May 7, 2020 [Page 4] Internet-Draft IGP Extensions for SR VPN+ November 2019 Where: o Type: 1 o Length: the length of the value field of the sub-TLV. o Flags: 16-bit flags to indicate the attribute of the network topology. Where: M flag: indicates the topology is determined by the MT-ID when set. A flag: indicates the topology is determined by the Algorithm when set. In this case, the value of the Algorithm field SHOULD be in the range 128 to 255. o MT-ID: 16-bit identifier which indicates the multi-topology identifier. o Reserved: this field is reserved for future use. MUST be set to 0 on transmission and ignored on receipt. o Algorithm: 8-bit identifier which indicates the algorithm which is used for this transport network slice. The format of the Network Resource sub-TLV is as below: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Resource Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Where: Type: 2 Length: 6 octets. Flags: 16 bit flags. All the bits are reserved, which MUST be set to 0 on transmission and ignored on receipt. Resource Identifier: A 32-bit identifier which is used to identify the group of network resources allocated to a transport network slice. Dong, et al. Expires May 7, 2020 [Page 5] Internet-Draft IGP Extensions for SR VPN+ November 2019 3. Advertisement of Network Topology Attribute Two candidate mechanisms can be used to describe and advertise the topology attributes of SR based transport network slice. The first approach is to use Multi-Topology Routing (MTR) [RFC4915] [RFC5120] together with segment routing extensions to advertise the topologies of SR based transport network slices. The second approach is to use Flex-Algo [I-D.ietf-lsr-flex-algo] to describe the topological constraints of SR based transport network slice. 3.1. MTR based Topology Advertisement Multi-Topology Routing (MTR) has been defined in [RFC4915] and [RFC5120] to create different network topologies in one network. It also has the capability of specifying customized attributes for each topology. The traditional use cases of multi-topology are to maintain separate topologies for unicast and multicast services, or to create different topologies for IPv4 and IPv6 in a network. There are some limitations when MTR is used with IP forwarding, the considerations about MT based IP forwarding are described in [RFC5120]. MTR can be used with SR-MPLS data plane. [I-D.ietf-isis-segment-routing-extensions] specifies the IS-IS extensions to support SR-MPLS data plane, in which the Prefix-SID sub-TLVs can be carried in IS-IS TLV 235 (MT IP Reachability) and TLV 237 (MT IPv6 IP Reachability), and the Adj-SID sub-TLVs can be carried in IS-IS TLV 222 (MT-ISN) and TLV 223 (MT IS Neighbor Attribute). MTR can also be used with SRv6 data plane. [I-D.ietf-lsr-isis-srv6-extensions] specifies the IS-IS extensions to support SRv6 data plane, in which the MT-ID is included in the SRv6 Locator TLV. The SRv6 End SIDs inherit the topology/algorithm from the parent locator. In addition, the SRv6 End.X SID sub-TLVs can be carried in the IS-IS TLV 222 (MT-ISN) and TLV 223 (MT IS Neighbor Attribute). These IGP extensions for SR-MPLS and SRv6 can be used to advertise and build the topology of SR based transport network slice. 3.2. Flex-Algo based Topology Advertisement [I-D.ietf-lsr-flex-algo] specifies the mechanism to provide distributed computation of constrained paths, and how the SR-MPLS prefix-SIDs and SRv6 locators can be used to steer traffic along the constrained paths. Dong, et al. Expires May 7, 2020 [Page 6] Internet-Draft IGP Extensions for SR VPN+ November 2019 The Flex-Algo definition can be used to describe the topological constraints for path computation. According to the network nodes' participation of a Flex-Algo, and the rules of including or excluding specific Admin Groups (colors), a network topology can be determined by a Flex-Algo. With the mechanism defined in [I-D.ietf-lsr-flex-algo], algorithm- specific prefix-SIDs can be allocated. This allows the nodes to steer traffic along distributed computed paths within the topology determined by the Flex-Algo. [I-D.ietf-lsr-isis-srv6-extensions] specifies the IS-IS extensions to support SRv6 data plane, in which algorithm-specific SRv6 locators and SRv6 End SIDs can be allocated. This allows the nodes to steer traffic along distributed computed paths within the topology determined by the Flex-Algo. In addition, algorithm-specific SRv6 End.X SID can be allocated, which can be used to enforce traffic over the LFA computed backup path. 4. Advertisement of Network Resource Attribute This section specifies the mechanism to advertise the network resource attributes associated with a transport network slice. The mechanism of advertising link level resources is described. The mechanism and description of node resource are for further study. On a physical network link, a subset of the link resource can be allocated to a specific transport network slice. This subset of the link resource can be represented as a virtual layer-2 member link of the physical link. In the L2 link bundle scenario, it is also possible that the subset of link resource is provided by a physical layer-2 member link. [I-D.ietf-isis-l2bundles] describes the IS-IS extensions to advertise the link attributes of the L2 member links which comprise an L3 interface. Such mechanism can be extended to advertise the attributes of each physical or virtual member links, and the associated transport network slice. A new flag "V" (Virtual) is defined in the flag field of the Parent L3 Neighbor Descriptor in the L2 Bundle Member Attributes TLV (25). 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |P|V| | +-+-+-+-+-+-+-+-+ Dong, et al. Expires May 7, 2020 [Page 7] Internet-Draft IGP Extensions for SR VPN+ November 2019 V flag: indicates the member links under the Parent L3 link are virtual member links when set. When the V flag is clear, it indicates the member links are physical links. A global-significant Resource Identifier (ResID) is used to identify a resource group which is the collection of all the network resources allocated to a transport network slice. The Resource Identifier (ResID) sub-TLV is carried in the L2 Bundle Member Attributes to describe to which resource group a particular virtual or physical member links belongs to. The format of the ResID Sub-TLV is as below: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Bundle Member Link Local Identifer | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Resource Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Where: o Type: TBD o Length: 10 octets. o Flags: 16 bit flags. All the bits are reserved, which MUST be set to 0 on transmission and ignored on receipt. o Bundle Member Link Local Identifer: A 32-bit local identifier of a physical or virtual member link. o Resource Identifier: A 32-bit global-signicifant identifier to identify the resource group this member link belongs to. Each physical or virtual member link of an L3 link SHOULD be allocated with a different Resource Identifier. Thus multiple ResID sub-TLVs will be carried in the L2 Bundle Attribute Descriptors of the L2 Bundle Member Attributes TLV. The TE attributes of each physical or virtual bundle member link, such as the bandwidth and the adj-SIDs, can be advertised using the mechanism as defined in [I-D.ietf-isis-l2bundles]. Dong, et al. Expires May 7, 2020 [Page 8] Internet-Draft IGP Extensions for SR VPN+ November 2019 5. Security Considerations This document introduces no additional security vulnerabilities to IS-IS and OSPF. The mechanism proposed in this document is subject to the same vulnerabilities as any other protocol that relies on IGPs. 6. IANA Considerations IANA is requested to assign a new code point in the "sub-TLVs for TLV 242" registry. Type: TBD Description: Transport Network Slice Definition IANA is requested to create a new sub-sub-TLV registry: Registry: Sub-Sub-TLVs for Transport Network Slice Definition Sub-TLV Registration Procedure: Expert review Reference: This document This document defines the following Sub-Sub-TLVs in the "Sub-Sub-TLVs for Transport Network Slice Definition Sub-TLV" registry: Type: 1 Description: Network Topology Attribute Reference: This document. Type: 2 Description: Network Resource Attribute Reference: This document IANA is requested to assign a new code point in the "sub-TLVs for TLVs 22, 23, 25, 141, 222, and 223" registry. Type: TBD Description: Resource Identifier 7. Acknowledgments The authors would like to thank Mach Chen, Robin Li and Dean Cheng for their review and discussion of this document. Dong, et al. Expires May 7, 2020 [Page 9] Internet-Draft IGP Extensions for SR VPN+ November 2019 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 Enhanced VPN Service", draft- dong-spring-sr-for-enhanced-vpn-05 (work in progress), October 2019. [I-D.ietf-isis-l2bundles] Ginsberg, L., Bashandy, A., Filsfils, C., Nanduri, M., and E. Aries, "Advertising L2 Bundle Member Link Attributes in IS-IS", draft-ietf-isis-l2bundles-07 (work in progress), May 2017. [I-D.ietf-isis-segment-routing-extensions] Previdi, S., Ginsberg, L., Filsfils, C., Bashandy, A., Gredler, H., and B. Decraene, "IS-IS Extensions for Segment Routing", draft-ietf-isis-segment-routing- extensions-25 (work in progress), May 2019. [I-D.ietf-lsr-flex-algo] Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and A. Gulko, "IGP Flexible Algorithm", draft-ietf-lsr-flex- algo-04 (work in progress), September 2019. [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", draft-ietf-lsr-isis-srv6-extensions-03 (work in progress), October 2019. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", RFC 4915, DOI 10.17487/RFC4915, June 2007, . [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, . Dong, et al. Expires May 7, 2020 [Page 10] Internet-Draft IGP Extensions for SR VPN+ November 2019 [RFC7981] Ginsberg, L., Previdi, S., and M. Chen, "IS-IS Extensions for Advertising Router Information", RFC 7981, DOI 10.17487/RFC7981, October 2016, . [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, July 2018, . 8.2. Informative References [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+) Service", draft-ietf-teas-enhanced-vpn-03 (work in progress), September 2019. Authors' Addresses Jie Dong Huawei Technologies Email: jie.dong@huawei.com Zhibo Hu Huawei Technologies Email: huzhibo@huawei.com Stewart Bryant Futurewei Technologies Email: stewart.bryant@gmail.com Dong, et al. Expires May 7, 2020 [Page 11]