BGP-LS Filters : A Framework for Network Slicing and Enhanced VPNs
draft-drake-bess-enhanced-vpn-03
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 "Replaced".
|
|
|---|---|---|---|
| Authors | John Drake , Adrian Farrel , Luay Jalil , Avinash Reddy Lingala | ||
| Last updated | 2020-05-21 | ||
| Replaced by | draft-drake-teas-bgp-ls-filter-nrp | ||
| RFC stream | (None) | ||
| Formats | |||
| 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-drake-bess-enhanced-vpn-03
BESS Working Group J. Drake
Internet-Draft Juniper Networks
Intended status: Standards Track A. Farrel
Expires: November 22, 2020 Old Dog Consulting
L. Jalil
Verizon
A. Lingala
AT&T
May 21, 2020
BGP-LS Filters : A Framework for Network Slicing and Enhanced VPNs
draft-drake-bess-enhanced-vpn-03
Abstract
Future networks that support advanced services, such as those enabled
by 5G mobile networks, envision a set of overlay networks each with
different performance and scaling properties. These overlays are
known as network slices and are realized over a common underlay
network.
In order to support network slicing, as well as to offer enhanced VPN
services in general, it is necessary to define a mechanism by which
specific resources (links and/or nodes) of an underlay network can be
used by a specific network slice, VPN, or set of VPNs. This document
sets out such a mechanism for use in Segment Routing networks.
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 22, 2020.
Drake, et al. Expires November 22, 2020 [Page 1]
Internet-Draft MPLS SFC May 2020
Copyright Notice
Copyright (c) 2020 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 . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. Overview of Approach . . . . . . . . . . . . . . . . . . . . 3
4. Detailed Protocol Operation . . . . . . . . . . . . . . . . . 5
4.1. The BGP-LS Filter Attribute . . . . . . . . . . . . . . . 7
4.1.1. The Filter TLV . . . . . . . . . . . . . . . . . . . 8
4.1.2. The DSCP List TLV . . . . . . . . . . . . . . . . . . 9
4.1.3. The Color List TLV . . . . . . . . . . . . . . . . . 10
4.1.4. The Root TLV . . . . . . . . . . . . . . . . . . . . 11
4.2. Error Handling . . . . . . . . . . . . . . . . . . . . . 11
5. Comparison With ACTN . . . . . . . . . . . . . . . . . . . . 12
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.1. MP2MP Connectivity . . . . . . . . . . . . . . . . . . . 13
6.2. P2MP Unidirectional Connectivity . . . . . . . . . . . . 14
6.3. P2P Unidirectional Connectivity . . . . . . . . . . . . . 15
6.4. P2P Bidirectional Connectivity . . . . . . . . . . . . . 16
7. Security Considerations . . . . . . . . . . . . . . . . . . . 17
8. Manageability Considerations . . . . . . . . . . . . . . . . 17
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
9.1. New BGP Path Attribute . . . . . . . . . . . . . . . . . 17
9.2. New BGP-LS Filter attribute TLVs Type Registry . . . . . 18
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
11.1. Normative References . . . . . . . . . . . . . . . . . . 18
11.2. Informative References . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
Drake, et al. Expires November 22, 2020 [Page 2]
Internet-Draft MPLS SFC May 2020
1. Introduction
Network slicing is an approach to network operations that builds on
the concept of network abstraction to provide programmability,
flexibility, and modularity. Driven largely by needs surfacing from
5G, the concept of network slicing has gained traction, for example
in [TS23501] and [TS28530]. Network slicing requires the underlying
network to support partitioning the network resources to provide the
client with dedicated (private) networking, computing, and storage
resources drawn from a shared pool. The slices may be seen as (and
operated as) virtual networks.
Advanced services drive a need to create virtual networks with
enhanced characteristics. The tenant of such a virtual network can
require a degree of isolation and performance that previously could
only be satisfied by dedicated networks. Additionally, the tenant
may ask for some level of control to their virtual networks, e.g., to
customize the service forwarding paths in the underlying network.
The concepts of "enhanced VPNs" and "network slicing" are introduced
in [I-D.ietf-teas-enhanced-vpn].
In order to support network slicing, as well as to offer enhanced VPN
services in general, it is necessary to define a mechanism by which
specific resources (links and/or nodes) of an underlay network can be
used by a specific network slice, VPN, or set of VPNs. This document
sets out such a mechanism for use in Segment Routing networks
[RFC8402] and builds on the ideas introduced in
[I-D.ietf-idr-segment-routing-te-policy]. I.e., it generalizes that
work to support multipoint-to-multipoint (MP2MP), point-to-multipoint
(P2MP), and bidirectional point-to-point (P2P) topologies; it
integrates BGP-based VPN support ([RFC4364], [RFC7432]); it supports
DSCP as well a Color-based forwarding, and it uses BGP Link-State
(BGP-LS) [RFC7752] to distribute topology information.
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. Overview of Approach
The approach is based on a network controller that uses the {source,
destination} traffic matrix and the performance and scaling
properties of each network slice, VPN, or set of VPNs in conjunction
Drake, et al. Expires November 22, 2020 [Page 3]
Internet-Draft MPLS SFC May 2020
with the topology of the underlay network to assign each network
slice, VPN, or set of VPNs a set of underlay links and nodes that it
can use. That is, each network slice, VPN, or set of VPNs gets a
subset, either dedicated or shared, of the resources in the underlay
network.
It should be noted that resources can be assigned at any of the
following granularities:
o All PEs in a given VPN
o A set of PEs in a given VPN
o An individual PE in a given VPN.
Once the network controller has determined the resource assignments,
it distributes this information to the PEs that participate in each
VPN using the usual VPN information dissemination tools, e.g., route
targets (RT) [RFC4360], route reflectors (RR) [RFC4456], and RT
constraints [RFC4684].
This information is distributed to the PEs by giving them a
customized and limited view of the underlay network on the basis of a
network slice, a VPN, or a set of VPNs. Each PE will have a complete
view of the underlay network and this customized and limited view
acts as filter on the underlay network telling the PE which underlay
network resources it can use to direct the traffic of a given network
slice, VPN, or set of VPNs to best deliver end-to-end services.
The resource allocation information is encoded using BGP-LS. This
approach is chosen for the following reasons:
o It is BGP-based so it integrates easily with the existing BGP-
based VPN infrastructure ([RFC4364], [RFC4684])
o It supports Segment Routing which is necessary to enforce the PEs'
usage of the resources allocated to the VPN or set of VPNs
o It supports Segment Routing which is necessary to enforce the PEs'
usage of the resources allocated to the network slice, VPN, or set
of VPNs. The use of RSVP-TE ([RFC3209]) rather than Segment
Routing is at the discretion of the network operator as BGP-LS
supports both and either confines a packet flow to a specific
path.
o It supports inter-AS connectivity which is a perquisite for
supporting the existing BGP-based VPN infrastructure
Drake, et al. Expires November 22, 2020 [Page 4]
Internet-Draft MPLS SFC May 2020
o It is canonical, in that it can be used to advertise the resources
of underlay networks that use either IS-IS or OSPF
It should be noted that this mechanism also follows the scalability
model of the existing BGP-based VPN infrastructure, which is that the
per-VPN information is restricted to only those PE routers that are
supporting that VPN and that the P routers have no per-VPN state.
The PEs in non-enhanced VPNs do not receive this resource allocation
information and would not confine their usage of the underlay network
resources. In order to ensure that the underlay network resources
allocated to enhanced VPNs are not inadvertently used by the PEs in
non-enhanced VPNs, the network controller SHOULD ensure that the IGP
and TE metrics for these resources is higher than the metrics for the
underlay network resources allocated to non-enhanced VPNs. In
certain situations, detailed in Section 4, PEs in enhanced VPNs will
use the underlay networks resources allocated to non-enhanced VPNs.
Additional to the programming of the PEs and its computation and
assignment of resources for use by network slices, VPNs, or sets of
VPNs, the network controller also instructs the P routers to make the
actual allocation of these resources by assigning link bandwidth to a
specific DSCP or adjacency SID.
4. Detailed Protocol Operation
We define a BGP-LS Filter to be a BGP-LS encoded description of a
subset of the links and nodes in the underlay network. A BGP-LS
Filter defines the topology for a network slice or a set of one or
more VPNs. The topology defined by a BGP-LS Filter needs to provide
connectivity between the PEs in a given network slice, VPN or set of
VPNs. I.e., it connects the PEs in these VPNs and is used by them to
send packets to each other. A given filter is tagged with the route
targets of the VPNs whose PEs are to import the filter. A BGP-LS
Filter is pushed southbound to those PEs by the network controller
and SHOULD provide multiple paths between a given ingress/egress PE
pair.
Note that there will be multiple BGP-LS Filters in a given network
deployment and that a given underlay network link or node may appear
in more than one of them. In order to provide disambiguation AFI
16388 (BGP-LS) and SAFI 72 (BGP-LS-VPN) are used in BGP-LS UPDATE
messages and the network controller SHOULD allocate a different route
distinguisher (RD) to each BGP-LS Filter.
Within a given VPN, when an ingress PE needs to send a packet to an
egress PE it selects a path to that egress PE from the topology
defined by the BGP-LS Filters it has imported for that VPN. It then
Drake, et al. Expires November 22, 2020 [Page 5]
Internet-Draft MPLS SFC May 2020
either adds a segment routing label stack specifying that path to the
packet or places the packet in an RSVP-TE LSP which uses that path.
The ingress PE may use any path computation it wishes if that path
computation confines the path to the topology defined by the relevant
set of BGP-LS Filters.
If Segment Routing is used and a nodal SID is placed in the segment
routing label stack, then when that segment is active the P routers
will forward the packet using the underlay network resources
allocated to non-enhanced VPNs. Similarly, if the RSVP-TE LSP was
established using a loose source route to the subject node, the path
to that node was selected using the underlay network resources
allocated to non-enhanced VPNs.
Because the BGP-LS UPDATE messages specifying a BGP-LS Filter may
arrive in any order and the BGP-LS UPDATE messages of multiple BGP-LS
Filters may be interleaved, there is a need for a new attribute that
is attached to a BGP-LS UPDATE. This attribute contains a Filter ID,
a Filter version number, a Filter type (MP2MP, P2MP, or P2P), the
total number of fragments in the filter, and the specific fragment
number of the piece in hand. I.e., it is assumed that a PE may
import more than one BGP-LS Filter, that a given BGP-LS Filter may
change over time, and that a given BGP-LS Filter may span multiple
BGP-LS UPDATE messages. The Filter ID needs to be unique across the
set of VPNs into which the BGP-LS Filter is to be imported.
A BGP-LS Filter that is created for a set of VPNs will contain a set
of network resources sufficient to connect the PEs in each VPN in the
set and each of the BGP-LS UPDATE messages for the filter MUST be
tagged with the RT for each VPN in the set.
If a PE imports more than one BGP-LS Filter it may use the union of
the links and nodes specified in each filter when selecting a path.
A PE should give precedence to BGP-LS Filters of type P2MP and P2P
when selecting a path. Routes targets specific to a given VPN/PE
pair are needed for BGP-LS Filters of type P2MP and P2P.
A given BGP-LS Filter may change in response to updates to the PE
membership in a VPN to which the BGP-LS Filter applies or to updates
to the underlay network. This implies that the network controller
needs to be connected to the route reflectors associated with the
VPNs for which it is providing BGP-LS maps. When this occurs, the
network controller should push a new version of the affected BGP-LS
Filters. That is, it increments the version number of each BGP-LS
Filter. Note that a network controller does not need to compute new
BGP-LS Filters in response to an individual link or node failure in
the underlay network if connectivity still exists among the PEs in
Drake, et al. Expires November 22, 2020 [Page 6]
Internet-Draft MPLS SFC May 2020
the network slice, VPN or set or VPNs with the existing BGP-LS
Filters.
A BGP-LS Filter cannot be used by a PE until it is completely
assembled. If the BGP-LS Filter that is being assembled is a newer
version of a BGP-LS Filter that the PE is currently using, the PE
should continue to use its current version of the BGP-LS Filter until
the newer version is completely assembled.
When selecting a path using one or more BGP-LS Filters, an ingress PE
can use a link or node only if it is active in the underlay network.
If this precludes connectivity to the egress PE it may use the
underlay network resources allocated to non-enhanced VPNs to reach
the egress PE.
Additionally, when there is a newly activated PE it will not be
present in any of the BGP-LS Filters used by the other PEs. Until a
new BGP-LS Filter or Filters that contain that PE has been
distributed, other PEs will use the underlay network resources
allocated to non-enhanced VPNs to reach the newly activated PE and it
use these resources to reach other PEs.
4.1. The BGP-LS Filter Attribute
[RFC4271] defines the BGP Path attribute. This document introduces a
new Optional Transitive Path attribute called the BGP-LS Filter
attribute with value TBD1 to be assigned by IANA.
The first BGP-LS Filter attribute MUST be processed and subsequent
instances MUST be ignored.
The common fields of the BGP-LS Filter attribute are set as follows:
o Optional bit is set to 1 to indicate that this is an optional
attribute.
o The Transitive bit is set to 1 to indicate that this is a
transitive attribute.
o The Extended Length bit is set according to the length of the BGP-
LS Filter attribute as defined in [RFC4271].
o The Attribute Type Code is set to TBD1.
The content of the BGP-LS Filter attribute is a series of Type-
Length-Value (TLV) constructs. Each TLV may include sub-TLVs. All
TLVs and sub-TLVs have a common format that is:
Drake, et al. Expires November 22, 2020 [Page 7]
Internet-Draft MPLS SFC May 2020
o Type: A single octet indicating the type of the BGP-LS Filter
attribute TLV. Values are taken from the registry described in
Section 9.2.
o Length: A two octet field indicating the length of the data
following the Length field counted in octets.
o Value: The contents of the TLV.
The formats of the TLVs defined in this document are shown in the
following sections. The presence rules and meanings are as follows.
o The BGP-LS Filter attribute MUST contain a Filter TLV.
o The BGP-LS Filter attribute MAY contain a DSCP List TLV.
o The BGP-LS Filter attribute MAY contain a Color List TLV.
o The BGP-LS Filter attribute MAY contain a Root TLV.
4.1.1. The Filter TLV
The BGP-LS Filter attribute MUST contain exactly one Filter TLV. Its
format is shown in Figure 1. Note that a given BGP-LS Filter may
span multiple UPDATE messages and the Topology, Version Number, and
the Number of Fragments fields in the BGP-LS Filter attribute
contained in each UPDATE message MUST be set to the same value or the
BGP-LS Filter is unusable.
+--------------------------------------------+
| Type = 1 (1 octet) |
+--------------------------------------------+
| Length (2 octets) |
+--------------------------------------------+
| Topology (1 Octet) |
+--------------------------------------------+
| ID (4 Octets) |
+--------------------------------------------+
| Version Number (4 Octets) |
+--------------------------------------------+
| Number of Fragments (4 Octets) |
+--------------------------------------------+
| Fragment Number (4 Octets) |
+--------------------------------------------+
Figure 1: The Filter TLV Format
Drake, et al. Expires November 22, 2020 [Page 8]
Internet-Draft MPLS SFC May 2020
The fields are as follows:
o Type is set to 1 to indicate a Filter TLV.
o Length is set to 17 octets.
o Topology indicates whether this BGP-LS Filter is MP2MP, P2MP, P2P
unidirectional, or P2P bidirectional.
o The ID of this BGP-LS Filter. This ID needs to be unique within
the set of VPNs into which the BGP-LS Filter is to be imported.
o The Version Number of this BGP-LS Filter. I.e., the contents of a
BGP-LS Filter with a given ID may change over time and this field
indicates the latest version of that BGP-LS Filter.
o Number of Fragments indicates the number of BGP UPDATE messages
defining this BGP-LS Filter.
o Fragment Number indicates ordinal position of this UPDATE message
within the set of UPDATE messages defining this BGP-LS Filter. A
BGP-LS Filter is not complete, i.e., usable, until all UPDATE
messages have been received with Fragment Numbers in the range 1
<= Fragment Number <= Number of Fragments. An UPDATE message with
a Fragment Number outside this range is to be ignored.
4.1.2. The DSCP List TLV
The DSCP List TLV MAY be included in the BGP-LS Filter attribute. If
included, a packet whose DSCP matches a DSCP in the DSCP list is to
be forwarded using the BGP-LS Filter defined by the containing BGP-LS
Filter attribute. The first DSCP List TLV MUST be processed and
subsequent instances MUST be ignored. The format of the DSCP List
TLV is shown in Figure 2.
+--------------------------------------------+
| Type = 2 (1 octet) |
+--------------------------------------------+
| Length (2 octets) |
+--------------------------------------------+
| DSCP List (variable) |
+--------------------------------------------+
Figure 2: The DSCP List TLV Format
The fields are as follows:
Drake, et al. Expires November 22, 2020 [Page 9]
Internet-Draft MPLS SFC May 2020
o Type is set to 2 to indicate a DSCP List TLV.
o Length indicates the length in octets of the DSCP List.
o DSCP List contains a list of DSCPs, each one octet in length and
encoded in the standard format.
4.1.3. The Color List TLV
The Color List TLV MAY be included in the BGP-LS Filter attribute.
If a BGP UPDATE contains a Color extended community with a color (as
defined by [RFC5512]) that matches an entry in the Color List, then a
packet whose destination is covered by one of the routes in that
UPDATE is to be forwarded using the BGP-LS Filter defined by the
containing BGP-LS Filter attribute. The first Color List TLV MUST be
processed and subsequent instances MUST be ignored. The format of
the Color List TLV is shown in Figure 3.
Note that if both a DSCP List and a Color List TLV are included in a
BGP-LS Filter attribute, packets matching an entry in either list are
to be forwarded using the BGP-LS Filter defined by the containing
BGP-LS Filter attribute. If neither list is included then all
packets for that network slice, VPN, or set of VPNs can be forwarded
using the BGP-LS Filter defined by the containing BGP-LS Filter
attribute.
+--------------------------------------------+
| Type = 3 (1 octet) |
+--------------------------------------------+
| Length (2 octets) |
+--------------------------------------------+
| Color List (variable) |
+--------------------------------------------+
Figure 3: The Color List TLV Format
The fields are as follows:
o Type is set to 3 to indicate a Color List TLV.
o Length indicates the length in octets of the Color List.
o Color List contains a list of Colors, each four octets in length.
Drake, et al. Expires November 22, 2020 [Page 10]
Internet-Draft MPLS SFC May 2020
4.1.4. The Root TLV
The Root TLV MUST be included in the BGP-LS Filter attribute if its
topology is of type P2MP or P2P unidirectional. It defines the root
node for that topology and if it is not present the BGP-LS Filter is
unusable. The TLV, if present, MUST be ignored if the topology is of
type MP2MP or P2P bidirectional.
The Root TLV is structured as shown in Figure 4 and MAY contain any
of the sub-TLVs defined in section 3.2.1.4 of [RFC7752].
+--------------------------------------------+
| Type = 3 (1 octet) |
+--------------------------------------------+
| Length (2 octets) |
+--------------------------------------------+
| Sub-TLVs (variable) |
+--------------------------------------------+
Figure 4: The Root TLV Format
The fields are as follows:
o Type is set to 3 to indicate a Color List TLV.
o Length indicates the length in octets of the Color List.
o There follows a sequence of zero or more sub-TLVs as defined in
section 3.2.1.4 of [RFC7752]. The presence of sub-TLVs can be
deduced from the Length field of the Root TLV and from the Length
fields of each of the sub-TLVs.
4.2. Error Handling
Section 6 of [RFC4271] describes the handling of malformed BGP
attributes, or those that are in error in some way. [RFC7606]
revises BGP error handling specifically for the for UPDATE message,
provides guidelines for the authors of documents defining new
attributes, and revises the error handling procedures for a number of
existing attributes. This document introduces the BGP-LS Filter
attribute and so defines error handling as follows:
o When parsing a message, an unknown Attribute Type code or a length
that suggests that the attribute is longer than the remaining
message is treated as a malformed message and the "treat-as-
withdraw" approach used as per [RFC7606].
Drake, et al. Expires November 22, 2020 [Page 11]
Internet-Draft MPLS SFC May 2020
o When parsing a message that contains an BGP-LS Filter attribute,
the following cases constitute errors:
1. Optional bit is set to 0 in BGP-LS Filter attribute.
2. Transitive bit is set to 0 in BGP-LS Filter attribute.
3. The attribute does not contain a Filter TLV or it contains
more than one Filter TLV.
4. The TLV length indicates that the TLV extends beyond the end
of the BGP-LS Filter attribute.
5. There is an unknown TLV type field found in BGP-LS Filter
attribute.
o The errors listed above are treated as follows:
1., 2., 3., 4.: The attribute MUST be treated as malformed and
the "treat-as-withdraw" approach used as per [RFC7606].
5.: Unknown TLVs SHOULD be ignored, and message processing SHOULD
continue.
5. Comparison With ACTN
TBD
6. Examples
Figure 5shows a sample underlay topology. Six PEs (PE1 through PE6)
are connected across a network of twelve P nodes (P1 through P12).
Each PE is dual-homed, and the P nodes are variously connected so
that there are multiple routes between PEs.
Drake, et al. Expires November 22, 2020 [Page 12]
Internet-Draft MPLS SFC May 2020
PE3 PE4
|\ /|
| \ / |
| \ / |
| \/ |
| /\ |
| / \ |
| / \ |
|/ \|
P1--------P2
/ |\ /| \
/ | \ / | \
/ | \ / | \
/ | \/ | \
P3-------P4--------P5-------P6
| / | /\ | \ |
| / | / \ | \ |
| / | / \ | \ |
|/ |/ \| \|
P7---P8--P9--------P10-P11-P12
|\ /| |\ /|
| \/ | | \/ |
| /\ | | /\ |
|/ \| |/ \|
PE1 PE2 PE5 PE6
Figure 5: Underlay Network Topology
6.1. MP2MP Connectivity
Figure 6 shows how a Multi-point-to-multipoint (MP2MP) service that
connects PE1, PE3, and PE6 can be installed over the underlay
network. Path have been computed so that, for example, PE1 is
connected to both PE3 and PE6 via a pair of redundant paths.
Similarly, PE3 is connected to PE1 and PE6, and PE6 is connected to
PE1 and PE3.
Drake, et al. Expires November 22, 2020 [Page 13]
Internet-Draft MPLS SFC May 2020
PE3 PE4
| \
| \
| \
| \
| \
| \
| \
| \
P1 P2
/ \ /|
/ \ / |
/ \ / |
/ \ / |
P3 P4 X P5 P6
| / \ \
| / \ \
| / \ \
| / \ \
P7 P8--P9---------P10-P11 P12
| / \ |
| / \ |
| / \ |
|/ \|
PE1 PE2 PE5 PE6
Figure 6: An MP2MP Service Installed at PE1, PE3, and PE6
6.2. P2MP Unidirectional Connectivity
Figure 7 shows the provision of a Point-to-Multipoint (P2MP) rooted
at PE3 and connected to PE1 and PE6. As in the previous example, a
redundant pair of paths is established between PE3 and each of PE1
and PE6. Thus, the two paths from PE3 to PE1 are PE3-P1-P4-P7-PE1
and PE3-P2-P9-P8-PE1.
Drake, et al. Expires November 22, 2020 [Page 14]
Internet-Draft MPLS SFC May 2020
PE3 PE4
| \
| \
| \
| \
| \
| \
| \
| \
P1 P2
|\ / \
| \ / \
| \ / \
| \ / \
P3 P4 X P5 P6
/ / \ |
/ / \ |
/ / \ |
/ / \ |
P7---P8--P9 P10-P11 P12
| / \ |
| / \ |
| / \ |
|/ \|
PE1 PE2 PE5 PE6
Figure 7: A P2MP Unidirectional Service Installed at PE3
6.3. P2P Unidirectional Connectivity
Figure 8 shows a Point-to-Point (P2P) service rooted at PE1 and
connected to PE3. This is equivalent to a Segment Routing Traffic
Engineering (SR TE) Policy [I-D.ietf-idr-segment-routing-te-policy]
installed at PE1.
As in the previous examples, a pair of redundant paths are computed.
Drake, et al. Expires November 22, 2020 [Page 15]
Internet-Draft MPLS SFC May 2020
PE3 PE4
|\
| \
| \
| \
| \
| \
| \
| \
P1 P2
| |
| |
| |
| |
P3 P4 P5 P6
/ |
/ |
/ |
/ |
P7 P8--P9--------P10 P11 P12
| /
| /
| /
|/
PE1 PE2 PE5 PE6
Figure 8: A P2P Unidirectional Service (SR TE Policy) Installed at
PE1
6.4. P2P Bidirectional Connectivity
Figure 9 show a bidirectional P2P service connecting PE1 and PE6.
This is equivalent to a Segment Routing Traffic Engineering (SR TE)
Policy [I-D.ietf-idr-segment-routing-te-policy] installed at PE1 and
PE6.
Drake, et al. Expires November 22, 2020 [Page 16]
Internet-Draft MPLS SFC May 2020
PE3 PE4
P1 P2
P3 P4--------P5 P6
/ \
/ \
/ \
/ \
P7 P8--P9--------P10-P11 P12
| / \ |
| / \ |
| / \ |
|/ \|
PE1 PE2 PE5 PE6
Figure 9: A P2P Bidirectional Service Installed at PE1 and PE6
7. Security Considerations
TBD
8. Manageability Considerations
Per VPN OAM and telemetry will be required in order to monitor and
verify the performance of network slices. This is particularly
important when the performance of a network slice has been committed
to a customer through a Service Level Agreement.
TBD
9. IANA Considerations
9.1. New BGP Path Attribute
IANA maintains a registry of "Border Gateway Protocol (BGP)
Parameters" with a subregistry of "BGP Path Attributes". IANA is
requested to assign a new Path attribute called "BGP-LS Filter
attribute" (TBD1 in this document) with this document as a reference.
Drake, et al. Expires November 22, 2020 [Page 17]
Internet-Draft MPLS SFC May 2020
9.2. New BGP-LS Filter attribute TLVs Type Registry
IANA maintains a registry of "Border Gateway Protocol (BGP)
Parameters". IANA is request to create a new subregistry called the
"BGP-LS Filter attribute TLVs" registry.
Valid values are in the range 0 to 255.
o Values 0 and 255 are to be marked "Reserved, not to be allocated".
o Values 1 through 254 are to be assigned according to the "First
Come First Served" policy [RFC8126]
This document should be given as a reference for this registry. The
new registry should track:
o Type
o Name
o Reference Document or Contact
o Registration Date
The registry should initially be populated as follows:
Type | Name | Reference | Date
------+-------------------------+---------------+---------------
1 | Filter TLV | [This.I-D] | Date-to-be-set
2 | DSCP List TLV | [This.I-D] | Date-to-be-set
3 | Color List TLV | [This.I-D] | Date-to-be-set
4 | Root TLV | [This.I-D] | Date-to-be-set
10. Acknowledgements
The authors are grateful to all those who contributed to the
discussions that led to this work: Ron Bonica, Stewart Bryant, Jie
Dong, Keyur Patel, and Colby Barth.
11. References
11.1. Normative References
Drake, et al. Expires November 22, 2020 [Page 18]
Internet-Draft MPLS SFC May 2020
[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>.
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Border Gateway Protocol 4 (BGP-4)", RFC 4271,
DOI 10.17487/RFC4271, January 2006,
<https://www.rfc-editor.org/info/rfc4271>.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
2006, <https://www.rfc-editor.org/info/rfc4364>.
[RFC5512] Mohapatra, P. and E. Rosen, "The BGP Encapsulation
Subsequent Address Family Identifier (SAFI) and the BGP
Tunnel Encapsulation Attribute", RFC 5512,
DOI 10.17487/RFC5512, April 2009,
<https://www.rfc-editor.org/info/rfc5512>.
[RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A.,
Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based
Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February
2015, <https://www.rfc-editor.org/info/rfc7432>.
[RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K.
Patel, "Revised Error Handling for BGP UPDATE Messages",
RFC 7606, DOI 10.17487/RFC7606, August 2015,
<https://www.rfc-editor.org/info/rfc7606>.
[RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and
S. Ray, "North-Bound Distribution of Link-State and
Traffic Engineering (TE) Information Using BGP", RFC 7752,
DOI 10.17487/RFC7752, March 2016,
<https://www.rfc-editor.org/info/rfc7752>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[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>.
Drake, et al. Expires November 22, 2020 [Page 19]
Internet-Draft MPLS SFC May 2020
11.2. Informative References
[I-D.ietf-idr-segment-routing-te-policy]
Previdi, S., Filsfils, C., Talaulikar, K., Mattes, P.,
Rosen, E., Jain, D., and S. Lin, "Advertising Segment
Routing Policies in BGP", draft-ietf-idr-segment-routing-
te-policy-08 (work in progress), November 2019.
[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+)
Services", draft-ietf-teas-enhanced-vpn-05 (work in
progress), February 2020.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
<https://www.rfc-editor.org/info/rfc3209>.
[RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended
Communities Attribute", RFC 4360, DOI 10.17487/RFC4360,
February 2006, <https://www.rfc-editor.org/info/rfc4360>.
[RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route
Reflection: An Alternative to Full Mesh Internal BGP
(IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006,
<https://www.rfc-editor.org/info/rfc4456>.
[RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk,
R., Patel, K., and J. Guichard, "Constrained Route
Distribution for Border Gateway Protocol/MultiProtocol
Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual
Private Networks (VPNs)", RFC 4684, DOI 10.17487/RFC4684,
November 2006, <https://www.rfc-editor.org/info/rfc4684>.
[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>.
[TS23501] 3GPP, "System architecture for the 5G System (5GS) - 3GPP
TS23.501", 2016,
<https://portal.3gpp.org/desktopmodules/Specifications/
SpecificationDetails.aspx?specificationId=3144>.
Drake, et al. Expires November 22, 2020 [Page 20]
Internet-Draft MPLS SFC May 2020
[TS28530] 3GPP, "Management and orchestration; Concepts, use cases
and requirements - 3GPP TS28.530", 2016,
<https://portal.3gpp.org/desktopmodules/Specifications/
SpecificationDetails.aspx?specificationId=3144>.
Authors' Addresses
John Drake
Juniper Networks
Email: jdrake@juniper.net
Adrian Farrel
Old Dog Consulting
Email: adrian@olddog.co.uk
Luay Jalil
Verizon
Email: luay.jalil@verizon.com
Avinash Lingala
AT&T
Email: ar977m@att.com
Drake, et al. Expires November 22, 2020 [Page 21]