IGP Extensions for Segment Routing based Enhanced VPN
draft-dong-lsr-sr-enhanced-vpn-02
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Active".
|
|
|---|---|---|---|
| Authors | Jie Dong , Zhibo Hu, Stewart Bryant | ||
| Last updated | 2019-11-04 (Latest revision 2018-10-22) | ||
| RFC stream | (None) | ||
| Formats | |||
| Additional resources | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-dong-lsr-sr-enhanced-vpn-02
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,
<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>.
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,
<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>.
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]