| Internet-Draft | IGP Extensions for SR VPN+ | January 2022 |
| Dong, et al. | Expires 3 August 2022 | [Page] |
Enhanced VPN (VPN+) aims to provide enhanced VPN services to support some application's needs of enhanced isolation and stringent performance requirements. VPN+ requires integration between the overlay VPN connectivity and the characteristics provided by the underlay network. A Virtual Transport Network (VTN) is a virtual underlay network which has a customized network topology and a set of network resources allocated from the physical network. A VTN could be used to support one or a group of VPN+ services.¶
This document specifies the IGP mechanisms with necessary extensions to advertise the associated topology and resource attributes for scalable Segment Routing (SR) based VTNs. Each VTN can have a customized topology and a set of network resources allocated from the physical network. Multiple VTNs may shared the same topology, and multiple VTNs may share the same set of network resources on some network segments. A group of resource-aware SIDs are allocated for each VTN. This allows flexible combination of the network topology and network resource attributes to build a relatively large number of VTNs with a small number of logical topologies. The proposed mechanism is applicable to both Segment Routing with MPLS data plane (SR-MPLS) and segment routing with IPv6 data plane (SRv6). This document also describes the mechanisms of using dedicated VTN-ID in the data plane instead of the per-VTN resource-aware SIDs to further reduce the control plane overhead.¶
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].¶
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 3 August 2022.¶
Copyright (c) 2022 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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
Enhanced VPN (VPN+) is an enhancement to VPN services to support the needs of new applications, particularly 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 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 can be used for 5G network slicing, and will also be of use in more generic scenarios.¶
To meet the requirement of different enhanced VPN services, a number of virtual underlay networks need to be created, each with a customized network topology and a set of network resources allocated from the physical network to meet the requirement of one or a group of VPN+ services. Such a virtual underlay network is called Virtual Transport Network (VTN) in [I-D.ietf-teas-enhanced-vpn].¶
[I-D.ietf-spring-resource-aware-segments] introduces resource-aware segments by associating existing type of SIDs with network resource attributes (e.g. bandwidth, processing or storage resources). These resource-aware SIDs retain their original functionality, with the additional semantics of identifying the set of network resources available for the packet processing action.[I-D.ietf-spring-sr-for-enhanced-vpn] describes the use of resource-aware segments to build SR based VTNs. To allow the network controller and network nodes to perform VTN-specific explicit path computation and/or shortest path computation, the group of resource-aware SIDs allocated by network nodes to each VTN and the associated topology and resource attributes need to be distributed using the control plane.¶
[I-D.dong-teas-nrp-scalability] analyzes the scalability requirements and the control plane and data plane scalability considerations of enhanced VPN, more specifically, the scalability of the VTNs. In order to support a relatively large number of VTNs in the network, one proposed approach is to separate the topology and resource attributes of the VTN in control plane, so that the advertisement and processing of each type of attribute could be decoupled. Multiple VTNs may shared the same topology, and multiple VTNs may share the same set of network resources on some network segments, while the difference in either the topology or resource attributes makes them different VTNs. This allows flexible combination of network topology and network resource attributes to build a large number of VTNs with a relatively small number of logical topologies.¶
This document specifies the IGP control plane mechanisms with necessary extensions for scalable SR based VTNs. The proposed mechanism is applicable to both segment routing with MPLS data plane (SR-MPLS) and segment routing with IPv6 data plane (SRv6). This document also describes the mechanisms of using dedicated VTN-ID in the data plane instead of the per-VTN resource-aware SIDs to further reduce the control plane overhead.¶
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 in a separate document.¶
According to [I-D.ietf-teas-enhanced-vpn], a VTN is associated with a customized network topology and a set of dedicated or shared network resources. Thus a VTN can be defined as the combination of a set of network attributes, which include the topology attribute and other attributes, such as the network resources. IS-IS Virtual Transport Network Definition (VTND) sub-TLV is used to advertise the definition of a VTN. It is a sub-TLV of the IS-IS Router-Capability TLV 242 as defined in [RFC7981].¶
The format of IS-IS VTND 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 | VTN ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VTN ID (Continue) | MT-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Algorithm | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Sub-sub-TLVs ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+¶
Where:¶
The VTND Sub-TLV MAY be advertised in an LSP of any number. A node MUST NOT advertise more than one VTND Sub-TLV for a given VTN ID.¶
This section describes the mechanisms used to advertise the topology attribute associated with SR based VTNs. Basically the topology of a VTN can be determined by the MT-ID and/or the algorithm ID included in the VTN definition. In practice, it could be described using two optional approaches.¶
The first approach is to use Multi-Topology Routing (MTR) [RFC4915] [RFC5120] with the segment routing extensions to advertise the topology associated with the SR based VTNs. Different algorithms MAY be used to further specify the computation algorithm or the metric type used for path computation within the topology. Multiple VTNs can be associated with the same <topology, algorithm>, and the IGP computation with the <topology, algorithm> tuple can be shared by these VTNs.¶
The second approach is to use Flex-Algo [I-D.ietf-lsr-flex-algo] to describe the topological constraints of SR based VTNs on a shared network topology (e.g. the default topology). Multiple VTNs can be associated with the same Flex-Algo, and the IGP computation with this Flex-Algo can be shared by these VTNs.¶
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 native IP forwarding, the considerations about MT based IP forwarding are described in [RFC5120].¶
MTR can be used with SR-MPLS data plane. [RFC8667] 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 carried in the SRv6 Locator TLV. The SRv6 End SIDs are carried as sub-TLVs in the SRv6 Locator TLV, and inherit the topology/algorithm from the parent locator. The SRv6 End.X SIDs are carried as sub-TLVs in the IS-IS TLV 222 (MT-ISN) and TLV 223 (MT IS Neighbor Attribute), and inherit the topology/algorithm from the parent locator.¶
These IGP extensions for SR-MPLS and SRv6 can be used to advertise and build the topology for a group of SR based VTNs.¶
An algorithm ID MAY be used to further specify the computation algorithm or the metric type used for path computation within the topology.¶
[I-D.ietf-lsr-flex-algo] specifies the mechanisms to provide distributed computation of constraint-based paths, and how the SR-MPLS prefix-SIDs and SRv6 locators can be used to steer packets along the constraint-based paths.¶
The Flex-Algo Definition (FAD) can be used to describe the topological constraints for path computation on a network topology. According to the network nodes' participation of a Flex-Algo, and the rules of including or excluding specific Administrative Groups (colors) and the Shared Risk Link Groups (SRLGs), the topology of a VTN can be determined using the associated Flex-Algo on a particular topology (e.g. the default topology).¶
With the mechanisms defined in[RFC8667] [I-D.ietf-lsr-flex-algo], prefix-SID advertisement can be associated with a <topology, algorithm> tuple, in which the algorithm can be a Flex-Algo. This allows network nodes to use the prefix-SID to steer traffic along distributed computed paths according to the identified Flex-Algo in the topology.¶
[I-D.ietf-lsr-isis-srv6-extensions] specifies the IS-IS extensions to support SRv6 data plane, in which the SRv6 locators advertisement can be associated with a specific topology and a specific algorithm, which can be a Flex-Algo. With the mechanism defined in [I-D.ietf-lsr-flex-algo], The SRv6 locator can be used to steer traffic along distributed computed paths according to the identified Flex-Algo in the topology. In addition, topology/algorithm specific SRv6 End SID and End.X SID can be used to enforce traffic over the LFA computed backup path.¶
Multiple Flex-Algos MAY be defined to describe the topological constraints on a shared network topology (e.g. the default topology).¶
This section specifies the mechanisms to advertise the network resource attributes associated with the VTNs. The mechanism of advertising the link resources and attributes associated with VTNs is described. The mechanism of advertising node resources and attributes associated with VTNs are for further study. Two optional approaches are described in the following sub-sections: the first option is the L2 Bundle [RFC8668] based approach, the second option is to extend IGP to advertise per-VTN link TE attributes.¶
On a Layer-3 interface, each VTN can be allocated with a subset of link resources (e.g. bandwidth). A subset of link resources may be dedicated to a VTN, or may be shared by a group of VTNs. Each subset of link resource can be represented as a virtual layer-2 member link under the Layer-3 interface, and the Layer-3 interface is considered as a virtual Layer-2 bundle. The Layer-3 interface may also be a physical Layer 2 link bundle, in this case a subset of link resources allocated to a VTN may be provided by one of the physical Layer-2 member links.¶
[RFC8668] describes the IS-IS extensions to advertise the link attributes of the Layer 2 member links which comprise a Layer 3 interface. Such mechanism can be extended to advertise the attributes of each physical or virtual member links, and its associated VTNs.¶
A new flag "E" (Exclusive) 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|E| |
+-+-+-+-+-+-+-+-+¶
E flag: When the E flag is set, it indicates each member link under the Parent L3 link are used exclusively for one or a specific group of VTNs, and load sharing among the member links is not allowed. When the E flag is clear, it indicates load balancing and sharing among the member links are allowed.¶
A new VTN-IDs sub-TLV is carried under the L2 Bundle Attribute Descriptors to describe the mapping relationship between the VTNs and the virtual or physical member links. As one or more VTNs may use the same set of link resource on a specific network segment, these VTN IDs will be advertised under the same virtual or physical member link.¶
The format of the VTN-IDs 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VTN ID #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VTN ID #n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+¶
Where:¶
Each physical or virtual member link MAY be associated with a different group of VTNs. Thus each L2 Bundle Attribute Descriptor may carry the link local identifier and attributes of only one Layer 2 member link. Multiple L2 Bundle Attribute Descriptors will be used to carry the attributes and the associated VTN-IDs of all the Layer 2 member links.¶
The TE attributes of each virtual or physical member link, such as the bandwidth attributes and the SR SIDs, can be advertised using the mechanism as defined in [RFC8668].¶
A Layer-3 interface can participate in multiple VTNs, each of which is allocated with a subset of the forwarding resources of the interface. For each VTN, the associated resources can be described using per-VTN TE attributes. A new VTN-specific TE attribute sub-TLV is defined to advertise the link attributes associated with a VTN. This sub-TLV MAY be advertised as a sub-TLV of the following TLVs:¶
TLV-22 (Extended IS reachability) [RFC5305] TLV-23 (IS Neighbor Attribute) [RFC5311] TLV-141 (Inter-AS Reachability Information) [RFC5316] TLV-222 (MT ISN) [RFC5120] TLV-223 (MT IS Neighbor Attribute) [RFC5311]¶
The format of the sub-TLV is shown 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 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VTN ID Sub-sub-TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Other Sub-sub-TLVs ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+¶
Where:¶
The format of the VTN ID sub-sub-TLV is shown 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VTN ID #1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ... ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+¶
Where:¶
One sub-sub-TLV "VTN bandwidth sub-sub-TLV" is defined in this document. Its format is shown 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 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Bandwidth | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+¶
Where:¶
The VTN-specific Bandwidth sub-sub-TLV is optional. This sub-sub-TLV SHOULD appear once at most in each VTN-specific TE attribute sub-TLV.¶
In order to steer packets to the VTN-specific paths which are computed taking the topology and network resources of the VTN as the constraints, some fields in the data packet needs to be used to infer or identify the VTN the packet belongs to. As multiple VTNs may share the same topology or Flex-Algo, the topology/Flex-Algo specific SR SIDs or Locators cannot be used to distinguish the packets which belong to different VTNs. Some additional data plane identifiers would be needed to identify the VTN a packet belongs to.¶
This section describes the mechanisms to advertise the VTN identifiers in different data plane encapsulations.¶
With SR-MPLS data plane, the VTN identification information can be implicitly carried in the VTN-specific SIDs. Each node SHOULD allocate a unique Prefix-SID for each VTN it participates in. On a Layer-3 interface, if each Layer 2 member link is associated with only one VTN, the adj-SIDs of the L2 member links could also identify the VTNs. If a member link is associated with multiple VTNs, VTN-specific adj-SIDs MAY need to be allocated to help the VTN-specific local protection.¶
A new VTN-specific prefix-SID sub-TLV is defined to advertise the prefix-SID and its associated VTN. This sub-TLV MAY be advertised as a sub-TLV of the following TLVs:¶
TLV-135 (Extended IPv4 Reachability) defined in [RFC5305]. TLV-235 (MT IP Reachability) defined in [RFC5120]. TLV-236 (IPv6 IP Reachability) defined in [RFC5308]. TLV-237 (MT IPv6 IP Reachability) defined in [RFC5120].¶
The format of the sub-TLV is shown 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VTN ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SID/Index/Label(Variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+¶
Where:¶
One or more of VTN-specific Prefix-SID sub-TLVs MAY be carried in the Multi-topology IP Reachability TLVs (TLV 235 or TLV 237), the MT-ID of the TLV SHOULD be the same as the MT-ID in the definition of these VTNs.¶
A new VTN-specific Adj-SID sub-TLV is defined to advertise the adj-SID and its associated VTN. This sub-TLV may be advertised as a sub-TLV of the following TLVs:¶
TLV-22 (Extended IS reachability) [RFC5305] TLV-23 (IS Neighbor Attribute) [RFC5311] TLV-25 (L2 Bundle Member Attributes) [RFC8668] TLV-141 (Inter-AS Reachability Information) [RFC5316] TLV-222 (MT ISN) [RFC5120] TLV-223 (MT IS Neighbor Attribute) [RFC5311]¶
The format of the sub-TLV is shown 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VTN ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SID/Index/Label(Variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+¶
Where:¶
One or more VTN-specific Adj-SID sub-TLV MAY be carried in the Multi-topology ISN or Multi-topology IS Attribute TLVs (TLV 222 or TLV 223), the MT-ID of the TLV SHOULD be the same as the MT-ID in the definition of these VTNs.¶
With SRv6 data plane, the VTN identification information can be implicitly or explicitly carried in the SRv6 Locator of the corresponding VTN, this is to ensure that all network nodes (including both the end nodes and the transit nodes) can identify the VTN to which a packet belongs to. Network nodes SHOULD allocate VTN-specific Locators for each VTN it participates in. The VTN-specific Locators are used as the covering prefix of VTN-specific SRv6 End SIDs, End.X SIDs and other types of SIDs.¶
In one possible approach, each VTN-specific Locator is advertised in a separate TLV called "VTN specific SRv6 Locator TLV". Its format is shown 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 |R|R|R|R| MT ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Locator Entries . . . |¶
Where:¶
Followed by one or more locator entries of the form:¶
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Algorithm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VTN ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Loc Size |
+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Locator (continued, variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-TLV-len | Sub-TLVs (variable) . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+¶
Where:¶
The VTN-specific SRv6 End SIDs are carried in the VTN-specific SRv6 Locator TLV, and inherits the topology, algorithm and VTN from the parent VTN-specific Locator.¶
In another possible approach, when a group of VTNs share the same topology/algorithm, the topology/algorithm specific Locator is the covering prefix of a group of VTN-specific Locators. Then the advertisement of VTN-specific locators can be optimized to reduce the amount of Locator TLVs advertised in the control plane.¶
A new VTN locator-block sub-TLV under the SRv6 Locator TLV is defined to advertise a set of sub-blocks which follows the topology/algorithm specific Locator. Each VTN locator-block value is assigned to one of the VTNs which share the same topology/algorithm.¶
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 | Number of VTNs| Block Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VTN ID #1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Locator Block Value ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ... ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VTN ID #n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Locator Block Value ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+¶
Where:¶
With the VTN locator-block sub-TLV, the VTN-specific Locator can be obtained by concatenating the topology/algorithm specific locator and the locator-block value advertised for the VTN.¶
The VTN-specific SRv6 End SIDs inherit the topology, algorithm and the VTN from the parent VTN-specific Locator.¶
The SRv6 End.X SIDs are advertised as sub-TLVs of TLV 22, 23, 25, 141, 222, and 223. In order to distinguish the End.X SIDs which belong to different VTNs, a new "VTN ID sub-sub-TLV" is introduced under the SRv6 End.X SID sub-TLV and SRv6 LAN End.X SID sub-TLV defined in [I-D.ietf-lsr-isis-srv6-extensions]. Its format is shown 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VTN ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+¶
Where:¶
As the number of VTNs increases, with the mechanism described in [I-D.ietf-spring-sr-for-enhanced-vpn], the number of SR SIDs and SRv6 Locators allocated for different VTNs would also increase. In network scenarios where the number of SIDs or Locators becomes a concern, some data plane optimization may be needed to reduce the amount of SR SIDs and Locators allocated. As described in [I-D.dong-teas-nrp-scalability], one approach is to decouple the data plane identifiers used for topology based forwarding and the identifiers used for the VTN-specific processing. Thus a dedicated data plane VTN-ID could be encapsulated in the packet. One possible encapsulation of VTN-ID in IPv6 data plane is proposed in [I-D.dong-6man-enhanced-vpn-vtn-id]. One possible encapsulation of VTN-ID in MPLS data plane is proposed in [I-D.li-mpls-enhanced-vpn-vtn-id].¶
In that case, the VTN-ID encapsulated in data plane can have the same value as the VTN-ID in control plane, so that the overhead of advertising the mapping between the control plane VTN-IDs and the corresponding data plane identifiers could be saved.¶
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.¶
IANA is requested to assign a new code point in the "sub-TLVs for TLV 242 registry".¶
Type: TBD1 Description: Virtual Transport Network Definition¶
IANA is requested to assign three new code points in the "sub-TLVs for TLVs 22, 23, 25, 141, 222, and 223 registry".¶
Type: TBD2 Description: Virtual Transport Network Identifiers Type: TBD3 Description: VTN-specific TE attribute sub-TLV Type: TBD4 Description: VTN-specific Adj-SID¶
IANA is requested to assign two new code points in the "Sub-TLVs for TLVs 27, 135, 235, 236 and 237 registry".¶
Type: TBD5 Description: VTN-specific Prefix-SID Type: TBD6 Description: VTN locator-block¶
IANA is requested to assign a new code point in the "IS-IS TLV Codepoints registry".¶
Type: TBD7 Description: VTN-specific SRv6 Locator TLV¶
IANA is requested to assign a new code point in the "sub-sub-TLVs for SRv6 End SID and SRv6 End.X SID registry".¶
Type: TBD8 Description: VTN ID Sub-sub-TLV¶
Hongjie Yang Email: hongjie.yang@huawei.com¶
The authors would like to thank Mach Chen, Dean Cheng and Guoqi Xu for their review and discussion of this document.¶