Internet DRAFT - draft-li-spring-tunnel-segment
draft-li-spring-tunnel-segment
Network Working Group Z. Li
Internet-Draft C. Li
Intended status: Standards Track N. Wu
Expires: October 16, 2021 Huawei
April 14, 2021
Tunnel Segment in Segment Routing
draft-li-spring-tunnel-segment-02
Abstract
This document introduces a new type of segment, Tunnel Segment, for
the segment routing (SR). Tunnel segment can be used to reduce SID
stack depth of SR path, span the non-SR domain or provide
differentiated services.
Forwarding mechanisms and requirements of control plane and data
models for tunnel segments are also defined.
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."
This Internet-Draft will expire on October 16, 2021.
Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved.
Li, et al. Expires October 16, 2021 [Page 1]
Internet-Draft Tunnel Segment in SR April 2021
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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Usecases . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Reducing SID Stack Depth . . . . . . . . . . . . . . . . 3
3.2. Passing through Non-SR Domain . . . . . . . . . . . . . . 4
3.3. Differentiated Services . . . . . . . . . . . . . . . . . 5
4. Comparison with Agency Segment . . . . . . . . . . . . . . . 6
5. Forwarding Mechanisms . . . . . . . . . . . . . . . . . . . . 6
6. Requirement of Control Plane and Yang Models . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
8. Security Considerations . . . . . . . . . . . . . . . . . . . 8
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
9.1. Normative References . . . . . . . . . . . . . . . . . . 8
9.2. Informative References . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
Segment Routing (SR), introduced by [RFC8402], leverages the source
routing paradigm. A packet can be steered through an ordered list of
instructions, which are also called segments. The node segment,
adjacency segment, etc. have been proposed for different usecases.
This document introduces a new type of segment, Tunnel Segment, for
the segment routing. Tunnel segment can be used to reduce SID stack
depth of SR path, span the non-SR domain or provide differentiated
services. Forwarding mechanisms and requirements of control plane
and data models for tunnel segments are also defined.
2. Terminology
o SID: Segment ID
o SR: Segment Routing
o SR Path: Segment Routing Path
Li, et al. Expires October 16, 2021 [Page 2]
Internet-Draft Tunnel Segment in SR April 2021
o SR-TE Path: Segment Routing Traffic Engineering Path
o MSD: Maximally SID Depth
The terms "Tunnel Segment" and "Tunnel SID" are the generic names for
a segment attached to a specific tunnel. A tunnel segment can be
used to steer traffic into the corresponding tunnel along the SR
path.
3. Usecases
3.1. Reducing SID Stack Depth
It is possible that a SR path has to take an explicit path with
multiple hops instead of the shortest path for the purpose of traffic
engineering. As a result, the ingress node has to push lots of
segments to steer the packet, which could be a challenge for the
forwarding plane, since the depth of this segment stack may be beyond
the capability of their forwarding engines. The tunnel segment
introduced in this document will be helpful to mitigate the pain in
these scenarios.
Taking Figure 1 below as an example, the SR-TE path is created from
SR-Node-1(ingress) to SR-Node-2(egress). The original SID stack, {A,
B, X, E, F, G, H, Y, J, K}, is too overwhelming for the path MSD.
With help of the tunnel segment, the tunnel from Gateway-Node-1 to
Gateway-Node-2 can be represented by a dedicated SID, saying Z. So
the SR-TE path can be represented as {A, B, X, Z, J, K}. Comparing
with the original SR-TE path, the SID stack depth is reduced.
The SR-TE tunnel can be created through two ways:
1. Manually configure on ingress node (Gateway-Node-1) and designate
the SID binding to it. This binding relationship needs to be
propagated to PCE/controller or advertised to other nodes in the
network.
2. With the knowledge of all MSD along the path, a PCE/controller
can calculate SR-TE tunnels using for reduce SID stack depth and
determine ingress/egress gateway nodes dynamically. Those SR-TE
tunnels can be created through PCE initiated style. The
corresponding tunnel segment and the binding relationship can be
propagated to ingress nodes and other nodes if necessary. As
shown in Figure 1, ingress (SR-Node-1) can receive update
messages from PCE/controller about the binding relationship. And
SR-Node-1 can calculate the SR-TE path with the SR-TE tunnel
segment without the help of PCE/controller in a centralized
manner.
Li, et al. Expires October 16, 2021 [Page 3]
Internet-Draft Tunnel Segment in SR April 2021
SID stack +------------+
{A, B, X, Z, J, K}| PCE/ |
+--------------| Controller |
| +------------+
| ^ Tunnel Binding
| | SID (Z)
| | .-----.
| | ( )
V V .--( )--.
+------+ +-------+ ( ) +-------+ +------+
| SR |_(...)_|Gateway|_( SR Network )_|Gateway|_(...)_ | SR |
|Node 1| (...) |Node-1 | ( ================> ) |Node-2 | (...) |Node 2|
+------+ +-------+ ( SR-TE Tunnel ) +-------+ +------+
'--( )--'
( )
'-----'
{A,B} {X} {E, F, G, H} {Y} {J,K}
Figure 1 Usecase for Reducing SID Stack Depth
3.2. Passing through Non-SR Domain
The tunnel segment can also be used in those scenarios that traffic
has to pass through non-SR domains. In another word, tunnel segment
can be used to connect SR islands.
As shown in Figure 2, traffic from SR-Node-1 to SR-Node-2 has to pass
through a traditional IP/MPLS network. Usually a RSVP-TE tunnel or
IP tunnel will be created between two gateway nodes. By allocating
SID for this tunnel, saying Z, the SR path from SR-Node-1 to SR-
Node-2 can be represented as {A, B, X, Z, J, K}.
In this scenario, the RSVP-TE tunnel or IP tunnel can be involved
into SR networks through two ways:
1. Manually configure on ingress node (Gateway-Node-1) and designate
the SID binding to it. This binding relationship needs to be
propagated to PCE/controller or advertised to other nodes in the
network.
2. With the knowledge of topology of non-SR domain, a PCE/controller
can calculate RSVP-TE tunnels or IP tunnels and determine
ingress/egress gateway nodes dynamically. Those RSVP-TE tunnels
or IP tunnels can be created through PCE initiated style. The
Li, et al. Expires October 16, 2021 [Page 4]
Internet-Draft Tunnel Segment in SR April 2021
corresponding tunnel segment and the binding relationship can be
propagated to ingress nodes and other nodes if necessary. As
shown in Figure 2, ingress (SR-Node-1) can receive update
messages from PCE/controller about the binding relationship. And
SR-Node-1 can calculate the SR-TE path which can pass through
non-SR domain without the help of PCE/controller in a centralized
manner.
SID stack +------------+
{A, B, X, Z, J, K}| PCE/ |
+--------------| Controller |
| +------------+
| ^ Tunnel Binding
| | SID (Z)
| | .-----.
| | ( )
V V .--( )--.
+------+ +-------+ ( ) +-------+ +------+
| SR |_(...)_|Gateway|_( IP/MPLS Network )_|Gateway|_(...)_ | SR |
|Node 1| (...) |Node-1 | ( ================> ) |Node-2 | (...) |Node 2|
+------+ +-------+ (MPLS TE/IP Tunnel) +-------+ +------+
'--( )--'
( )
'-----'
{A,B} {X} {E, F, G, H} {Y} {J,K}
Figure 2 Usecase for Passing through Non-SR Domain
3.3. Differentiated Services
It is necessary to create multiple tunnels between the same pair of
gateway nodes to support different services, since different tunnels
can have different attributes. As a result, different SIDs have to
be assigned per tunnel. Then an End-to-End SR path can choose
different SIDs at ingress according to the service requirement when
passing through the network between gateway nodes.
As depicted in Figure 3, two RSVP-TE tunnels, say RSVP-TE-tunnel1 and
RSVP-TE-tunnel2, are created in MPLS network to provide different
bandwidth guarantee services. And two SIDs, Z1 and Z2, are allocated
and mapped to these two tunnels separately. These two SIDs can be
utilized by a PCE/controller when defining the SR path at ingress.
Since different traffic will transport through different tunnels,
differentiated services can be guaranteed.
Li, et al. Expires October 16, 2021 [Page 5]
Internet-Draft Tunnel Segment in SR April 2021
SID stack
{A, B, X, Z1, J, K}+------------+
{A, B, X, Z2, J, K}| PCE/ |
+---------------| Controller |
| +------------+
| ^ Tunnel Binding
| | SID (Z)
| | .-----.
| | ( )
V V .--( )--.
+------+ +-------+ (MPLS TE Tunnel 1 ) +-------+ +------+
| SR |_(...)_|Gateway|_( ================> )_|Gateway|_(...)_ | SR |
|Node 1| (...) |Node-1 | ( ================> ) |Node-2 | (...) |Node 2|
+------+ +-------+ (MPLS TE Tunnel 2 ) +-------+ +------+
'--( )--'
( )
'-----'
{A,B} {X} {E, F, G, H} {Y} {J,K}
Figure 3 Usecase for Differentiated Services
4. Comparison with Agency Segment
As described in [RFC8402], a tunnel can be represented by an Adj-SID
or as a Forwarding Adjacency. One obvious benefit of the method is
to unify the process. But it may be necessary to differentiate a
tunnel segment from other adjacency segment in some scenarios since
there are more attributes attached to a tunnel.
By introducing the tunnel segment, this document expects not only to
inform the binding relationship between a tunnel and a SID but also
to learn tunnel information as much as possible. For example, it
will be helpful for SR-capable nodes to know the detail of an
explicit path that passes through non-SR networks.
In addition, one tunnel will need an IP address if handled as an
adjacency (a borrowed IP address at least). While a tunnel binding
to a Tunnel-SID does not have to contain an IP address, only an
ingress node and an egress node is enough.
5. Forwarding Mechanisms
In the gateway node, when received the packet with the tunnel segment
SID as the topmost SID, it will use the forwarding mechanism shown in
the following figure to steering the traffic to the corresponding
tunnel.
Li, et al. Expires October 16, 2021 [Page 6]
Internet-Draft Tunnel Segment in SR April 2021
+--------+ +------------------------+
| SID |--->| Tunnel Forwarding Info |
+--------+ +------------------------+
SID: Segment ID
Figure 4 Forwarding Mechanisms for Tunnel Segment
6. Requirement of Control Plane and Yang Models
According to the procedures of the above usecases, following
requirements of control plane and Yang models for Tunnel Segment are
proposed:
o REQ 01: IGP extensions SHOULD be introduced to advertise the
binding relationship between a SID/label and the corresponding
tunnel. Attributes of the tunnel MAY be carried optionally.
o REQ 02: BGP Link-State extension SHOULD be introduced to advertise
the binding relationship between a label and the corresponding
tunnel. Attributes of the tunnel MAY be carried optionally.
o REQ 03: PCEP extensions SHOULD be introduced to advertise the
binding relationship between a SID/label and the corresponding
tunnel from a PCC to a PCE. Attributes of the tunnel MAY be
carried optionally.
o REQ 04: PCE SHOULD support initiated IP tunnel.
o REQ 05: PCE SHOULD support to allocate SID/label for the
corresponding tunnel dynamically.
o REQ 06: PCEP extensions SHOULD be introduced to distribute the
binding relationship between a SID/label and the corresponding
tunnel from a PCE to a PCC. Attributes of the tunnel MAY be
carried optionally.
o REQ 07: An I2RS interface SHOULD be available for allocating SID/
label to the corresponding tunnel. And augmentation on segment
routing YANG models SHOULD be introduced.
7. IANA Considerations
This document makes no request of IANA.
Li, et al. Expires October 16, 2021 [Page 7]
Internet-Draft Tunnel Segment in SR April 2021
8. Security Considerations
This document does not introduce new security threat.
9. References
9.1. Normative References
[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>.
9.2. Informative References
[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>.
Authors' Addresses
Zhenbin Li
Huawei
Huawei Bld., No.156 Beiqing Rd.
Beijing 100095
China
Email: lizhenbin@huawei.com
Cheng Li
Huawei
Huawei Campus, No. 156 Beiqing Rd.
Beijing 100095
China
Email: c.l@huawei.com
Nan Wu
Huawei
Huawei Bld., No.156 Beiqing Rd.
Beijing 100095
China
Email: eric.wu@huawei.com
Li, et al. Expires October 16, 2021 [Page 8]
