LSR Working Group J. Dong
Internet-Draft Z. Hu
Intended status: Standards Track Z. Li
Expires: 3 August 2022 Huawei Technologies
X. Tang
R. Pang
China Unicom
L. JooHeon
LG U+
S. Bryant
Futurewei Technologies
30 January 2022
IGP Extensions for Scalable Segment Routing based Enhanced VPN
draft-dong-lsr-sr-enhanced-vpn-07
Abstract
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.
Requirements Language
Dong, et al. Expires 3 August 2022 [Page 1]
Internet-Draft IGP Extensions for SR VPN+ January 2022
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."
This Internet-Draft will expire on 3 August 2022.
Copyright Notice
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. VTN Definition Advertisement . . . . . . . . . . . . . . . . 4
3. Advertisement of VTN Topology Attribute . . . . . . . . . . . 6
3.1. MTR based Topology Advertisement . . . . . . . . . . . . 6
3.2. Flex-Algo based Topology Advertisement . . . . . . . . . 7
4. Advertisement of VTN Resource Attribute . . . . . . . . . . . 8
4.1. Option 1: L2 Bundle based Approach . . . . . . . . . . . 8
4.2. Option 2: Per-VTN Link TE Attributes . . . . . . . . . . 10
5. Advertisement of VTN specific Data Plane Identifiers . . . . 12
5.1. Advertisement of VTN-specific SR-MPLS SIDs . . . . . . . 12
5.2. Advertisement of VTN-specific SRv6 Locators and SIDs . . 14
Dong, et al. Expires 3 August 2022 [Page 2]
Internet-Draft IGP Extensions for SR VPN+ January 2022
5.2.1. VTN-specific SRv6 Locators and End SIDs . . . . . . . 14
5.2.2. VTN-specific SRv6 End.X SIDs . . . . . . . . . . . . 17
5.3. Advertisement of Dedicated Data Plane VTN IDs . . . . . . 17
6. Security Considerations . . . . . . . . . . . . . . . . . . . 18
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 19
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
10.1. Normative References . . . . . . . . . . . . . . . . . . 19
10.2. Informative References . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction
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.
Dong, et al. Expires 3 August 2022 [Page 3]
Internet-Draft IGP Extensions for SR VPN+ January 2022
[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.
2. VTN Definition Advertisement
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:
Dong, et al. Expires 3 August 2022 [Page 4]
Internet-Draft IGP Extensions for SR VPN+ January 2022
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:
* Type: TBD
* Length: The length of the value field of the sub-TLV. It is
variable dependent on the included sub-TLVs.
* VTN ID: A global significant 32-bit identifier which is used to
identify a VTN.
* MT-ID: 16-bit field which indicates the multi-topology identifier
as defined in [RFC5120]. The first 4-bit are set to zero.
* Algorithm: 8-bit identifier which indicates the algorithm which
applies to this VTN. It can be either a normal algorithm
[RFC8402] or a Flexible Algorithm [I-D.ietf-lsr-flex-algo].
* Flags: 8-bit flags. Currently all the flags are reserved for
future use. They SHOULD be set to zero on transmission and MUST
be ignored on receipt.
* Sub-sub-TLVs: optional sub-sub-TLVs to specify the additional
attributes of a VTN. Currently no sub-sub-TLV is defined in this
document.
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.
Dong, et al. Expires 3 August 2022 [Page 5]
Internet-Draft IGP Extensions for SR VPN+ January 2022
3. Advertisement of VTN Topology Attribute
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.
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 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).
Dong, et al. Expires 3 August 2022 [Page 6]
Internet-Draft IGP Extensions for SR VPN+ January 2022
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.
3.2. Flex-Algo based Topology Advertisement
[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.
Dong, et al. Expires 3 August 2022 [Page 7]
Internet-Draft IGP Extensions for SR VPN+ January 2022
Multiple Flex-Algos MAY be defined to describe the topological
constraints on a shared network topology (e.g. the default topology).
4. Advertisement of VTN Resource Attribute
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.
4.1. Option 1: L2 Bundle based Approach
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.
Dong, et al. Expires 3 August 2022 [Page 8]
Internet-Draft IGP Extensions for SR VPN+ January 2022
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:
* Type: TBD
* Length: The length of the value field of the sub-TLV. It is
variable dependent on the number of VTN IDs included.
* Flags: 16 bit flags. All the bits are reserved for future use,
which SHOULD be set to 0 on transmission and MUST be ignored on
receipt.
* VTN IDs: One or more 32-bit identifier to identify the VTNs this
member link belongs to.
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].
Dong, et al. Expires 3 August 2022 [Page 9]
Internet-Draft IGP Extensions for SR VPN+ January 2022
4.2. Option 2: Per-VTN Link TE Attributes
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:
* Type: TBD
* Length: The length of the value field of the sub-TLV. It is
variable dependent on the length of the Sub-sub-TLVs field.
* Flags: 8-bit flags. All the 8 bits are reserved for future use,
which SHOULD be set to 0 on transmission and MUST be ignored on
receipt.
* Reserved: 8-bit field reserved for future use, SHOULD be set to 0
on transmission and MUST be ignored on receipt.
* VTN ID Sub-sub-TLV: contains one or more VTN IDs which is
associated with the same group of TE attributes.
Dong, et al. Expires 3 August 2022 [Page 10]
Internet-Draft IGP Extensions for SR VPN+ January 2022
* Other Sub-sub-TLVs: the TLVs which carry the TE attributes
associated with the VTNs.
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:
* Type: TBD
* Length: The length of the value field of the sub-sub-TLV. It is
the number of the VTN IDs in the TLV multiplied by 4.
* VTN ID: A global significant 32-bit identifier which is used to
identify a VTN.
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:
* Type: TBD
* Length: The length of the value field of the sub-sub-TLV. It is
set to 6.
* Flags: 8-bit flags. All the 8 bits are reserved for future use,
which SHOULD be set to 0 on transmission and MUST be ignored on
receipt.
Dong, et al. Expires 3 August 2022 [Page 11]
Internet-Draft IGP Extensions for SR VPN+ January 2022
* Reserved: 8-bit field reserved for future use, SHOULD be set to 0
on transmission and MUST be ignored on receipt.
* Bandwidth: The bandwidth allocated to the VTN, encoded in 32 bits
in IEEE floating point format.
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.
5. Advertisement of VTN specific Data Plane Identifiers
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.
5.1. Advertisement of VTN-specific SR-MPLS SIDs
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:
Dong, et al. Expires 3 August 2022 [Page 12]
Internet-Draft IGP Extensions for SR VPN+ January 2022
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:
* Type: TBD
* Length: The length of the value field of the sub-TLV. It is
variable dependent on the length of the SID/Index/Label field.
* Flags: 16-bit flags. The high-order 8 bits are the same as in the
Prefix-SID sub-TLV defined in [RFC8667]. The lower-order 8 bits
are reserved for future use, which SHOULD be set to 0 on
transmission and MUST be ignored on receipt.
* VTN ID: A 32-bit identifier to identify the VTN this prefix-SID
associates with.
* SID/Index/Label: The same as defined in [RFC8667].
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]
Dong, et al. Expires 3 August 2022 [Page 13]
Internet-Draft IGP Extensions for SR VPN+ January 2022
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:
* Type: TBD
* Length: The length of the value field of the sub-TLV. It is
variable dependent on the length of the SID/Index/Label field.
* Flags: 16-bit flags. The high-order 8 bits are the same as in the
Adj-SID sub-TLV defined in [RFC8667]. The lower-order 8 bits are
reserved for future use, which SHOULD be set to 0 on transmission
and MUST be ignored on receipt.
* VTN ID: A 32-bit global identifier to identify the VTN this Adj-
SID associates with.
* SID/Index/Label: The same as defined in [RFC8667].
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.
5.2. Advertisement of VTN-specific SRv6 Locators and SIDs
5.2.1. VTN-specific SRv6 Locators and End SIDs
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.
Dong, et al. Expires 3 August 2022 [Page 14]
Internet-Draft IGP Extensions for SR VPN+ January 2022
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:
* Type: TBD
* The semantics of the Length field, the R bits and the MT ID field
are the same as those defined in
[I-D.ietf-lsr-isis-srv6-extensions].
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:
* VTN ID: A 32-bit global identifier to identify the VTN this
Locator associates with.
* All the other fields are the same as those defined in
[I-D.ietf-lsr-isis-srv6-extensions].
Dong, et al. Expires 3 August 2022 [Page 15]
Internet-Draft IGP Extensions for SR VPN+ January 2022
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:
* Type: TBD
* Length: The length of the value field of the sub-TLV. It is
variable dependent on the number of VTNs and the Block Length.
* Number of VTNs: The number of VTNs which share the same topology/
algorithm specific Locator as the covering prefix.
* Block Length: The length of the VTN locator-block which follows
the length of the topology/algorithm specific Locator.
* VTN ID: A 32-bit global identifier to identify the VTN the
locator-block is associates with.
* Block Value: The value of the VTN locator-block for each VTN.
Dong, et al. Expires 3 August 2022 [Page 16]
Internet-Draft IGP Extensions for SR VPN+ January 2022
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.
5.2.2. VTN-specific SRv6 End.X SIDs
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:
* Type: TBD.
* Length: the length of the Value field of the TLV. It is set to 4.
* VTN ID: A 32-bit global identifier to identify the VTN this End.X
SID associates with.
5.3. Advertisement of Dedicated Data Plane VTN IDs
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
Dong, et al. Expires 3 August 2022 [Page 17]
Internet-Draft IGP Extensions for SR VPN+ January 2022
[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.
6. 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.
7. IANA Considerations
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".
Dong, et al. Expires 3 August 2022 [Page 18]
Internet-Draft IGP Extensions for SR VPN+ January 2022
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
8. Contributors
Hongjie Yang
Email: hongjie.yang@huawei.com
9. Acknowledgments
The authors would like to thank Mach Chen, Dean Cheng and Guoqi Xu
for their review and discussion of this document.
10. References
10.1. Normative References
[I-D.ietf-lsr-flex-algo]
Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and
A. Gulko, "IGP Flexible Algorithm", Work in Progress,
Internet-Draft, draft-ietf-lsr-flex-algo-18, 25 October
2021, <https://www.ietf.org/archive/id/draft-ietf-lsr-
flex-algo-18.txt>.
[I-D.ietf-lsr-isis-srv6-extensions]
Psenak, P., Filsfils, C., Bashandy, A., Decraene, B., and
Z. Hu, "IS-IS Extensions to Support Segment Routing over
IPv6 Dataplane", Work in Progress, Internet-Draft, draft-
ietf-lsr-isis-srv6-extensions-18, 20 October 2021,
<https://www.ietf.org/archive/id/draft-ietf-lsr-isis-srv6-
extensions-18.txt>.
[I-D.ietf-spring-resource-aware-segments]
Dong, J., Bryant, S., Miyasaka, T., Zhu, Y., Qin, F., Li,
Z., and F. Clad, "Introducing Resource Awareness to SR
Segments", Work in Progress, Internet-Draft, draft-ietf-
spring-resource-aware-segments-03, 12 July 2021,
<https://www.ietf.org/archive/id/draft-ietf-spring-
resource-aware-segments-03.txt>.
Dong, et al. Expires 3 August 2022 [Page 19]
Internet-Draft IGP Extensions for SR VPN+ January 2022
[I-D.ietf-spring-sr-for-enhanced-vpn]
Dong, J., Bryant, S., Miyasaka, T., Zhu, Y., Qin, F., Li,
Z., and F. Clad, "Segment Routing based Virtual Transport
Network (VTN) for Enhanced VPN", Work in Progress,
Internet-Draft, draft-ietf-spring-sr-for-enhanced-vpn-01,
12 July 2021, <https://www.ietf.org/archive/id/draft-ietf-
spring-sr-for-enhanced-vpn-01.txt>.
[I-D.ietf-teas-enhanced-vpn]
Dong, J., Bryant, S., Li, Z., Miyasaka, T., and Y. Lee, "A
Framework for Enhanced Virtual Private Network (VPN+)
Services", Work in Progress, Internet-Draft, draft-ietf-
teas-enhanced-vpn-09, 25 October 2021,
<https://www.ietf.org/archive/id/draft-ietf-teas-enhanced-
vpn-09.txt>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[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,
<https://www.rfc-editor.org/info/rfc4915>.
[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,
<https://www.rfc-editor.org/info/rfc5120>.
[RFC7981] Ginsberg, L., Previdi, S., and M. Chen, "IS-IS Extensions
for Advertising Router Information", RFC 7981,
DOI 10.17487/RFC7981, October 2016,
<https://www.rfc-editor.org/info/rfc7981>.
[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, <https://www.rfc-editor.org/info/rfc8402>.
[RFC8667] Previdi, S., Ed., Ginsberg, L., Ed., Filsfils, C.,
Bashandy, A., Gredler, H., and B. Decraene, "IS-IS
Extensions for Segment Routing", RFC 8667,
DOI 10.17487/RFC8667, December 2019,
<https://www.rfc-editor.org/info/rfc8667>.
Dong, et al. Expires 3 August 2022 [Page 20]
Internet-Draft IGP Extensions for SR VPN+ January 2022
[RFC8668] Ginsberg, L., Ed., Bashandy, A., Filsfils, C., Nanduri,
M., and E. Aries, "Advertising Layer 2 Bundle Member Link
Attributes in IS-IS", RFC 8668, DOI 10.17487/RFC8668,
December 2019, <https://www.rfc-editor.org/info/rfc8668>.
10.2. Informative References
[I-D.dong-6man-enhanced-vpn-vtn-id]
Dong, J., Li, Z., Xie, C., Ma, C., and G. Mishra,
"Carrying Virtual Transport Network (VTN) Identifier in
IPv6 Extension Header", Work in Progress, Internet-Draft,
draft-dong-6man-enhanced-vpn-vtn-id-06, 24 October 2021,
<https://www.ietf.org/archive/id/draft-dong-6man-enhanced-
vpn-vtn-id-06.txt>.
[I-D.dong-teas-nrp-scalability]
Dong, J., Li, Z., Gong, L., Yang, G., Guichard, J. N.,
Mishra, G., and F. Qin, "Scalability Considerations for
Network Resource Partition", Work in Progress, Internet-
Draft, draft-dong-teas-nrp-scalability-00, 17 December
2021, <https://www.ietf.org/archive/id/draft-dong-teas-
nrp-scalability-00.txt>.
[I-D.li-mpls-enhanced-vpn-vtn-id]
Li, Z. and J. Dong, "Carrying Virtual Transport Network
Identifier in MPLS Packet", Work in Progress, Internet-
Draft, draft-li-mpls-enhanced-vpn-vtn-id-01, 14 April
2021, <https://www.ietf.org/archive/id/draft-li-mpls-
enhanced-vpn-vtn-id-01.txt>.
Authors' Addresses
Jie Dong
Huawei Technologies
Email: jie.dong@huawei.com
Zhibo Hu
Huawei Technologies
Email: huzhibo@huawei.com
Zhenbin Li
Huawei Technologies
Email: lizhenbin@huawei.com
Dong, et al. Expires 3 August 2022 [Page 21]
Internet-Draft IGP Extensions for SR VPN+ January 2022
Xiongyan Tang
China Unicom
Email: tangxy@chinaunicom.cn
Ran Pang
China Unicom
Email: pangran@chinaunicom.cn
Lee JooHeon
LG U+
Email: playgame@lguplus.co.kr
Stewart Bryant
Futurewei Technologies
Email: stewart.bryant@gmail.com
Dong, et al. Expires 3 August 2022 [Page 22]