draft-ietf-spring-sr-for-enhanced-vpn-00.txt   draft-ietf-spring-sr-for-enhanced-vpn-01.txt 
SPRING Working Group J. Dong SPRING Working Group J. Dong
Internet-Draft Huawei Technologies Internet-Draft Huawei Technologies
Intended status: Informational S. Bryant Intended status: Informational S. Bryant
Expires: August 16, 2021 Futurewei Technologies Expires: January 13, 2022 Futurewei Technologies
T. Miyasaka T. Miyasaka
KDDI Corporation KDDI Corporation
Y. Zhu Y. Zhu
China Telecom China Telecom
F. Qin F. Qin
Z. Li Z. Li
China Mobile China Mobile
F. Clad F. Clad
Cisco Systems Cisco Systems
February 12, 2021 July 12, 2021
Segment Routing based Virtual Transport Network (VTN) for Enhanced VPN Segment Routing based Virtual Transport Network (VTN) for Enhanced VPN
draft-ietf-spring-sr-for-enhanced-vpn-00 draft-ietf-spring-sr-for-enhanced-vpn-01
Abstract Abstract
Segment Routing (SR) leverages the source routing paradigm. A node Segment Routing (SR) leverages the source routing paradigm. A node
steers a packet through an ordered list of instructions, called steers a packet through an ordered list of instructions, called
"segments". A segment can represent topological or service based "segments". A segment can represent topological or service based
instructions. A segment can further be associated with a set of instructions. A segment can further be associated with a set of
network resources used for executing the instruction. Such a segment network resources used for executing the instruction. Such a segment
is called resource-aware segment. is called resource-aware segment.
skipping to change at page 2, line 10 skipping to change at page 2, line 10
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 16, 2021. This Internet-Draft will expire on January 13, 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 4, line 37 skipping to change at page 4, line 37
In the case of multi-domain VTNs, on an inter-domain link, multiple In the case of multi-domain VTNs, on an inter-domain link, multiple
BGP peering SIDs [I-D.ietf-idr-bgpls-segment-routing-epe] are BGP peering SIDs [I-D.ietf-idr-bgpls-segment-routing-epe] are
allocated, each of which is associated with a VTN which spans allocated, each of which is associated with a VTN which spans
multiple domains, and represents a subset of resources allocated on multiple domains, and represents a subset of resources allocated on
the inter-domain link. the inter-domain link.
2.2. SRv6 based VTN 2.2. SRv6 based VTN
This section describes a mechanism of allocating resource-aware SRv6 This section describes a mechanism of allocating resource-aware SRv6
Locators and SIDs to SRv6 based VTN.s Locators and SIDs to SRv6 based VTNs.
For a network node, multiple SRv6 Locators are allocated, each of For a network node, multiple SRv6 Locators are allocated, each of
which is associated with a VTN the node participates in, and which is associated with a VTN the node participates in, and
identifies the set of network resources allocated to the VTN on identifies the set of network resources allocated to the VTN on
network nodes which participate in the VTN. The SRv6 SIDs associated network nodes which participate in the VTN. The SRv6 SIDs associated
with a VTN are allocated from the SID space using the VTN-specific with a VTN are allocated from the SID space using the VTN-specific
Locator as the prefix. These SRv6 SIDs can be used to represent VTN- Locator as the prefix. These SRv6 SIDs can be used to represent VTN-
specific SRv6 functions, and can identify the set of resources used specific SRv6 functions, and can identify the set of resources used
by network nodes to process packets. by network nodes to process packets.
skipping to change at page 6, line 22 skipping to change at page 6, line 22
aware SIDs can be allocated for the VTN. With SR-MPLS, it is a group aware SIDs can be allocated for the VTN. With SR-MPLS, it is a group
of prefix-SIDs and adj-SIDs which are allocated to identify the of prefix-SIDs and adj-SIDs which are allocated to identify the
network nodes and links in the VTN, and also identify the set of network nodes and links in the VTN, and also identify the set of
network resources allocated on these network nodes and links for the network resources allocated on these network nodes and links for the
VTN. As the resource-aware SIDs can be allocated either by a VTN. As the resource-aware SIDs can be allocated either by a
centralized network controller or by the network nodes, control plane centralized network controller or by the network nodes, control plane
protocols such as IGP (e.g. IS-IS or OSPF) and BGP-LS can be used to protocols such as IGP (e.g. IS-IS or OSPF) and BGP-LS can be used to
distribute the SIDs and the associated resource and topology distribute the SIDs and the associated resource and topology
information of a VTN to other nodes in the same VTN and also to the information of a VTN to other nodes in the same VTN and also to the
controller, so that both the network nodes and the controller can controller, so that both the network nodes and the controller can
generate the VTN-specific forwarding entries based on the resource- generate the VTN-specific forwarding table or forwarding entries
aware SIDs of the VTN. The detailed control plane mechanisms and based on the resource-aware SIDs of the VTN. The detailed control
possible extensions are described in separate documents and are out plane mechanisms and possible extensions are described in separate
of the scope of this document. documents and are out of the scope of this document.
3.1. VTN Topology and Resource Planning 3.1. VTN Topology and Resource Planning
A centralized network controller can be responsible for the planning A centralized network controller can be responsible for the planning
of a VTN to meet the received service request. The controller needs of a VTN to meet the received service request. The controller needs
to collect the information on network connectivity, network to collect the information on network connectivity, network
resources, network performance and any other relevant network states resources, network performance and any other relevant network states
from the underlay network. This can be done using either IGP TE from the underlay network. This can be done using either IGP TE
extensions such as [RFC5305] [RFC3630] [RFC7471] [RFC8570], and/or extensions such as [RFC5305] [RFC3630] [RFC7471] [RFC8570], and/or
BGP-LS [RFC7752] [RFC8571], or any other form of control plane BGP-LS [RFC7752] [RFC8571], or any other form of control plane
skipping to change at page 7, line 8 skipping to change at page 7, line 8
segment (e.g. links and nodes) in the sub-topology to meet the segment (e.g. links and nodes) in the sub-topology to meet the
service requirements, whilst maintaining the needs of the existing service requirements, whilst maintaining the needs of the existing
services that are using the same network. The subset of the network services that are using the same network. The subset of the network
topology and network resources will be used to constitute a VTN, and topology and network resources will be used to constitute a VTN, and
will be used as the virtual underlay network of the requested will be used as the virtual underlay network of the requested
service. service.
3.2. VTN Network Resource and SID Allocation 3.2. VTN Network Resource and SID Allocation
According to the result of VTN planning, the network controller According to the result of VTN planning, the network controller
instructs the set of network nodes involved to join the VTN and instructs the set of network nodes involved to join a specific VTN
allocate the required set of network resources for the VTN. This may and allocate the required set of network resources for the VTN. This
be done with PCEP [RFC5440], Netconf/YANG [RFC6241] [RFC7950] or with may be done with Netconf/YANG [RFC6241] [RFC7950] or with any other
any other control or management plane mechanism with necessary control or management plane mechanism with necessary extensions.
extensions. Thus, the controller not only allocates the resources to Thus, the controller not only allocates the resources to the newly
the newly computed VTN but also keeps track of the remaining computed VTN but also keeps track of the remaining available
available resources in order to cope with subsequent VTN requests. resources in order to cope with subsequent VTN requests.
On each network node involved in the VTN, a set of network resources On each network node involved in the VTN, a set of network resources
(e.g. link bandwidth) are allocated to the VTN. Such set of network (e.g. link bandwidth) are allocated to the VTN. Such set of network
resources can be dedicated for the processing of traffic in that VTN, resources can be dedicated for the processing of traffic in that VTN,
and cannot be used by traffic in other VTNs. Note it is also and cannot be used by traffic in other VTNs. Note it is also
possible that a group of VTNs may share a set of network resources on possible that a group of VTNs may share a set of network resources on
some network segments. A group of resource-aware SIDs, such as some network segments. A group of resource-aware SIDs, such as
prefix-SIDs and adj-SIDs are allocated to identify both the network prefix-SIDs and adj-SIDs are allocated to identify both the network
segments and the set of resources allocated on the network segments segments and the set of resources allocated on the network segments
for the VTN. Such group of resource-aware SIDs, e.g. prefix-SIDs and for the VTN. Such group of resource-aware SIDs, e.g. prefix-SIDs and
skipping to change at page 9, line 39 skipping to change at page 9, line 39
associated network resources and topology information. Based on the associated network resources and topology information. Based on the
collected information, the network nodes which are the headend of a collected information, the network nodes which are the headend of a
path can perform VTN-specific path computation, and build the SID path can perform VTN-specific path computation, and build the SID
list using the collected resource-aware adj-SIDs and prefix-SIDs. list using the collected resource-aware adj-SIDs and prefix-SIDs.
The network nodes also need to generate the forwarding entries for The network nodes also need to generate the forwarding entries for
the resource-aware prefix-SIDs in each VTN they participates in, and the resource-aware prefix-SIDs in each VTN they participates in, and
associate these forwarding entries with the set of local network associate these forwarding entries with the set of local network
resources (e.g. a set of bandwidth on the outgoing interface) resources (e.g. a set of bandwidth on the outgoing interface)
allocated to the corresponding VTN. allocated to the corresponding VTN.
Thus each network node needs to advertise the VTNs it participates Thus after receiving the network controller's instruction of network
in, the group of resource-aware SIDs allocated to each VTN, and the resource and SID allocation, each network node needs to advertise the
resource attributes (e.g. bandwidth) associated with the resource- identifier of the VTNs it participates in, the group of resource-
aware SIDs in the network. Each resource-aware adj-SID is advertised aware SIDs allocated to each VTN, and the resource attributes (e.g.
with the set of associated link resources, and each resource-aware bandwidth) associated with the resource-aware SIDs in the network.
prefix-SID is advertised with the identifier of the associated VTN, Each resource-aware adj-SID is advertised with the set of associated
as all the prefix-SIDs in a VTN are associated with the same set of link resources, and each resource-aware prefix-SID is advertised with
network resources allocated to the VTN. Note as described in section the identifier of the associated VTN, as all the prefix-SIDs in a VTN
2.3, the VTN can be identified in the control plane either by are associated with the same set of network resources allocated to
existing IDs, or a new VTN ID. the VTN. Note that as described in section 2.3, the VTNs can be
identified in the control plane either using existing identifiers,
such as the MT-ID or Flex-Algo ID, or using a newly defined VTN ID.
The IGP mechanisms which reuse the existing IDs such as Multi- The IGP mechanisms which reuse the existing IDs such as Multi-
Topology [RFC5120] or Flex-Algo [I-D.ietf-lsr-flex-algo] as the Topology [RFC5120] or Flex-Algo [I-D.ietf-lsr-flex-algo] as the
identifier of VTNs, and distribute the resource-aware SIDs and the identifier of VTNs, and distribute the resource-aware SIDs and the
associated topology and resource information are described in associated topology and resource information are described in
[I-D.xie-lsr-isis-sr-vtn-mt] and [I-D.zhu-lsr-isis-sr-vtn-flexalgo] [I-D.ietf-lsr-isis-sr-vtn-mt] and [I-D.zhu-lsr-isis-sr-vtn-flexalgo]
respectively. The corresponding BGP-LS mechanisms which can be used respectively. The corresponding BGP-LS mechanisms which can be used
to distribute both the intra-domain VTN information and the inter- to distribute both the intra-domain VTN information and the inter-
domain VTN-specfic link information to the controller are described domain VTN-specfic link information to the controller are described
in [I-D.xie-idr-bgpls-sr-vtn-mt] and in [I-D.xie-idr-bgpls-sr-vtn-mt] and
[I-D.zhu-idr-bgpls-sr-vtn-flexalgo] respectively. Note that with [I-D.zhu-idr-bgpls-sr-vtn-flexalgo] respectively. Note that with
these mechanisms, the number of VTNs supported relies on the number these mechanisms, the number of VTNs supported relies on the number
of topologies or algorithms supported. of topologies or algorithms supported.
The IGP mechanisms described in [I-D.dong-lsr-sr-enhanced-vpn] The IGP mechanisms described in [I-D.dong-lsr-sr-enhanced-vpn]
introduce a new VTN-ID in control plane, so that multiple VTNs can be introduce a new VTN-ID in the control plane, so that multiple VTNs
mapped to the same <topology, algorithm> tuple, while each VTN can can be mapped to the same <topology, algorithm> tuple, while each VTN
have different resource attributes. This allows flexible combination can have different resource attributes. This allows flexible
of network topology and network resources attributes to build a large combination of network topology and network resources attributes to
number of VTNs with a relatively small number of topologies or build a large number of VTNs with a relatively small number of
algorithms. The corresponding BGP-LS mechanisms which can be used to topologies or algorithms. The corresponding BGP-LS mechanisms which
distribute the intra-domain VTN information and the inter-domain VTN- can be used to distribute the intra-domain VTN information and the
specific link information to the controller are described in inter-domain VTN-specific link information to the controller are
[I-D.dong-idr-bgpls-sr-enhanced-vpn]. described in [I-D.dong-idr-bgpls-sr-enhanced-vpn].
Figure 2 shows the three SR based VTNs created in the network in Figure 2 shows the three SR based VTNs created in the network in
Figure 1. Figure 1.
1001 1001 2001 2001 3001 3001 1001 1001 2001 2001 3001 3001
101---------102 201---------202 301---------302 101---------102 201---------202 301---------302
| | \1003 | | \2003 | | | | \1003 | | \2003 | |
1002| 1002| \ 1001 2002| 2002| \ 2001 3002| 3002| 1002| 1002| \ 1001 2002| 2002| \ 2001 3002| 3002|
| | 105 | | 205 | | | | 105 | | 205 | |
1001| 1002| / 1002 2001| 2002| / 2002 3001| 3002| 1001| 1002| / 1002 2001| 2002| / 2002 3001| 3002|
skipping to change at page 11, line 45 skipping to change at page 11, line 48
steering of service traffic to SR based VTNs can be based on either steering of service traffic to SR based VTNs can be based on either
local policy or the mechanisms as defined in local policy or the mechanisms as defined in
[I-D.ietf-spring-segment-routing-policy]. [I-D.ietf-spring-segment-routing-policy].
3.5. VTN Visibility to Customer 3.5. VTN Visibility to Customer
VTNs can be used by network operators to organize and split their VTNs can be used by network operators to organize and split their
network infrastructure into different virtual underlay networks for network infrastructure into different virtual underlay networks for
different customers or services. Some customers may also request different customers or services. Some customers may also request
different granularity of visibility to the VTN which is used to different granularity of visibility to the VTN which is used to
deliver the service. Depending on the requirement, VTN can be deliver the service. Depending on the requirement, VTN may be
exposed to the customer either as a virtual network with both the exposed to the customer either as a virtual network with both the
edge nodes and the intermediate nodes, or a set of paths with some of edge nodes and the intermediate nodes, or a set of paths with some of
the transit nodes, or simply a set of virtual connections between the the transit nodes, or simply a set of virtual connections between the
endpoints without any transit node information. The visibility may endpoints without any transit node information. The visibility may
be delivered through different possible mechanisms, such as IGPs be delivered through different possible mechanisms, such as IGPs
(e.g. IS-IS, OSPF), BGP-LS or Netconf/YANG. On the other hand, (e.g. IS-IS, OSPF), BGP-LS or Netconf/YANG. On the other hand,
network operators may want to restrict the visibility of the underlay network operators may want to restrict the visibility of the underlay
network information it delivers to the customer by either hiding the network information it delivers to the customer by either hiding the
transit nodes between sites (and only delivering the endpoints transit nodes between sites (and only delivering the endpoints
connectivity), or by hiding portions of the transit nodes connectivity), or by hiding portions of the transit nodes
(summarizing the path into fewer nodes). Mechanisms such as BGP-LS (summarizing the path into fewer nodes). The information of VTNs
allow the flexibility of the advertisement of aggregated virtual which are not used by the customer should also be filtered.
network information. Mechanisms such as BGP-LS allow the flexibility of the advertisement
of aggregated virtual network information and configurable filtering
policies.
4. Characteristics of SR based VTN 4. Characteristics of SR based VTN
The proposed mechanism provides several key characteristics: The proposed mechanism provides several key characteristics:
o Customization: Different customized VTNs can be created in a o Customization: Different customized VTNs can be created in a
shared network to meet different customers' connectivity and shared network to meet different customers' connectivity and
service requirement. Each customer is only aware of the topology service requirement. Each customer is only aware of the topology
and attributes of his own VTN, and provision services on the VTN and attributes of his own VTN, and provision services on the VTN
instead of the shared physical network. This provides an instead of the shared physical network. This provides an
skipping to change at page 14, line 21 skipping to change at page 14, line 23
Zhenbin Li Zhenbin Li
Email: lizhenbin@huawei.com Email: lizhenbin@huawei.com
Zhibo Hu Zhibo Hu
Email: huzhibo@huawei.com Email: huzhibo@huawei.com
9. Acknowledgements 9. Acknowledgements
The authors would like to thank Mach Chen, Stefano Previdi, Charlie The authors would like to thank Mach Chen, Stefano Previdi, Charlie
Perkins, Bruno Decraene, Loa Andersson, Alexander Vainshtein, Joel Perkins, Bruno Decraene, Loa Andersson, Alexander Vainshtein, Joel
Halpern, James Guichard and Adrian Farrel for the valuable discussion Halpern, James Guichard, Adrian Farrel and Shunsuke Homma for the
and suggestions to this document. valuable discussion and suggestions to this document.
10. References 10. References
10.1. Normative References 10.1. Normative References
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
July 2018, <https://www.rfc-editor.org/info/rfc8402>. July 2018, <https://www.rfc-editor.org/info/rfc8402>.
skipping to change at page 14, line 47 skipping to change at page 14, line 49
<https://www.rfc-editor.org/info/rfc8660>. <https://www.rfc-editor.org/info/rfc8660>.
10.2. Informative References 10.2. Informative References
[DetNet] "DetNet WG", 2016, [DetNet] "DetNet WG", 2016,
<https://datatracker.ietf.org/wg/detnet>. <https://datatracker.ietf.org/wg/detnet>.
[I-D.dong-idr-bgpls-sr-enhanced-vpn] [I-D.dong-idr-bgpls-sr-enhanced-vpn]
Dong, J., Hu, Z., Li, Z., Tang, X., and R. Pang, "BGP-LS Dong, J., Hu, Z., Li, Z., Tang, X., and R. Pang, "BGP-LS
Extensions for Segment Routing based Enhanced VPN", draft- Extensions for Segment Routing based Enhanced VPN", draft-
dong-idr-bgpls-sr-enhanced-vpn-02 (work in progress), June dong-idr-bgpls-sr-enhanced-vpn-03 (work in progress),
2020. February 2021.
[I-D.dong-lsr-sr-enhanced-vpn] [I-D.dong-lsr-sr-enhanced-vpn]
Dong, J., Hu, Z., Li, Z., Tang, X., Pang, R., JooHeon, L., Dong, J., Hu, Z., Li, Z., Tang, X., Pang, R., JooHeon, L.,
and S. Bryant, "IGP Extensions for Segment Routing based and S. Bryant, "IGP Extensions for Segment Routing based
Enhanced VPN", draft-dong-lsr-sr-enhanced-vpn-04 (work in Enhanced VPN", draft-dong-lsr-sr-enhanced-vpn-05 (work in
progress), June 2020. progress), February 2021.
[I-D.ietf-idr-bgpls-segment-routing-epe] [I-D.ietf-idr-bgpls-segment-routing-epe]
Previdi, S., Talaulikar, K., Filsfils, C., Patel, K., Ray, Previdi, S., Talaulikar, K., Filsfils, C., Patel, K., Ray,
S., and J. Dong, "BGP-LS extensions for Segment Routing S., and J. Dong, "BGP-LS extensions for Segment Routing
BGP Egress Peer Engineering", draft-ietf-idr-bgpls- BGP Egress Peer Engineering", draft-ietf-idr-bgpls-
segment-routing-epe-19 (work in progress), May 2019. segment-routing-epe-19 (work in progress), May 2019.
[I-D.ietf-lsr-flex-algo] [I-D.ietf-lsr-flex-algo]
Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and
A. Gulko, "IGP Flexible Algorithm", draft-ietf-lsr-flex- A. Gulko, "IGP Flexible Algorithm", draft-ietf-lsr-flex-
algo-13 (work in progress), October 2020. algo-15 (work in progress), April 2021.
[I-D.ietf-lsr-isis-sr-vtn-mt]
Xie, C., Ma, C., Dong, J., and Z. Li, "Using IS-IS Multi-
Topology (MT) for Segment Routing based Virtual Transport
Network", draft-ietf-lsr-isis-sr-vtn-mt-00 (work in
progress), March 2021.
[I-D.ietf-spring-resource-aware-segments] [I-D.ietf-spring-resource-aware-segments]
Dong, J., Bryant, S., Miyasaka, T., Zhu, Y., Qin, F., Li, Dong, J., Bryant, S., Miyasaka, T., Zhu, Y., Qin, F., Li,
Z., and F. Clad, "Introducing Resource Awareness to SR Z., and F. Clad, "Introducing Resource Awareness to SR
Segments", draft-ietf-spring-resource-aware-segments-01 Segments", draft-ietf-spring-resource-aware-segments-02
(work in progress), January 2021. (work in progress), February 2021.
[I-D.ietf-spring-segment-routing-policy] [I-D.ietf-spring-segment-routing-policy]
Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and
P. Mattes, "Segment Routing Policy Architecture", draft- P. Mattes, "Segment Routing Policy Architecture", draft-
ietf-spring-segment-routing-policy-09 (work in progress), ietf-spring-segment-routing-policy-11 (work in progress),
November 2020. April 2021.
[I-D.ietf-spring-srv6-network-programming] [I-D.ietf-spring-srv6-network-programming]
Filsfils, C., Camarillo, P., Leddy, J., Voyer, D., Filsfils, C., Garvia, P. C., Leddy, J., Voyer, D.,
Matsushima, S., and Z. Li, "SRv6 Network Programming", Matsushima, S., and Z. Li, "Segment Routing over IPv6
draft-ietf-spring-srv6-network-programming-28 (work in (SRv6) Network Programming", draft-ietf-spring-srv6-
progress), December 2020. network-programming-28 (work in progress), December 2020.
[I-D.ietf-teas-enhanced-vpn] [I-D.ietf-teas-enhanced-vpn]
Dong, J., Bryant, S., Li, Z., Miyasaka, T., and Y. Lee, "A Dong, J., Bryant, S., Li, Z., Miyasaka, T., and Y. Lee, "A
Framework for Enhanced Virtual Private Networks (VPN+) Framework for Enhanced Virtual Private Network (VPN+)
Service", draft-ietf-teas-enhanced-vpn-06 (work in Services", draft-ietf-teas-enhanced-vpn-07 (work in
progress), July 2020. progress), February 2021.
[I-D.xie-idr-bgpls-sr-vtn-mt] [I-D.xie-idr-bgpls-sr-vtn-mt]
Xie, C., Li, C., Dong, J., and Z. Li, "BGP-LS with Multi- Xie, C., Li, C., Dong, J., and Z. Li, "BGP-LS with Multi-
topology for Segment Routing based Virtual Transport topology for Segment Routing based Virtual Transport
Networks", draft-xie-idr-bgpls-sr-vtn-mt-02 (work in Networks", draft-xie-idr-bgpls-sr-vtn-mt-02 (work in
progress), January 2021. progress), January 2021.
[I-D.xie-lsr-isis-sr-vtn-mt]
Xie, C., Ma, C., Dong, J., and Z. Li, "Using IS-IS Multi-
Topology (MT) for Segment Routing based Virtual Transport
Network", draft-xie-lsr-isis-sr-vtn-mt-02 (work in
progress), October 2020.
[I-D.zhu-idr-bgpls-sr-vtn-flexalgo] [I-D.zhu-idr-bgpls-sr-vtn-flexalgo]
Zhu, Y., Dong, J., and Z. Hu, "BGP-LS with Flex-Algo for Zhu, Y., Dong, J., and Z. Hu, "BGP-LS with Flex-Algo for
Segment Routing based Virtual Transport Networks", draft- Segment Routing based Virtual Transport Networks", draft-
zhu-idr-bgpls-sr-vtn-flexalgo-00 (work in progress), March zhu-idr-bgpls-sr-vtn-flexalgo-01 (work in progress),
2020. February 2021.
[I-D.zhu-lsr-isis-sr-vtn-flexalgo] [I-D.zhu-lsr-isis-sr-vtn-flexalgo]
Zhu, Y., Dong, J., and Z. Hu, "Using Flex-Algo for Segment Zhu, Y., Dong, J., and Z. Hu, "Using Flex-Algo for Segment
Routing based VTN", draft-zhu-lsr-isis-sr-vtn-flexalgo-01 Routing based VTN", draft-zhu-lsr-isis-sr-vtn-flexalgo-02
(work in progress), September 2020. (work in progress), February 2021.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
<https://www.rfc-editor.org/info/rfc3209>. <https://www.rfc-editor.org/info/rfc3209>.
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
(TE) Extensions to OSPF Version 2", RFC 3630, (TE) Extensions to OSPF Version 2", RFC 3630,
DOI 10.17487/RFC3630, September 2003, DOI 10.17487/RFC3630, September 2003,
<https://www.rfc-editor.org/info/rfc3630>. <https://www.rfc-editor.org/info/rfc3630>.
 End of changes. 23 change blocks. 
68 lines changed or deleted 72 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/