Internet DRAFT - draft-peng-idr-bgp-tea-extensions-network-slicing
draft-peng-idr-bgp-tea-extensions-network-slicing
IDR S. Peng
Internet-Draft Y. Liu
Intended status: Standards Track ZTE Corporation
Expires: November 11, 2021 May 10, 2021
BGP Tunnel Encapsulation Attribute Extensions for Network Slicing
draft-peng-idr-bgp-tea-extensions-network-slicing-00
Abstract
This document defines extension to BGP Tunnel Encapsulation attribute
to provide network slicing information needed to create tunnels and
their corresponding encapsulation headers.
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 November 11, 2021.
Copyright Notice
Copyright (c) 2021 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.
Peng & Liu Expires November 11, 2021 [Page 1]
Internet-Draft bgp tea extensions for slicing May 2021
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. Gap Analysis of Tunnel Encapsulation Attribute . . . . . . . 3
3.1. Additional Rules to Filter Traffic . . . . . . . . . . . 3
3.2. Additional Tunnel Information for Network Slice . . . . . 4
4. BGP Flow Specification Considerations . . . . . . . . . . . . 5
5. TEA Extensions . . . . . . . . . . . . . . . . . . . . . . . 5
5.1. Flow Classification Sub-TLV (Type Code TBA1) . . . . . . 5
5.1.1. IP Differentiated Service sub-sub-TLV . . . . . . . . 5
5.1.2. IP Source Address Range sub-sub-TLV . . . . . . . . . 6
5.1.3. IP Destination Address Range sub-sub-TLV . . . . . . 7
5.1.4. IP Protocol Number Range sub-sub-TLV . . . . . . . . 7
5.1.5. Transport Source Port Range sub-sub-TLV . . . . . . . 7
5.1.6. Transport Destination Port Range sub-sub-TLV . . . . 8
5.1.7. Ethernet Frame related sub-sub-TLVs . . . . . . . . . 8
5.2. Virtual Network Sub-TLV (Type Code TBA2) . . . . . . . . 8
5.3. SR-BE Encapsulation Sub-TLV . . . . . . . . . . . . . . . 10
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.1. IP Flex-algo Examples . . . . . . . . . . . . . . . . . . 10
6.2. SR Flex-algo Examples . . . . . . . . . . . . . . . . . . 12
6.3. Specifying Network Slice Identifier Examples . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
7.1. BGP Tunnel Encapsulation Attribute Sub-TLVs . . . . . . . 14
7.2. sub-sub-Types of Flow Classification Sub-TLVs . . . . . . 14
7.3. BGP Tunnel Encapsulation Attribute Tunnel Types . . . . . 15
8. Security Considerations . . . . . . . . . . . . . . . . . . . 15
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
10. Normative References . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction
[I-D.ietf-teas-ietf-network-slices] describes network slicing in the
context of networks built from IETF technologies. In order to
provide network slicing in the operators network for different
scenarios, some existing control plane technologies are utilized, and
also some new technologies are developed. A network slice can be a
virtual network or a traffic engineering path with guaranteed
resources. For example, it could be implemented as an IGP Multi-
Topology (see [RFC5120], [RFC4915], [RFC5340]), or an IGP Flexible
Algorithm (see [I-D.ietf-lsr-flex-algo]), or a Slice Aggregate which
comprises of multiple IETF network slice traffic streams(see
[I-D.bestbar-teas-ns-packet]), or a simple SR policy(see
[I-D.ietf-spring-segment-routing-policy]).
Peng & Liu Expires November 11, 2021 [Page 2]
Internet-Draft bgp tea extensions for slicing May 2021
Once a network slice is created, it is necessary to configure the
corresponding traffic mapping policy on the entry node of the slice
to steer the traffic to the that slice. For example, ACL rules can
be configured on the entry node of the slice to filter the traffic
based on 5-tuple fields or other fields (such as Differentiated
Services) of the packets, then steer the matched traffic to that
slice; It is also possible to firstly set a Color for the matched
traffic, then steer the traffic to an SR policy. However, such
configuration is inflexible, especially for the case where the slice
entry node is not the endpoint of overlay service, in this case it is
not recommended to configure a large number of service-related
policies on the slice entry node. From the point of view of
simplifying operation and maintenance, automatic slice steering is
necessary.
[RFC9012] defines a BGP path attribute known as the "Tunnel
Encapsulation attribute", which can be used with BGP UPDATEs of
various Subsequent Address Family Identifiers (SAFIs) to provide
information needed to create tunnels and their corresponding
encapsulation headers. This document describes extensions to Tunnel
Encapsulation attribute to specify forwarding path within particular
network slice.
2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
3. Gap Analysis of Tunnel Encapsulation Attribute
3.1. Additional Rules to Filter Traffic
[RFC9012] defines two Sub-TLVs, i.e., Protocol Type Sub-TLV (Type
Code 2) and Color Sub-TLV (Type Code 4), for aiding tunnel selection.
For Protocol Type Sub-TLV, the value fileld contains a 2-octet value
from IANA's "ETHER TYPES" registry, such as IPv4(0x0800),
IPv6(0x86dd), MPLS(0x8847), to indicate the type of the payload
packets that are allowed to be encapsulated with the tunnel
parameters that are being signaled in the parent TLV. However, for
network slicing case, it is not enough that the traffic of different
slices is distinguished based on the coarse-grained ethernet types,
more fine-grained differentiation is needed, such as Differentiated
Services field or 5-tuple fields of the IP packet, or Source/
Destination MAC or VLAN ID/PCP of the Ethernet frame.
Peng & Liu Expires November 11, 2021 [Page 3]
Internet-Draft bgp tea extensions for slicing May 2021
For Color Sub-TLV, the value field contains a Color Extended
Community to "color" the corresponding Tunnel TLV. In more detailed,
as section "8. Recursive Next-Hop Resolution" of [RFC9012]
described, an overlay route (U1) with a Color Extended Community that
is identified in one of Color sub-TLVs of the underlay route (U2) can
use tunnel identified in the Tunnel Encapsulation attribute of the
underlay route (U2). That is, an overlay route with specific Color
Extended Community indicates the expected TE purpose during recursive
next-hop resolution, while an underlay route with specific Color sub-
TLV of Tunnel Encapsulation attribute indicates the "color" of the
corresponding Tunnel. In fact, the corresponding Tunnel itself may
not have a color attribute, and the color is temporarily set by the
underlay route. It is possible that different colors may be set by
different underlay routes. Another example that corresponding TE
path itself has a color attribute is SR policy defined in
[I-D.ietf-spring-segment-routing-policy]. For network slicing case,
although a Color Extended Community can be contained in a route
UPDATE to indicate TE purpose within the specific network slice, that
means any packets matched that route will have the same forwarding
behavior. In some cases these packets may need different treatment.
It is possible to advertise multiple Color Extended Community for the
same route, however, ACL rules is necessary at entry nodes of the
slice to firstly set color for packets and then quest TE purpose,
that is inflexible.
3.2. Additional Tunnel Information for Network Slice
[RFC9012] does not define how to specify the tunnel within a network
slice. For example, Tunnel Encapsulation Attribute with IP-in-IP
Tunnel type will only let the packet be encapsulated in IP-tunnel
created in physical network. It is useful to combine the existing
Tunnel Egress Endpoint Sub-TLV or BGP next-hop with a Network Slice
Identifier to select tunnel within expected network slice. Note that
[RFC9012] defines that some of the tunnel types (for example, VXLAN
and NVGRE) that can be specified in the Tunnel Encapsulation
attribute have an encapsulation header containing a virtual network
identifier of some sort, however they are different from the semantic
and function of network slice.
In some network slicing techniques, SID allocation has distinguished
different network slices, so SR-BE (Best Effort) can be specified
directly in Tunnel Encapsulation Attribute. Although, [RFC9012]
defines Prefix-SID sub-TLV, it is the Prefix-SID that the tunnel's
egress endpoint uses to represent the prefix appearing in the NLRI
field of the BGP UPDATE to which the Tunnel Encapsulation attribute
is attached, it is not the Prefix-SID of the outer SR-BE tunnel.
Peng & Liu Expires November 11, 2021 [Page 4]
Internet-Draft bgp tea extensions for slicing May 2021
4. BGP Flow Specification Considerations
[RFC8955] defines Flow Specification NLRI and also specifies BGP
Extended Community encoding formats used to propagate Traffic
Filtering Actions along with the Flow Specification NLRI. The
corresponding flow routes can be installed on the entry nodes of the
network slice, and that is similar with manually configured policy
based routes. However, both of them are inflexible, and some
implementations may not be easy to route packets in combination with
flow routes and unicast routes. Instead, prefix NLRI containing
Tunnel Encapsulation Attribute is different with Flow Specification
NLRI, it does not need to introduce flow route state on the entry
node of the network slice, and all forwarding behaviors are based on
traditional unicast route with its TEA attributes.
5. TEA Extensions
5.1. Flow Classification Sub-TLV (Type Code TBA1)
The Flow Classification Sub-TLV MAY be included in a given Tunnel
Encapsulation TLV to indicate the flow classification of the payload
packets that are allowed to be encapsulated with the tunnel
parameters that are being signaled in the parent TLV. It MUST NOT
appear more than once in its parent TLV. The Value field of the Flow
Classification Sub-TLV comprised of multiple sub-sub-TLVs.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-sub-TLVs (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Flow Classification Sub-TLV Value Field
5.1.1. IP Differentiated Service sub-sub-TLV
IP Differentiated Service sub-sub-TLV is used to represent the range
of Differentiated Service field (such as the TOS field of the IPv4
header or the TC field of the IPv6 header) that traffic needs to
match. It can appear more than once in its parent sub-TLV.
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 | DS Begin | DS End |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: IP Differentiated Service sub-sub-TLV Format
Peng & Liu Expires November 11, 2021 [Page 5]
Internet-Draft bgp tea extensions for slicing May 2021
Type: TBD (suggest 1)
Length: 2 octets.
DS Begin: The begin value of the range of Differentiated Service.
DS End: The end value of the range of Differentiated Service. DS
Begin and DS End field can be same to specify actions for each DS
value.
5.1.2. IP Source Address Range sub-sub-TLV
IP Source Address Range sub-sub-TLV is used to represent the range of
Source Address field that traffic needs to match. It can appear more
than once in its parent sub-TLV.
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 |V| Flags | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Prefix or IPv6 Prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: IP Source Address Range sub-sub-TLV Format
Type: TBD (suggest 2)
Length: variable.
Flags: Currently only V-flag is defined. The IP Prefix field
contains an IPv4 Prefix if V-Flag is clear and an IPv6 Prefix if
V-Flag is set. The remaining bits are reserved for future use. They
MUST be set to zero on transmission and MUST be ignored on receipt.
Prefix Length: Number of bits in the Prefix field. MUST be from the
range (1 - 32) when V-Flag is clear and (1 - 128) when V-Flag is set.
The sub-sub-TLV MUST be ignored if the Prefix Length is outside of
this range.
IP Prefix: The IP Prefix is encoded in the minimal number of octets
for the given number of bits. Trailing bits MUST be set to zero and
ignored when received.
Peng & Liu Expires November 11, 2021 [Page 6]
Internet-Draft bgp tea extensions for slicing May 2021
5.1.3. IP Destination Address Range sub-sub-TLV
IP Destination Address Range sub-sub-TLV is used to represent the
range of Destination Address field that traffic needs to match.
It has the same format as IP Source Address Range sub-sub-TLV,
suggest Type Code 3.
5.1.4. IP Protocol Number Range sub-sub-TLV
IP Protocol Number Range sub-sub-TLV is used to represent the range
of IP Protocol Number field that traffic needs to match. It can
appear more than once in its parent sub-TLV.
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 |Protocol Begin | Protocol End |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: IP Protocol Number Range sub-sub-TLV Format
Type: TBD (suggest 4)
Length: 2 octets.
Protocol Begin: The begin value of the range of IP Protocol Number.
Protocol End: The end value of the range of IP Protocol Number.
Protocol Begin and Protocol End field can be same to specify actions
for each Protocol value.
5.1.5. Transport Source Port Range sub-sub-TLV
Transport Source Port Range sub-sub-TLV is used to represent the
range of Source Port field that traffic needs to match. It can
appear more than once in its parent sub-TLV.
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 | Port Begin | Port End |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Transport Source Port Range sub-sub-TLV Format
Type: TBD (suggest 5)
Peng & Liu Expires November 11, 2021 [Page 7]
Internet-Draft bgp tea extensions for slicing May 2021
Length: 2 octets.
Port Begin: The begin value of the range of Source Port.
Port End: The end value of the range of Source Port. Port Begin and
Port End field can be same to specify actions for each Port value.
5.1.6. Transport Destination Port Range sub-sub-TLV
Transport Destination Port Range sub-sub-TLV is used to represent the
range of Destination Port field that traffic needs to match. It can
appear more than once in its parent sub-TLV.
It has the same format as Transport Source Port Range sub-sub-TLV,
suggest Type Code 6.
5.1.7. Ethernet Frame related sub-sub-TLVs
To be defined in future versions.
5.2. Virtual Network Sub-TLV (Type Code TBA2)
The Virtual Network Sub-TLV MAY be included in a given Tunnel
Encapsulation TLV to indicate the expected network slice that the
traffic is steered to. It MUST NOT appear more than once in its
parent TLV. The Value field of the Virtual Network Sub-TLV has the
following format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Algorithm |R R R R| Multi-Topology ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Slice ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Virtual Network Sub-TLV Value Field
Flags: The following flags are defined:
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|I|A|T|S| |
+-+-+-+-+-+-+-+-+
where:
Peng & Liu Expires November 11, 2021 [Page 8]
Internet-Draft bgp tea extensions for slicing May 2021
I-Flag: This flag is only valid when S-Flag is set. If I-Flag is
set, the entry node of network slice SHOULD insert the value of
Network Slice ID field into the outer encapsulated tunnel header,
otherwise no necessary.
A-Flag: If A-Flag is set, the Algorithm field contains valid value.
T-Flag: If T-Flag is set, the Multi-Topology ID field contains valid
value.
S-Flag: If S-Flag is set, the Network Slice ID field contains valid
value.
The remaining bits are reserved for future use. They MUST be set to
zero on transmission and MUST be ignored on receipt.
Algorithm: Represents IGP algorithm, see IANA "IGP Algorithm Types"
registry, such as 0 (Shortest Path First algorithm based on link
metric), 1 (Strict Shortest Path First algorithm based on link
metric) defined in [RFC8402], and 128~255 (Flexible Algorithm)
defined in [I-D.ietf-lsr-flex-algo].
Multi-Topology ID: Represents IGP Multi-Topology defined in [RFC5120]
and [RFC4915].
Network Slice ID: Represents an IETF network Slice defined in
[I-D.ietf-teas-ietf-network-slices].
In most cases, it only need to set one of Algorithm, Multi-Topology
ID and Network Slice ID. However, it is possible to set them at the
same time. When not set, the value is 0.
Virtual Network Sub-TLV is used together with other Sub-TLVs to
encapsulate the tunnel information corresponding to the specified
tunnel in a specific virtual network. For example, when the Tunnel
Type of Tunnel Encapsulation TLV is 7 (representing IP-in-IP), and
contains Virtual Network Sub-TLV and Tunnel Egress Endpoint Sub-TLV,
it means that the packets is encapsulated in the IP tunnel in the
expected virtual network destinated to the Tunnel Egress Endpoint.
In detailed, the path of IP tunnel could be determined by <Algorithm,
Endpoint>, or <MT-ID, Endpoint>, or <Slice-ID, Endpoint>.
In some network slice control plane schemes, Slice-ID is directly
used to identify FIB table, so it is easy to get FIB entry by <Slice-
ID, Endpoint>. In other shcemes, Slice-ID need firstly be mapped to
an SA-ID, then get FIB entry by <SA-ID, Endpoint>. It is the local
matter for the entry node of the network slice to get FIB entry
according to the specific deployment mode. In any case, the entry
Peng & Liu Expires November 11, 2021 [Page 9]
Internet-Draft bgp tea extensions for slicing May 2021
node of the network slice can, but may not if it has not such
capability, insert Slice-ID to the outer tunnel header.
5.3. SR-BE Encapsulation Sub-TLV
This document introduce a new Tunnel Type, termed as SR-BE. For SR-
BE tunnel, the structure of the Value field in the Encapsulation sub-
TLV (Type Code 1) is shown as the following:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |D| Flags | SID... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: SR-BE Encapsulation Sub-TLV Value Field
Reserved: MUST be set to zero on transmission and disregarded on
receipt.
Flags: Currently only D-flag is defined. The SID field contains a 32
bits SR-MPLS SID (index) if D-Flag is clear and a 128 bits SRv6 SID
if D-Flag is set. The remaining bits are reserved for future use.
They MUST be set to zero on transmission and MUST be ignored on
receipt.
SID: 32 bits SR-MPLS SID (index) or 128 bits SRv6 SID.
For SR-MPLS SID (index), the out-label needs to be obtained based on
the SRGB of the downstream node and then pushed to the label stack.
For SRv6 SID, the SID is filled in the DA field of outer IPv6 header.
6. Examples
6.1. IP Flex-algo Examples
The following example describes a most simple network slice
deployment selection, which steers traffic to the corresponding
tunnel endpoint according to the traffic class. In the backbone
network of some operators, network administrators do not want to
deploy a large number of traffic engineering paths in the network,
but they also want to automatically select the appropriate path for
forwarding according to the traffic characteristics. The network
administrator chooses to deploy IGP flex-algo in the backbone network
of pure IPv6 (refering to [I-D.ietf-lsr-ip-flexalgo]), and creates an
flex-algo plane based on the calculation path of Delay-metric. It is
Peng & Liu Expires November 11, 2021 [Page 10]
Internet-Draft bgp tea extensions for slicing May 2021
expected that the traffic with higher traffic class will be forwarded
along the flex-algo plane, while the ordinary traffic will continue
to be forwarded along the physical network.
~~~~~~~~~~~~~~~~~~~~~~~~~
~ ....................~
~ . FA-128 . ~
~~~~~~~~~~~ ~ . +-----P1----+ . ~ ~~~~~~~~~~~
~ ~ ~. / | \ . ~ ~ ~
~ S-----A---------B1-----P2-----B2------------C-----D ~
~ ~ ~ \ | / ~ ~ ~
~~~~~~~~~~~ ~ +-----p3----+ ~ ~~~~~~~~~~~
~ ~
~~~~~~~~~~~~~~~~~~~~~~~~~
Metro-1 Backbone Metro-2
Figure 8: Flex-algo in Backbone
Nodes B1, P1, P2, B2 and their interconnected links join to the flex-
algo 128 plane. Suppose that there are two loopback routes on node
B2, respectively loopback-B2 and loopback-B200, and loopback-B2 is
associated with algorithm 0, loopback-B200 is associated with
algorithm 128. On node B1, the route forwarding path to loopback-B2
will be the forwarding path calculated by the minimum IGP metric in
the physical network, and the route forwarding path to loopback-B200
will be the forwarding path calculated by the minimum delay metric in
flex-algo 128 plane.
Node S of Metro-1 needs to send IPv6 packets to node D of Metro-2.
Suppose that node D has a local route prefix-D, which is flooded in
Metro-2. Node C can advertise prefix-D to node B2 through BGP. When
the B2 receives prefix-D from outside the backbone domain, it
continues to advertise the routes to the boundary node B1 through
BGP. At this time, B2 does not pay attention to the difference of
the announced prefixes (i.e. whether it is for prefix-D or other
prefix-D'). It just configure a simple local policy to add the
Tunnel Encapsulation Attribute to the BGP UPDATE that continues to be
advertised, which includes two Tunnel Cncapsulation TLVs:
The first Tunnel Encapsulation TLV:
Tunnel Type: IP in IP
Tunnel Egress Endpoint Sub-TLV: Loopback-B2
Flow Classification Sub-TLV: IP Differentiated Service is [0,3]
The second Tunnel Encapsulation TLV:
Peng & Liu Expires November 11, 2021 [Page 11]
Internet-Draft bgp tea extensions for slicing May 2021
Tunnel Type: IP in IP
Tunnel Egress Endpoint Sub-TLV: Loopback-B200
Flow Classification Sub-TLV: IP Differentiated Service is [4,7]
Node B1 will maintain to the prefix-D route entry, which contains the
above two Tunnel Encapsulation Attribute options.
Assuming the two data packets, P1 and P2, sent from node S to node D.
Suppose that the traffic class in IPv6 header of P1 is 0 and that in
IPv6 header of P2 is 7.
When the above packets reache the node B1 of the backbone network, it
will match the route entry prefix-D and encapsulate the outer IPv6
tunnel for the packets according to the Tunnel Encapsulation
Attribute options. Since the traffic class of P1 is 0, the DA of the
encapsulated outer IPv6 header is loopback-B2; while the traffic
class of P2 is 7, the DA of the encapsulated outer IPv6 header is
loopback-B200.
The above two packets will be forwarded to the destination node B2
along the physical topology and flex-algo 128 plane respectively.
6.2. SR Flex-algo Examples
The network administrator can also deploy IGP flex-algo in the
backbone network of SRv6 (refering to [I-D.ietf-lsr-flex-algo]).
In Figure 8, suppose that there are two SRv6 Locators on node B2,
respectively LOC-B2 and LOC-B200, and LOC-B2 is associated with
algorithm 0, LOC-B200 is associated with algorithm 128. On node B1,
the route forwarding path to LOC-B2 will be the forwarding path
calculated by the minimum IGP metric in the physical network, and the
route forwarding path to LOC-B200 will be the forwarding path
calculated by the minimum delay metric in flex-algo 128 plane.
Suppose SID-b2 is allocated in LOC-B2 and SID-B200 is allocated in
LOC-B200. These two SIDS may be END SID with USD flavor or END.DT6
SID used to carry global IPv6 packets.
Similar with the above example, B2 sends to B1 about BGP UPDATE with
Tunnel Encapsulation Attribute, which includes two Tunnel
Cncapsulation TLVs:
The first Tunnel Encapsulation TLV:
Tunnel Type: SR-BE
Peng & Liu Expires November 11, 2021 [Page 12]
Internet-Draft bgp tea extensions for slicing May 2021
SR-BE Encapsulation Sub-TLV: D-Flag is set, SID is SID-B2
Flow Classification Sub-TLV: IP Differentiated Service is [0,3]
The second Tunnel Encapsulation TLV:
Tunnel Type: SR-BE
SR-BE Encapsulation Sub-TLV: D-Flag is set, SID is SID-B200
Flow Classification Sub-TLV: IP Differentiated Service is [4,7]
For the above packet P1, the DA of the encapsulated outer IPv6 header
is SID-B2; For the above packet P2, the DA of the encapsulated outer
IPv6 header is SID-B200. Thus they will be forwarded to the
destination node B2 along the physical topology and flex-algo 128
plane respectively.
6.3. Specifying Network Slice Identifier Examples
This example describes steering to a specific network slice according
to the traffic level, which requires the entry node to combine the
specific Network Slice Identifier with the BGP next-hop of BGP UPDATE
or the Tunnel Egress Endpoint Sub-TLV to determine the tunnel
encapsulation to be adopted. In this way, the tunnel selection of
the entry node is more flexible, and the constructure of BGP UPDATE
is more concise.
Similar with the above example, B2 sends to B1 about BGP UPDATE with
Tunnel Encapsulation Attribute, which includes two Tunnel
Cncapsulation TLVs:
The first Tunnel Encapsulation TLV:
Tunnel Type: Any-Encapsulation
Virtual Network Sub-TLV: Algorithm 0, MT-ID 0, Slice-ID 0
Flow Classification Sub-TLV: IP Differentiated Service is [0,3]
The second Tunnel Encapsulation TLV:
Tunnel Type: Any-Encapsulation
Virtual Network Sub-TLV: Algorithm 128, MT-ID 0, Slice-ID 0
Flow Classification Sub-TLV: IP Differentiated Service is [4,7]
Peng & Liu Expires November 11, 2021 [Page 13]
Internet-Draft bgp tea extensions for slicing May 2021
Node B1 will maintain to the prefix-D route entry, which contains the
tunnel encapsulation attribute information and specifically contains
the above two Tunnel Encapsulation options. Because the Tunnel Type
is Any-Encapsulation, B1 node needs to select the corresponding
tunnel according to the actual deployment modes in the backbone
network. For example, if the backbone network is an SR-MPLS network,
it needs to find the prefix-SID allocated by the node B2 for the
corresponding algorithm in the link-state database, and then obtain
the corresponding MPLS SR-BE tunnel; If the backbone network is SRv6
network, it needs to find the END SID assigned by the node B2 for the
corresponding algorithm in the link state database, and then obtain
the corresponding IPv6 SR-BE tunnel.
7. IANA Considerations
7.1. BGP Tunnel Encapsulation Attribute Sub-TLVs
This document request the following entries to the "BGP Tunnel
Encapsulation Attribute Sub-TLVs" registry:
+=======+=========================+================+
| Value | Description | Reference |
+=======+=========================+================+
| TBA1 | Flow Classification | This Document |
+-------+-------------------------+----------------+
| TBA2 | Virtual Network | This Document |
+-------+-------------------------+----------------+
7.2. sub-sub-Types of Flow Classification Sub-TLVs
This document request new registry named as "sub-sub-Types of Flow
Classification Sub-TLVs" under the "Border Gateway Protocol (BGP)
Tunnel Encapsulation" grouping.
The initial types for this new registry are indicated as the
following:
Peng & Liu Expires November 11, 2021 [Page 14]
Internet-Draft bgp tea extensions for slicing May 2021
+=======+==================================+================+
| Value | Description | Reference |
+=======+==================================+================+
| 1 | IP Differentiated Service | This Document |
+-------+----------------------------------+----------------+
| 2 | IP Source Address Range | This Document |
+-------+----------------------------------+----------------+
| 3 | IP Destination Address Range | This Document |
+-------+----------------------------------+----------------+
| 4 | IP Protocol Number Range | This Document |
+-------+----------------------------------+----------------+
| 5 | Transport Source Port Range | This Document |
+-------+----------------------------------+----------------+
| 6 | Transport Destination Port Range | This Document |
+-------+----------------------------------+----------------+
7.3. BGP Tunnel Encapsulation Attribute Tunnel Types
This document request the following entries to the "BGP Tunnel
Encapsulation Attribute Tunnel Types" registry:
+=======+=========================+================+
| Value | Description | Reference |
+=======+=========================+================+
| TBA3 | SR-BE | This Document |
+-------+-------------------------+----------------+
8. Security Considerations
This document inherits the security consideration from [RFC9012].
9. Acknowledgements
TBD
10. Normative References
[I-D.bestbar-teas-ns-packet]
Saad, T., Beeram, V. P., Wen, B., Ceccarelli, D., Halpern,
J., Peng, S., Chen, R., Liu, X., and L. M. Contreras,
"Realizing Network Slices in IP/MPLS Networks", draft-
bestbar-teas-ns-packet-02 (work in progress), February
2021.
[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-15 (work in progress), April 2021.
Peng & Liu Expires November 11, 2021 [Page 15]
Internet-Draft bgp tea extensions for slicing May 2021
[I-D.ietf-lsr-ip-flexalgo]
Britto, W., Hegde, S., Kaneriya, P., Shetty, R., Bonica,
R., and P. Psenak, "IGP Flexible Algorithms (Flex-
Algorithm) In IP Networks", draft-ietf-lsr-ip-flexalgo-02
(work in progress), April 2021.
[I-D.ietf-spring-segment-routing-policy]
Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and
P. Mattes, "Segment Routing Policy Architecture", draft-
ietf-spring-segment-routing-policy-11 (work in progress),
April 2021.
[I-D.ietf-teas-ietf-network-slices]
Farrel, A., Gray, E., Drake, J., Rokui, R., Homma, S.,
Makhijani, K., Contreras, L. M., and J. Tantsura,
"Framework for IETF Network Slices", draft-ietf-teas-ietf-
network-slices-00 (work in progress), April 2021.
[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>.
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008,
<https://www.rfc-editor.org/info/rfc5340>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[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>.
Peng & Liu Expires November 11, 2021 [Page 16]
Internet-Draft bgp tea extensions for slicing May 2021
[RFC8955] Loibl, C., Hares, S., Raszuk, R., McPherson, D., and M.
Bacher, "Dissemination of Flow Specification Rules",
RFC 8955, DOI 10.17487/RFC8955, December 2020,
<https://www.rfc-editor.org/info/rfc8955>.
[RFC9012] Patel, K., Van de Velde, G., Sangli, S., and J. Scudder,
"The BGP Tunnel Encapsulation Attribute", RFC 9012,
DOI 10.17487/RFC9012, April 2021,
<https://www.rfc-editor.org/info/rfc9012>.
Authors' Addresses
Shaofu Peng
ZTE Corporation
Email: peng.shaofu@zte.com.cn
Yao Liu
ZTE Corporation
Email: liu.yao71@zte.com.cn
Peng & Liu Expires November 11, 2021 [Page 17]
