draft-ietf-bess-nsh-bgp-control-plane-15.txt   draft-ietf-bess-nsh-bgp-control-plane-16.txt 
BESS Working Group A. Farrel BESS Working Group A. Farrel
Internet-Draft Old Dog Consulting Internet-Draft Old Dog Consulting
Intended status: Standards Track J. Drake Intended status: Standards Track J. Drake
Expires: December 17, 2020 E. Rosen Expires: February 20, 2021 E. Rosen
Juniper Networks Juniper Networks
J. Uttaro J. Uttaro
AT&T AT&T
L. Jalil L. Jalil
Verizon Verizon
June 15, 2020 August 19, 2020
BGP Control Plane for the Network Service Header in Service Function BGP Control Plane for the Network Service Header in Service Function
Chaining Chaining
draft-ietf-bess-nsh-bgp-control-plane-15 draft-ietf-bess-nsh-bgp-control-plane-16
Abstract Abstract
This document describes the use of BGP as a control plane for This document describes the use of BGP as a control plane for
networks that support Service Function Chaining (SFC). The document networks that support Service Function Chaining (SFC). The document
introduces a new BGP address family called the SFC Address Family introduces a new BGP address family called the SFC Address Family
Identifier / Subsequent Address Family Identifier (SFC AFI/SAFI) with Identifier / Subsequent Address Family Identifier (SFC AFI/SAFI) with
two route types. One route type is originated by a node to advertise two route types. One route type is originated by a node to advertise
that it hosts a particular instance of a specified service function. that it hosts a particular instance of a specified service function.
This route type also provides "instructions" on how to send a packet This route type also provides "instructions" on how to send a packet
skipping to change at page 2, line 4 skipping to change at page 2, line 4
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 December 17, 2020. This Internet-Draft will expire on February 20, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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 2, line 34 skipping to change at page 2, line 34
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Overview of Service Function Chaining . . . . . . . . . . 6 2.1. Overview of Service Function Chaining . . . . . . . . . . 6
2.2. Control Plane Overview . . . . . . . . . . . . . . . . . 8 2.2. Control Plane Overview . . . . . . . . . . . . . . . . . 8
3. BGP SFC Routes . . . . . . . . . . . . . . . . . . . . . . . 12 3. BGP SFC Routes . . . . . . . . . . . . . . . . . . . . . . . 12
3.1. Service Function Instance Route (SFIR) . . . . . . . . . 13 3.1. Service Function Instance Route (SFIR) . . . . . . . . . 13
3.1.1. SFIR Pool Identifier Extended Community . . . . . . . 14 3.1.1. SFIR Pool Identifier Extended Community . . . . . . . 14
3.1.2. MPLS Mixed Swapping/Stacking Extended Community . . . 15 3.1.2. MPLS Mixed Swapping/Stacking Extended Community . . . 15
3.2. Service Function Path Route (SFPR) . . . . . . . . . . . 16 3.2. Service Function Path Route (SFPR) . . . . . . . . . . . 16
3.2.1. The SFP Attribute . . . . . . . . . . . . . . . . . . 16 3.2.1. The SFP Attribute . . . . . . . . . . . . . . . . . . 17
3.2.2. General Rules For The SFP Attribute . . . . . . . . . 22 3.2.2. General Rules For The SFP Attribute . . . . . . . . . 22
4. Mode of Operation . . . . . . . . . . . . . . . . . . . . . . 23 4. Mode of Operation . . . . . . . . . . . . . . . . . . . . . . 23
4.1. Route Targets . . . . . . . . . . . . . . . . . . . . . . 23 4.1. Route Targets . . . . . . . . . . . . . . . . . . . . . . 23
4.2. Service Function Instance Routes . . . . . . . . . . . . 24 4.2. Service Function Instance Routes . . . . . . . . . . . . 24
4.3. Service Function Path Routes . . . . . . . . . . . . . . 24 4.3. Service Function Path Routes . . . . . . . . . . . . . . 24
4.4. Classifier Operation . . . . . . . . . . . . . . . . . . 26 4.4. Classifier Operation . . . . . . . . . . . . . . . . . . 26
4.5. Service Function Forwarder Operation . . . . . . . . . . 26 4.5. Service Function Forwarder Operation . . . . . . . . . . 27
4.5.1. Processing With 'Gaps' in the SI Sequence . . . . . . 27 4.5.1. Processing With 'Gaps' in the SI Sequence . . . . . . 28
5. Selection within Service Function Paths . . . . . . . . . . . 29 5. Selection within Service Function Paths . . . . . . . . . . . 29
6. Looping, Jumping, and Branching . . . . . . . . . . . . . . . 31 6. Looping, Jumping, and Branching . . . . . . . . . . . . . . . 31
6.1. Protocol Control of Looping, Jumping, and Branching . . . 31 6.1. Protocol Control of Looping, Jumping, and Branching . . . 32
6.2. Implications for Forwarding State . . . . . . . . . . . . 32 6.2. Implications for Forwarding State . . . . . . . . . . . . 33
7. Advanced Topics . . . . . . . . . . . . . . . . . . . . . . . 33 7. Advanced Topics . . . . . . . . . . . . . . . . . . . . . . . 33
7.1. Correlating Service Function Path Instances . . . . . . . 33 7.1. Correlating Service Function Path Instances . . . . . . . 33
7.2. Considerations for Stateful Service Functions . . . . . . 34 7.2. Considerations for Stateful Service Functions . . . . . . 34
7.3. VPN Considerations and Private Service Functions . . . . 35 7.3. VPN Considerations and Private Service Functions . . . . 35
7.4. Flow Specification for SFC Classifiers . . . . . . . . . 35 7.4. Flow Specification for SFC Classifiers . . . . . . . . . 35
7.5. Choice of Data Plane SPI/SI Representation . . . . . . . 37 7.5. Choice of Data Plane SPI/SI Representation . . . . . . . 37
7.5.1. MPLS Representation of the SPI/SI . . . . . . . . . . 38 7.5.1. MPLS Representation of the SPI/SI . . . . . . . . . . 38
7.6. MPLS Label Swapping/Stacking Operation . . . . . . . . . 38 7.6. MPLS Label Swapping/Stacking Operation . . . . . . . . . 38
7.7. Support for MPLS-Encapsulated NSH Packets . . . . . . . . 39 7.7. Support for MPLS-Encapsulated NSH Packets . . . . . . . . 39
8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 39 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 39
8.1. Example Explicit SFP With No Choices . . . . . . . . . . 41 8.1. Example Explicit SFP With No Choices . . . . . . . . . . 41
8.2. Example SFP With Choice of SFIs . . . . . . . . . . . . . 41 8.2. Example SFP With Choice of SFIs . . . . . . . . . . . . . 42
8.3. Example SFP With Open Choice of SFIs . . . . . . . . . . 42 8.3. Example SFP With Open Choice of SFIs . . . . . . . . . . 42
8.4. Example SFP With Choice of SFTs . . . . . . . . . . . . . 42 8.4. Example SFP With Choice of SFTs . . . . . . . . . . . . . 43
8.5. Example Correlated Bidirectional SFPs . . . . . . . . . . 43 8.5. Example Correlated Bidirectional SFPs . . . . . . . . . . 43
8.6. Example Correlated Asymmetrical Bidirectional SFPs . . . 43 8.6. Example Correlated Asymmetrical Bidirectional SFPs . . . 44
8.7. Example Looping in an SFP . . . . . . . . . . . . . . . . 44 8.7. Example Looping in an SFP . . . . . . . . . . . . . . . . 44
8.8. Example Branching in an SFP . . . . . . . . . . . . . . . 45 8.8. Example Branching in an SFP . . . . . . . . . . . . . . . 45
8.9. Examples of SFPs with Stateful Service Functions . . . . 45 8.9. Examples of SFPs with Stateful Service Functions . . . . 46
8.9.1. Forward and Reverse Choice Made at the SFF . . . . . 46 8.9.1. Forward and Reverse Choice Made at the SFF . . . . . 46
8.9.2. Parallel End-to-End SFPs with Shared SFF . . . . . . 47 8.9.2. Parallel End-to-End SFPs with Shared SFF . . . . . . 48
8.9.3. Parallel End-to-End SFPs with Separate SFFs . . . . . 49 8.9.3. Parallel End-to-End SFPs with Separate SFFs . . . . . 49
8.9.4. Parallel SFPs Downstream of the Choice . . . . . . . 51 8.9.4. Parallel SFPs Downstream of the Choice . . . . . . . 51
8.10. Examples Using IPv6 Addressing . . . . . . . . . . . . . 54 8.10. Examples Using IPv6 Addressing . . . . . . . . . . . . . 54
8.10.1. Example Explicit SFP With No Choices . . . . . . . . 56 8.10.1. Example Explicit SFP With No Choices . . . . . . . . 56
8.10.2. Example SFP With Choice of SFIs . . . . . . . . . . 56 8.10.2. Example SFP With Choice of SFIs . . . . . . . . . . 57
8.10.3. Example SFP With Open Choice of SFIs . . . . . . . . 57 8.10.3. Example SFP With Open Choice of SFIs . . . . . . . . 57
8.10.4. Example SFP With Choice of SFTs . . . . . . . . . . 57 8.10.4. Example SFP With Choice of SFTs . . . . . . . . . . 58
9. Security Considerations . . . . . . . . . . . . . . . . . . . 58 9. Security Considerations . . . . . . . . . . . . . . . . . . . 59
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 60 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 61
10.1. New BGP AF/SAFI . . . . . . . . . . . . . . . . . . . . 60 10.1. New BGP AF/SAFI . . . . . . . . . . . . . . . . . . . . 61
10.2. New BGP Path Attribute . . . . . . . . . . . . . . . . . 60 10.2. New BGP Path Attribute . . . . . . . . . . . . . . . . . 61
10.3. New SFP Attribute TLVs Type Registry . . . . . . . . . . 61 10.3. New SFP Attribute TLVs Type Registry . . . . . . . . . . 61
10.4. New SFP Association Type Registry . . . . . . . . . . . 61 10.4. New SFP Association Type Registry . . . . . . . . . . . 62
10.5. New Service Function Type Registry . . . . . . . . . . . 62 10.5. New Service Function Type Registry . . . . . . . . . . . 63
10.6. New Generic Transitive Experimental Use Extended 10.6. New Generic Transitive Experimental Use Extended
Community Sub-Types . . . . . . . . . . . . . . . . . . 63 Community Sub-Types . . . . . . . . . . . . . . . . . . 65
10.7. New BGP Transitive Extended Community Type . . . . . . . 64 10.7. New BGP Transitive Extended Community Type . . . . . . . 65
10.8. New SFC Extended Community Sub-Types Registry . . . . . 64 10.8. New SFC Extended Community Sub-Types Registry . . . . . 65
10.9. SPI/SI Representation . . . . . . . . . . . . . . . . . 64 10.9. SPI/SI Representation . . . . . . . . . . . . . . . . . 66
10.10. SFC SPI/SI Representation Flags Registry . . . . . . . . 65 10.10. SFC SPI/SI Representation Flags Registry . . . . . . . . 66
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 65 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 66
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 65 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 67
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 66 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 67
13.1. Normative References . . . . . . . . . . . . . . . . . . 66 13.1. Normative References . . . . . . . . . . . . . . . . . . 67
13.2. Informative References . . . . . . . . . . . . . . . . . 67 13.2. Informative References . . . . . . . . . . . . . . . . . 69
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 70
1. Introduction 1. Introduction
As described in [RFC7498], the delivery of end-to-end services can As described in [RFC7498], the delivery of end-to-end services can
require a packet to pass through a series of Service Functions (SFs) require a packet to pass through a series of Service Functions (SFs)
(e.g., WAN and application accelerators, Deep Packet Inspection (DPI) (e.g., WAN and application accelerators, Deep Packet Inspection (DPI)
engines, firewalls, TCP optimizers, and server load balancers) in a engines, firewalls, TCP optimizers, and server load balancers) in a
specified order: this is termed "Service Function Chaining" (SFC). specified order: this is termed "Service Function Chaining" (SFC).
There are a number of issues associated with deploying and There are a number of issues associated with deploying and
maintaining service function chaining in production networks, which maintaining service function chaining in production networks, which
skipping to change at page 4, line 43 skipping to change at page 4, line 43
In order to address these issues, the SFC architecture describes In order to address these issues, the SFC architecture describes
Service Function Chains that are built in their own overlay network Service Function Chains that are built in their own overlay network
(the service function overlay network), coexisting with other overlay (the service function overlay network), coexisting with other overlay
networks, over a common underlay network [RFC7665]. A Service networks, over a common underlay network [RFC7665]. A Service
Function Chain is a sequence of Service Functions through which Function Chain is a sequence of Service Functions through which
packet flows that satisfy specified criteria will pass. packet flows that satisfy specified criteria will pass.
This document describes the use of BGP as a control plane for This document describes the use of BGP as a control plane for
networks that support Service Function Chaining (SFC). The document networks that support Service Function Chaining (SFC). The document
introduces a new BGP address family called the SFC AFI/SAFI with two introduces a new BGP address family called the SFC Address Family
Identifier / Subsequent Address Family Identifier (AFI/SAFI) with two
route types. One route type is originated by a node to advertise route types. One route type is originated by a node to advertise
that it hosts a particular instance of a specified service function. that it hosts a particular instance of a specified service function.
This route type also provides "instructions" on how to send a packet This route type also provides "instructions" on how to send a packet
to the hosting node in a way that indicates that the service function to the hosting node in a way that indicates that the service function
has to be applied to the packet. The other route type is used by a has to be applied to the packet. The other route type is used by a
Controller (a centralized network component responsible for planning Controller (a centralized network component responsible for planning
and coordinating Service Function Chaining within the network) to and coordinating Service Function Chaining within the network) to
advertise the paths of "chains" of service functions, and to give a advertise the paths of "chains" of service functions, and to give a
unique designator to each such path so that they can be used in unique designator to each such path so that they can be used in
conjunction with the Network Service Header [RFC8300]. conjunction with the Network Service Header [RFC8300].
skipping to change at page 8, line 37 skipping to change at page 8, line 37
of Service Function Types is introduced in Section 10.5 and is of Service Function Types is introduced in Section 10.5 and is
consistent with types used in other work such as consistent with types used in other work such as
[I-D.dawra-idr-bgp-ls-sr-service-segments]. An SFF may support SFs [I-D.dawra-idr-bgp-ls-sr-service-segments]. An SFF may support SFs
of multiple different SFTs, and may support multiple SFIs of each SF. of multiple different SFTs, and may support multiple SFIs of each SF.
The registry of SFT values (see Section 10.5) is split into three The registry of SFT values (see Section 10.5) is split into three
ranges with assignment policies per [RFC8126]: ranges with assignment policies per [RFC8126]:
o The Special Purpose SFT values range is assigned through Standards o The Special Purpose SFT values range is assigned through Standards
Action. Values in that range are used for special SFC operations Action. Values in that range are used for special SFC operations
and do not apply to the types SF that may be placed on the SFC. and do not apply to the types of SF that may form part of the SFP.
o The First Come First Served range tracks assignments of STF values o The First Come First Served range tracks assignments of STF values
made by any party that defines an SF type. Reference through an made by any party that defines an SF type. Reference through an
Internet-Draft is desirable, but not required. Internet-Draft is desirable, but not required.
o The Private Use range is not tracked by IANA and is primarily o The Private Use range is not tracked by IANA and is primarily
intended for use in private networks where the meaning of the SFT intended for use in private networks where the meaning of the SFT
values is locally tracked and under the control of a local values is locally tracked and under the control of a local
administrator. administrator.
skipping to change at page 9, line 12 skipping to change at page 9, line 12
ensure interoperability especially in situations where software and ensure interoperability especially in situations where software and
hardware from different vendors is deployed in the same networks, or hardware from different vendors is deployed in the same networks, or
when networks are merged. However, operators of private networks may when networks are merged. However, operators of private networks may
choose to develop their own SFs and manage the configuration and choose to develop their own SFs and manage the configuration and
operation of their network through their own list of SFT values. operation of their network through their own list of SFT values.
This document also introduces a new BGP AFI/SAFI (values to be This document also introduces a new BGP AFI/SAFI (values to be
assigned by IANA) for "SFC Routes". Two SFC Route Types are defined assigned by IANA) for "SFC Routes". Two SFC Route Types are defined
by this document: the Service Function Instance Route (SFIR), and the by this document: the Service Function Instance Route (SFIR), and the
Service Function Path Route (SFPR). As detailed in Section 3, the Service Function Path Route (SFPR). As detailed in Section 3, the
route type is indicated by a sub-field in the NLRI. route type is indicated by a sub-field in the Network Layer
Reachability Information (NLRI).
o The SFIR is advertised by the node hosting the service function o The SFIR is advertised by the node that provides access to the
instance (i.e., the SFF). The SFIR describes a particular service function instance (i.e., the SFF). The SFIR describes a
instance of a particular Service Function (i.e., an SFI) and the particular instance of a particular Service Function (i.e., an
way to forward a packet to it through the underlay network, i.e., SFI) and the way to forward a packet to it through the underlay
IP address and encapsulation information. network, i.e., IP address and encapsulation information.
o The SFPRs are originated by Controllers. One SFPR is originated o The SFPRs are originated by Controllers. One SFPR is originated
for each Service Function Path. The SFPR specifies: for each Service Function Path. The SFPR specifies:
A. the SPI of the path A. the SPI of the path
B. the sequence of SFTs and/or SFIs of which the path consists B. the sequence of SFTs and/or SFIs of which the path consists
C. for each such SFT or SFI, the SI that represents it in the C. for each such SFT or SFI, the SI that represents it in the
identified path. identified path.
This approach assumes that there is an underlay network that provides This approach assumes that there is an underlay network that provides
connectivity between SFFs and Controllers, and that the SFFs are connectivity between SFFs and Controllers, and that the SFFs are
grouped to form one or more service function overlay networks through grouped to form one or more service function overlay networks through
which SFPs are built. We assume the the Controllers have BGP which SFPs are built. We assume that the Controllers have BGP
connectivity to all SFFs and all Classifiers within each service connectivity to all SFFs and all Classifiers within each service
function overlay network. function overlay network.
When choosing the next SFI in a path, the SFF uses the SPI and SI as When choosing the next SFI in a path, the SFF uses the SPI and SI as
well as the SFT to choose among the SFIs, applying, for example, a well as the SFT to choose among the SFIs, applying, for example, a
load balancing algorithm or direct knowledge of the underlay network load balancing algorithm or direct knowledge of the underlay network
topology as described in Section 4. topology as described in Section 4.
The SFF then encapsulates the packet using the encapsulation The SFF then encapsulates the packet using the encapsulation
specified by the SFIR of the selected SFI and forwards the packet. specified by the SFIR of the selected SFI and forwards the packet.
skipping to change at page 12, line 14 skipping to change at page 12, line 14
As previously noted, [RFC8300] makes it clear that the mechanisms it As previously noted, [RFC8300] makes it clear that the mechanisms it
defines are intended for use within a single provider's operational defines are intended for use within a single provider's operational
domain. This reduces the requirements on the control plane function. domain. This reduces the requirements on the control plane function.
[RFC7665] sets out the functions provided by a control plane for an [RFC7665] sets out the functions provided by a control plane for an
SFC network in Section 5.2. The functions are broken down into six SFC network in Section 5.2. The functions are broken down into six
items the first four of which are completely covered by the items the first four of which are completely covered by the
mechanisms described in this document: mechanisms described in this document:
1. Visiblity of all SFs and the SFFs through which they are reached. 1. Visibility of all SFs and the SFFs through which they are
reached.
2. Computation of SFPs and progrmming into the network. 2. Computation of SFPs and programming into the network.
3. Selection of SFIs explicitly in the SFP or dynamically within the 3. Selection of SFIs explicitly in the SFP or dynamically within the
network. network.
4. Programming of SFFs with forwarding path information. 4. Programming of SFFs with forwarding path information.
The fifth and six items in the list in RFC 7665 concern the use of The fifth and six items in the list in RFC 7665 concern the use of
metadata. These are more peripheral to the control plane mechanisms metadata. These are more peripheral to the control plane mechanisms
defined in this document, but are discussed in Section 4.4. defined in this document, but are discussed in Section 4.4.
skipping to change at page 14, line 41 skipping to change at page 14, line 43
Note that the Tunnel Encapsulation attribute MUST contain sufficient Note that the Tunnel Encapsulation attribute MUST contain sufficient
information to allow the advertising SFF to identify the overlay or information to allow the advertising SFF to identify the overlay or
VPN network which a received packet is transiting. This is because VPN network which a received packet is transiting. This is because
the [SPI, SI] in a received packet is specific to a particular the [SPI, SI] in a received packet is specific to a particular
overlay or VPN network. overlay or VPN network.
3.1.1. SFIR Pool Identifier Extended Community 3.1.1. SFIR Pool Identifier Extended Community
This document defines a new transitive extended community [RFC4360] This document defines a new transitive extended community [RFC4360]
of type TBD6 called the SFC extended community. When used with Sub- of type TBD6 called the SFC extended community. When used with Sub-
Type TBD7, this is called the SFIR Pool Identifier extended Type 1, this is called the SFIR Pool Identifier extended community.
community. It MAY be included in SFIR advertisements, and is used to It MAY be included in SFIR advertisements, and is used to indicate
indicate the identity of a pool of SFIRs to which an SFIR belongs. the identity of a pool of SFIRs to which an SFIR belongs. Since an
Since an SFIR may be a member of multiple pools, multiple of these SFIR may be a member of multiple pools, multiple of these extended
extended communities may be present on a single SFIR advertisement. communities may be present on a single SFIR advertisement.
SFIR pools allow SFIRs to be grouped for any purpose. Possible uses SFIR pools allow SFIRs to be grouped for any purpose. Possible uses
include control plane scalability and stability. A pool identifier include control plane scalability and stability. A pool identifier
may be included in an SFPR to indicate a set of SFIs that are may be included in an SFPR to indicate a set of SFIs that are
acceptable at a specific point on an SFP (see Section 3.2.1.3 and acceptable at a specific point on an SFP (see Section 3.2.1.3 and
Section 4.3). Section 4.3).
The SFIR Pool Identifier extended community is encoded in 8 octets as The SFIR Pool Identifier extended community is encoded in 8 octets as
shown in Figure 4. shown in Figure 4.
+--------------------------------------------+ +--------------------------------------------+
| Type = TBD6 (1 octet) | | Type = TBD6 (1 octet) |
+--------------------------------------------+ +--------------------------------------------+
| Sub-Type = TBD7 (1 octet) | | Sub-Type = 1 (1 octet) |
+--------------------------------------------+ +--------------------------------------------+
| SFIR Pool Identifier Value (6 octets) | | SFIR Pool Identifier Value (6 octets) |
+--------------------------------------------+ +--------------------------------------------+
Figure 4: The SFIR Pool Identifier Extended Community Figure 4: The SFIR Pool Identifier Extended Community
The SFIR Pool Identifier Value is encoded in a 6 octet field in The SFIR Pool Identifier Value is encoded in a 6 octet field in
network byte order, and the value is unique within the scope of an network byte order, and the value is unique within the scope of an
overlay network. This means that pool identifiers need to be overlay network. This means that pool identifiers need to be
centrally managed, which is consistent with the assignment of SFIs to centrally managed, which is consistent with the assignment of SFIs to
pools. pools.
3.1.2. MPLS Mixed Swapping/Stacking Extended Community 3.1.2. MPLS Mixed Swapping/Stacking Extended Community
As noted in Section 3.1.1, this document defines a new transitive As noted in Section 3.1.1, this document defines a new transitive
extended community of type TBD6 called the SFC extended community. extended community of type TBD6 called the SFC extended community.
When used with Sub-Type TBD8, this is called the MPLS Mixed Swapping/ When used with Sub-Type 2, this is called the MPLS Mixed Swapping/
Stacking Labels extended community. The community is encoded as Stacking Labels extended community. The community is encoded as
shown in Figure 5. It contains a pair of MPLS labels: an SFC Context shown in Figure 5. It contains a pair of MPLS labels: an SFC Context
Label and an SF Label as described in [RFC8595]. Each label is 20 Label and an SF Label as described in [RFC8595]. Each label is 20
bits encoded in a 3-octet (24 bit) field with 4 trailing bits that bits encoded in a 3-octet (24 bit) field with 4 trailing bits that
MUST be set to zero. MUST be set to zero.
+--------------------------------------------+ +--------------------------------------------+
| Type = TBD6 (1 octet) | | Type = TBD6 (1 octet) |
+--------------------------------------------| +--------------------------------------------|
| Sub-Type = TBD8 (1 octet) | | Sub-Type = 2 (1 octet) |
+--------------------------------------------| +--------------------------------------------|
| SFC Context Label (3 octets) | | SFC Context Label (3 octets) |
+--------------------------------------------| +--------------------------------------------|
| SF Label (3 octets) | | SF Label (3 octets) |
+--------------------------------------------+ +--------------------------------------------+
Figure 5: The MPLS Mixed Swapping/Stacking Extended Community Figure 5: The MPLS Mixed Swapping/Stacking Extended Community
Note that it is assumed that each SFF has one or more globally unique Note that it is assumed that each SFF has one or more globally unique
SFC Context Labels and that the context label space and the SPI SFC Context Labels and that the context label space and the SPI
skipping to change at page 22, line 17 skipping to change at page 22, line 24
may be used at the hop. The SFIs are identified using the SFIR- may be used at the hop. The SFIs are identified using the SFIR-
RDs from the advertisements of the SFIs in the SFIRs. Note that RDs from the advertisements of the SFIs in the SFIRs. Note that
if the list contains one or more SFIR Pool Identifiers, then for if the list contains one or more SFIR Pool Identifiers, then for
each the SFIR-RD list is effectively expanded to include the SFIR- each the SFIR-RD list is effectively expanded to include the SFIR-
RD of each SFIR advertised with that SFIR Pool Identifier. An RD of each SFIR advertised with that SFIR Pool Identifier. An
SFIR-RD of value zero has special meaning as described in SFIR-RD of value zero has special meaning as described in
Section 5. Each entry in the list is eight octets long, and the Section 5. Each entry in the list is eight octets long, and the
number of entries in the list can be deduced from the value of the number of entries in the list can be deduced from the value of the
Length field. Length field.
Note that an SFIR-RD can be distinguished from an SFIR Pool
Identifier because they are both BGP Extended Communities but they
have different extended community types.
3.2.1.4. MPLS Swapping/Stacking Sub-TLV 3.2.1.4. MPLS Swapping/Stacking Sub-TLV
The MPLS Swapping/Stacking Sub-TLV (Type value 4) is a zero length The MPLS Swapping/Stacking Sub-TLV (Type value 4) is a zero length
sub-TLV that is OPTIONAL in the Hop TLV and is used when the data sub-TLV that is OPTIONAL in the Hop TLV and is used when the data
representation is MPLS (see Section 7.5). When present it indicates representation is MPLS (see Section 7.5). When present it indicates
to the Classifier imposing an MPLS label stack that the current hop to the Classifier imposing an MPLS label stack that the current hop
is to use an {SFC Context Label, SF label} rather than an {SPI, SF} is to use an {SFC Context Label, SF label} rather than an {SPI, SF}
label pair. See Section 7.6 for more details. label pair. See Section 7.6 for more details.
3.2.1.5. SFP Traversal With MPLS Label Stack TLV 3.2.1.5. SFP Traversal With MPLS Label Stack TLV
The SFP Traversal With MPLS Label Stack TLV (Type value 5) is a zero The SFP Traversal With MPLS Label Stack TLV (Type value 5) is a zero
length TLV that can be carried in the SFP Attribute and indicates to length TLV that can be carried in the SFP Attribute and indicates to
the Classifier and the SFFs on the SFP that an MPLS label stack with the Classifier and the SFFs on the SFP that an MPLS label stack with
label swapping/stacking is to be used for packets traversing the SFP. label swapping/stacking is to be used for packets traversing the SFP.
All of the SFF specified at each the SFP's hops MUST have advertised All of the SFFs specified at each of the SFP's hops MUST have
an MPLS Mixed Swapping/Stacking Extended Community (see advertised an MPLS Mixed Swapping/Stacking Extended Community (see
Section 3.1.2) for the SFP to be considered usable. Section 3.1.2) for the SFP to be considered usable.
3.2.2. General Rules For The SFP Attribute 3.2.2. General Rules For The SFP Attribute
It is possible for the same SFI, as described by an SFIR, to be used It is possible for the same SFI, as described by an SFIR, to be used
in multiple SFPRs. in multiple SFPRs.
When two SFPRs have the same SPI but different SFPR-RDs there can be When two SFPRs have the same SPI but different SFPR-RDs there can be
three cases: three cases:
skipping to change at page 23, line 11 skipping to change at page 23, line 23
o There is a transition in content of the advertised SFP and the o There is a transition in content of the advertised SFP and the
advertisements may originate from one or more Controllers. In advertisements may originate from one or more Controllers. In
this case the content of the SFPRs will be different. this case the content of the SFPRs will be different.
o The reuse of an SPI may result from a configuration error. o The reuse of an SPI may result from a configuration error.
In all cases, there is no way for the receiving SFF to know which In all cases, there is no way for the receiving SFF to know which
SFPR to process, and the SFPRs could be received in any order. At SFPR to process, and the SFPRs could be received in any order. At
any point in time, when multiple SFPRs have the same SPI but any point in time, when multiple SFPRs have the same SPI but
different SFPR-RDs, the SFF MUST use the SFPR with the numerically different SFPR-RDs, the SFF MUST use the SFPR with the numerically
lowest SFPR-RD when interpretting the RDs as 8-octet integers in lowest SFPR-RD when interpreting the RDs as 8-octet integers in
network byte order. The SFF SHOULD log this occurrence to assist network byte order. The SFF SHOULD log this occurrence to assist
with debugging. with debugging.
Furthermore, a Controller that wants to change the content of an SFP Furthermore, a Controller that wants to change the content of an SFP
is RECOMMENDED to use a new SPI and so create a new SFP onto which is RECOMMENDED to use a new SPI and so create a new SFP onto which
the Classifiers can transition packet flows before the SFPR for the the Classifiers can transition packet flows before the SFPR for the
old SFP is withdrawn. This avoids any race conditions with SFPR old SFP is withdrawn. This avoids any race conditions with SFPR
advertisements. advertisements.
Additionally, a Controller SHOULD NOT re-use an SPI after it has Additionally, a Controller SHOULD NOT re-use an SPI after it has
skipping to change at page 23, line 44 skipping to change at page 24, line 9
Targets (RTs) [RFC4364]. Targets (RTs) [RFC4364].
Every BGP UPDATE containing an SFIR or SFPR carries one or more RTs. Every BGP UPDATE containing an SFIR or SFPR carries one or more RTs.
The RT carried by a particular SFIR or SFPR is determined by the The RT carried by a particular SFIR or SFPR is determined by the
provisioning of the route's originator. provisioning of the route's originator.
Every node in a service function overlay network is configured with Every node in a service function overlay network is configured with
one or more import RTs. Thus, each SFF will import only the SFPRs one or more import RTs. Thus, each SFF will import only the SFPRs
with matching RTs allowing the construction of multiple service with matching RTs allowing the construction of multiple service
function overlay networks or the instantiation of Service Function function overlay networks or the instantiation of Service Function
Chains within an L3VPN or EVPN instance (see Section 7.3). An SFF Chains within an Layer 3 Virtual Private Network (L3VPN) or Ethernet
that has a presence in multiple service function overlay networks VPN (EVPN) instance (see Section 7.3). An SFF that has a presence in
(i.e., imports more than one RT) will usually maintain separate multiple service function overlay networks (i.e., imports more than
forwarding state for each overlay network. one RT) will usually maintain separate forwarding state for each
overlay network.
4.2. Service Function Instance Routes 4.2. Service Function Instance Routes
The SFIR (see Section 3.1) is used to advertise the existence and The SFIR (see Section 3.1) is used to advertise the existence and
location of a specific Service Function Instance and consists of: location of a specific Service Function Instance and consists of:
o The RT as just described. o The RT as just described.
o A Service Function Type (SFT) that is the type of service function o A Service Function Type (SFT) that is the type of service function
that is provided (such as "firewall"). that is provided (such as "firewall").
skipping to change at page 31, line 10 skipping to change at page 31, line 26
A typical policy might be to figure out the set of SFIs that are A typical policy might be to figure out the set of SFIs that are
closest, and to load balance among them. But this is not the only closest, and to load balance among them. But this is not the only
possible policy. possible policy.
Thus, at any point in time when an SFF selects its next hop, it Thus, at any point in time when an SFF selects its next hop, it
chooses from the intersection of the set of next hop RDs contained in chooses from the intersection of the set of next hop RDs contained in
the SFPR and the RDs contained in the SFF's local set of SFIRs (i.e., the SFPR and the RDs contained in the SFF's local set of SFIRs (i.e.,
according to the determination of "relevance", above). If the according to the determination of "relevance", above). If the
intersection is null, the SFPR is unusable. Similarly, when this intersection is null, the SFPR is unusable. Similarly, when this
condition applies on the controller that originated the SFPR, it condition applies on the Controller that originated the SFPR, it
SHOULD either withdraw the SFPR or re-advertise it with a new set of SHOULD either withdraw the SFPR or re-advertise it with a new set of
RDs for the affected hop. RDs for the affected hop.
6. Looping, Jumping, and Branching 6. Looping, Jumping, and Branching
As described in Section 2 an SFI or an SFF may cause a packet to As described in Section 2 an SFI or an SFF may cause a packet to
"loop back" to a previous SF on a path in order that a sequence of "loop back" to a previous SF on a path in order that a sequence of
functions may be re-executed. This is simply achieved by replacing functions may be re-executed. This is simply achieved by replacing
the SI in the NSH with a higher value instead of decreasing it as the SI in the NSH with a higher value instead of decreasing it as
would normally be the case to determine the next hop in the path. would normally be the case to determine the next hop in the path.
skipping to change at page 34, line 27 skipping to change at page 34, line 43
This issue becomes a concern where there are multiple parallel This issue becomes a concern where there are multiple parallel
instances of a service function and a determination of which one to instances of a service function and a determination of which one to
use could normally be left to the SFF as a load-balancing or local use could normally be left to the SFF as a load-balancing or local
policy choice. policy choice.
For the forward direction SFP, the concern is that the same choice of For the forward direction SFP, the concern is that the same choice of
service function is made for all packets of a flow under normal service function is made for all packets of a flow under normal
network conditions. It may be possible to guarantee that the load network conditions. It may be possible to guarantee that the load
balancing functions applied in the SFFs are stable and repeatable, balancing functions applied in the SFFs are stable and repeatable,
but a controller that constructs SFPs might not want to trust to but a Controller that constructs SFPs might not want to trust to
this. The controller can, in these cases, build a number of more this. The Controller can, in these cases, build a number of more
specific SFPs each traversing a specific instance of the stateful specific SFPs each traversing a specific instance of the stateful
SFs. In this case, the load balancing choice can be left up to the SFs. In this case, the load balancing choice can be left up to the
Classifier. Thus the Classifier selects which instance of a stateful Classifier. Thus the Classifier selects which instance of a stateful
SF is used by a particular flow by selecting the SFP that the flow SF is used by a particular flow by selecting the SFP that the flow
uses. uses.
For bidirectional SFPs where the same instance of a stateful SF must For bidirectional SFPs where the same instance of a stateful SF must
be traversed in both directions, it is not enough to leave the choice be traversed in both directions, it is not enough to leave the choice
of service function instance as a local choice even if the load of service function instance as a local choice even if the load
balancing is stable because coordination would be required between balancing is stable because coordination would be required between
skipping to change at page 35, line 20 skipping to change at page 35, line 36
Functions in such environments requires that suitable identifiers are Functions in such environments requires that suitable identifiers are
used to ensure that SFFs distinguish which SFIs can be used and which used to ensure that SFFs distinguish which SFIs can be used and which
cannot. cannot.
This problem is similar to how VPNs are supported and is solved in a This problem is similar to how VPNs are supported and is solved in a
similar way. The RT field is used to indicate a set of Service similar way. The RT field is used to indicate a set of Service
Functions from which all choices must be made. Functions from which all choices must be made.
7.4. Flow Specification for SFC Classifiers 7.4. Flow Specification for SFC Classifiers
[RFC5575] and [I-D.ietf-idr-rfc5575bis] define a set of BGP routes [I-D.ietf-idr-rfc5575bis] defines a set of BGP routes that can be
that can be used to identify the packets in a given flow using fields used to identify the packets in a given flow using fields in the
in the header of each packet, and a set of actions, encoded as header of each packet, and a set of actions, encoded as extended
extended communities, that can be used to disposition those packets. communities, that can be used to disposition those packets. This
This document enables the use of these mechanisms by SFC Classifiers document enables the use of these mechanisms by SFC Classifiers by
by defining a new action extended community called "Flow defining a new action extended community called "Flow Specification
Specification for SFC Classifiers" identified by the value TBD4. for SFC Classifiers" identified by the value TBD4. Note that
Note that implementation of this specification MUST NOT include other implementation of this section of this specification will be
action extended communities at the same time as an SFC Classifier: Controllers or Classifiers communicating with each other directly for
the inclusion of the "Flow Specification for SFC Classifiers" action the purpose of instructing the Classifier how to place packets onto
extended community along with any other action MUST be treated by an SFP. In order that the implementation of Classifiers can be kept
implementation of this specification as an error which SHOULD result simple and to avoid the confusion between the purpose of different
in the Flow Specification UPDATE message being handled as Treat-as- extended communities, a Controller MUST NOT include other action
withdraw according to [RFC7606] Section 2. extended communities at the same time as a "Flow Specification for
SFC Classifiers" extended community: a "Flow Specification for SFC
Classifiers" Traffic Filtering Action Extended Community advertised
with any other Traffic Filtering Action Extended Community MUST be
treated as malformed in line with [I-D.ietf-idr-rfc5575bis] and
result in the Flow Specification UPDATE message being handled as
treat-as-withdraw according to [RFC7606] Section 2.
To put the Flow Specification into context when multiple SFC overlays To put the Flow Specification into context when multiple SFC overlays
are present in one network, each FlowSpec update MUST be tagged with are present in one network, each FlowSpec update MUST be tagged with
the route target of the overlay or VPN network for which it is the route target of the overlay or VPN network for which it is
intended. intended.
This extended community is encoded as an 8-octet value, as shown in This extended community is encoded as an 8-octet value, as shown in
Figure 10. Figure 10.
1 2 3 1 2 3
skipping to change at page 36, line 23 skipping to change at page 36, line 34
Figure 10: The Format of the Flow Specification for SFC Classifiers Figure 10: The Format of the Flow Specification for SFC Classifiers
Extended Community Extended Community
The extended community contains the Service Path Identifier (SPI), The extended community contains the Service Path Identifier (SPI),
Service Index (SI), and Service Function Type (SFT) as defined Service Index (SI), and Service Function Type (SFT) as defined
elsewhere in this document. Thus, each action extended community elsewhere in this document. Thus, each action extended community
defines the entry point (not necessarily the first hop) into a defines the entry point (not necessarily the first hop) into a
specific service function path. This allows, for example, different specific service function path. This allows, for example, different
flows to enter the same service function path at different points. flows to enter the same service function path at different points.
Note that a given Flow Specification update according to [RFC5575] Note that according to [I-D.ietf-idr-rfc5575bis] a given Flow
and [I-D.ietf-idr-rfc5575bis] may include multiple of these action Specification update may include multiple of these action extended
extended communities, and that if a given action extended community communities. If a given action extended community does not contain
does not contain an installed SFPR with the specified {SPI, SI, SFT} an installed SFPR with the specified {SPI, SI, SFT} it MUST NOT be
it MUST NOT be used for dispositioning the packets of the specified used for dispositioning the packets of the specified flow.
flow.
The normal case of packet classification for SFC will see a packet The normal case of packet classification for SFC will see a packet
enter the SFP at its first hop. In this case the SI in the extended enter the SFP at its first hop. In this case the SI in the extended
community is superfluous and the SFT may also be unnecessary. To community is superfluous and the SFT may also be unnecessary. To
allow these cases to be handled, a special meaning is assigned to a allow these cases to be handled, a special meaning is assigned to a
Service Index of zero (not a valid value) and an SFT of zero (a Service Index of zero (not a valid value) and an SFT of zero (a
reserved value in the registry - see Section 10.5). reserved value in the registry - see Section 10.5).
o If an SFC Classifiers Extended Community is received with SI = 0 o If an SFC Classifiers Extended Community is received with SI = 0
then it means that the first hop of the SFP indicated by the SPI then it means that the first hop of the SFP indicated by the SPI
skipping to change at page 37, line 38 skipping to change at page 37, line 49
attribute [I-D.ietf-idr-tunnel-encaps], the SPI/SI Representation attribute [I-D.ietf-idr-tunnel-encaps], the SPI/SI Representation
sub-TLV of type TBD5. This sub-TLV MAY be present in each Tunnel TLV sub-TLV of type TBD5. This sub-TLV MAY be present in each Tunnel TLV
contained in a Tunnel Encapsulation attribute when the attribute is contained in a Tunnel Encapsulation attribute when the attribute is
carried by an SFIR. The value field of this sub-TLV is a two octet carried by an SFIR. The value field of this sub-TLV is a two octet
field of flags numbered counting from the the most significant bit, field of flags numbered counting from the the most significant bit,
each of which describes how the originating SFF expects to see the each of which describes how the originating SFF expects to see the
SPI/SI represented in the data plane for packets carried in the SPI/SI represented in the data plane for packets carried in the
tunnels described by the Tunnel TLV. tunnels described by the Tunnel TLV.
The following bits are defined by this document and are tracked in an The following bits are defined by this document and are tracked in an
IANA registry desribed in Section 10.10: IANA registry described in Section 10.10:
Bit TBD9: If this bit is set the NSH is to be used to carry the SPI/ Bit TBD9: If this bit is set the NSH is to be used to carry the SPI/
SI in the data plane. SI in the data plane.
Bit TBD10: If this bit is set two labels in an MPLS label stack are Bit TBD10: If this bit is set two labels in an MPLS label stack are
to be used as described in Section 7.5.1. to be used as described in Section 7.5.1.
If a given Tunnel TLV does not contain an SPI/SI Representation sub- If a given Tunnel TLV does not contain an SPI/SI Representation sub-
TLV then it MUST be processed as if such a sub-TLV is present with TLV then it MUST be processed as if such a sub-TLV is present with
Bit TBD9 set and no other bits set. That is, the absence of the sub- Bit TBD9 set and no other bits set. That is, the absence of the sub-
skipping to change at page 40, line 31 skipping to change at page 40, line 42
|192.0.2.3| |192.0.2.4| |192.0.2.3| |192.0.2.4|
--------- --------- --------- ---------
/ \ / \ / \ / \
------ ------ ------ ------ ------ ------ ------ ------
| SFI | | SFI | | SFI | | SFI | | SFI | | SFI | | SFI | | SFI |
|SFT=42| |SFT=44| |SFT=43| |SFT=44| |SFT=42| |SFT=44| |SFT=43| |SFT=44|
------ ------ ------ ------ ------ ------ ------ ------
Figure 11: Example Service Function Overlay Network Figure 11: Example Service Function Overlay Network
The SFFs advertise routes to the SFIs they support. So we see the The SFFs advertise routes to the SFIs they support. These
following SFIRs: advertisements contain Route Distinguishers that are set according to
the network operator's configuration model. In all of these IPv4
examples we use RDs of type 2 such that the available six octets are
partitioned as four octets for the IPv4 address of the advertising
SFF, and two octets that are a local index of the SFI. This scheme
is chosen purely for convenience of documentation, and an operator is
totally free to use any other scheme so long as it conforms to the
definitions of SFIR and SFPR in Section 3.1 and Section 3.2.
Thus we see the following SFIRs advertised:
RD = 192.0.2.1/1, SFT = 41 RD = 192.0.2.1/1, SFT = 41
RD = 192.0.2.1/2, SFT = 42 RD = 192.0.2.1/2, SFT = 42
RD = 192.0.2.2/1, SFT = 41 RD = 192.0.2.2/1, SFT = 41
RD = 192.0.2.2/2, SFT = 43 RD = 192.0.2.2/2, SFT = 43
RD = 192.0.2.3/7, SFT = 42 RD = 192.0.2.3/7, SFT = 42
RD = 192.0.2.3/8, SFT = 44 RD = 192.0.2.3/8, SFT = 44
RD = 192.0.2.4/5, SFT = 43 RD = 192.0.2.4/5, SFT = 43
RD = 192.0.2.4/6, SFT = 44 RD = 192.0.2.4/6, SFT = 44
skipping to change at page 55, line 45 skipping to change at page 55, line 45
|2001:db8::192:0:2:3| |2001:db8::192:0:2:4| |2001:db8::192:0:2:3| |2001:db8::192:0:2:4|
------------------- ------------------- ------------------- -------------------
/ \ / \ / \ / \
------ ------ ------ ------ ------ ------ ------ ------
| SFI | | SFI | | SFI | | SFI | | SFI | | SFI | | SFI | | SFI |
|SFT=42| |SFT=44| |SFT=43| |SFT=44| |SFT=42| |SFT=44| |SFT=43| |SFT=44|
------ ------ ------ ------ ------ ------ ------ ------
Figure 15: Example Service Function Overlay Network Figure 15: Example Service Function Overlay Network
The SFFs advertise routes to the SFIs they support. These
advertisements contain Route Distinguishers that are set according to
the network operator's configuration model. Note that in an IPv6
network, the RD is not large enough to contain the full IPv6 address
as only six octets are available so, in all of these IPv6 examples,
we use RDs of type 2 such that the available six octets are
partitioned as four octets for an IPv4 address of the advertising
SFF, and two octets that are a local index of the SFI. Furthermore,
we have chosen an IPv6 addressing scheme so that the low order four
octets of the IPv6 address match an IPv4 address of the advertising
node. This scheme is chosen purely for convenience of documentation,
and an operator is totally free to use any other scheme so long as it
conforms to the definitions of SFIR and SFPR in Section 3.1 and
Section 3.2.
Observant readers will notice that this makes the BGP advertisements
shown in these examples exactly the same as in the previous examples.
All that is different is that the advertising SFFs and Controller
have IPv6 addresses.
Thus we see the following SFIRs advertised:
The SFFs advertise routes to the SFIs they support. So we see the The SFFs advertise routes to the SFIs they support. So we see the
following SFIRs: following SFIRs:
RD = 2001:db8::192:0:2:1/1, SFT = 41 RD = 192.0.2.1/1, SFT = 41
RD = 2001:db8::192:0:2:1/2, SFT = 42 RD = 192.0.2.1/2, SFT = 42
RD = 2001:db8::192:0:2:2/1, SFT = 41 RD = 192.0.2.2/1, SFT = 41
RD = 2001:db8::192:0:2:2/2, SFT = 43 RD = 192.0.2.2/2, SFT = 43
RD = 2001:db8::192:0:2:3/7, SFT = 42 RD = 192.0.2.3/7, SFT = 42
RD = 2001:db8::192:0:2:3/8, SFT = 44 RD = 192.0.2.3/8, SFT = 44
RD = 2001:db8::192:0:2:4/5, SFT = 43 RD = 192.0.2.4/5, SFT = 43
RD = 2001:db8::192:0:2:4/6, SFT = 44 RD = 192.0.2.4/6, SFT = 44
Note that the addressing used for communicating between SFFs is taken Note that the addressing used for communicating between SFFs is taken
from the Tunnel Encapsulation attribute of the SFIR and not from the from the Tunnel Encapsulation attribute of the SFIR and not from the
SFIR-RD. SFIR-RD.
8.10.1. Example Explicit SFP With No Choices 8.10.1. Example Explicit SFP With No Choices
Consider the following SFPR similar to that in Section 8.1. Consider the following SFPR similar to that in Section 8.1.
SFP1: RD = 2001:db8::198:51:100:1/101, SPI = 15, SFP1: RD = 198.51.100.1/101, SPI = 15,
[SI = 255, SFT = 41, RD = 2001:db8::192:0:2:1/1], [SI = 255, SFT = 41, RD = 192.0.2.1/1],
[SI = 250, SFT = 43, RD = 2001:db8::192:0:2:2/2] [SI = 250, SFT = 43, RD = 192.0.2.2/2]
The Service Function Path consists of an SF of type 41 located at The Service Function Path consists of an SF of type 41 located at
SFF1 followed by an SF of type 43 located at SFF2. This path is SFF1 followed by an SF of type 43 located at SFF2. This path is
fully explicit and each SFF is offered no choice in forwarding packet fully explicit and each SFF is offered no choice in forwarding packet
along the path. along the path.
SFF1 will receive packets on the path from the Classifier and will SFF1 will receive packets on the path from the Classifier and will
identify the path from the SPI (15). The initial SI will be 255 and identify the path from the SPI (15). The initial SI will be 255 and
so SFF1 will deliver the packets to the SFI for SFT 41. so SFF1 will deliver the packets to the SFI for SFT 41.
When the packets are returned to SFF1 by the SFI the SI will be When the packets are returned to SFF1 by the SFI the SI will be
decreased to 250 for the next hop. SFF1 has no flexibility in the decreased to 250 for the next hop. SFF1 has no flexibility in the
choice of SFF to support the next hop SFI and will forward the packet choice of SFF to support the next hop SFI and will forward the packet
to SFF2 which will send the packets to the SFI that supports SFT 43 to SFF2 which will send the packets to the SFI that supports SFT 43
before forwarding the packets to their destinations. before forwarding the packets to their destinations.
8.10.2. Example SFP With Choice of SFIs 8.10.2. Example SFP With Choice of SFIs
SFP2: RD = 2001:db8::198:51:100:1/102, SPI = 16, SFP2: RD = 198.51.100.1/102, SPI = 16,
[SI = 255, SFT = 41, RD = 2001:db8::192:0:2:1/1], [SI = 255, SFT = 41, RD = 192.0.2.1/1],
[SI = 250, SFT = 43, {RD = 2001:db8::192:0:2:2/2, [SI = 250, SFT = 43, {RD = 192.0.2.2/2,
RD = 2001:db8::192:0:2:4/5 } ] RD = 192.0.2.4/5 } ]
In this example, like that in Section 8.2, the path also consists of In this example, like that in Section 8.2, the path also consists of
an SF of type 41 located at SFF1 and this is followed by an SF of an SF of type 41 located at SFF1 and this is followed by an SF of
type 43, but in this case the SI = 250 contains a choice between the type 43, but in this case the SI = 250 contains a choice between the
SFI located at SFF2 and the SFI located at SFF4. SFI located at SFF2 and the SFI located at SFF4.
SFF1 will receive packets on the path from the Classifier and will SFF1 will receive packets on the path from the Classifier and will
identify the path from the SPI (16). The initial SI will be 255 and identify the path from the SPI (16). The initial SI will be 255 and
so SFF1 will deliver the packets to the SFI for SFT 41. so SFF1 will deliver the packets to the SFI for SFT 41.
When the packets are returned to SFF1 by the SFI the SI will be When the packets are returned to SFF1 by the SFI the SI will be
decreased to 250 for the next hop. SFF1 now has a choice of next hop decreased to 250 for the next hop. SFF1 now has a choice of next hop
SFF to execute the next hop in the path. It can either forward SFF to execute the next hop in the path. It can either forward
packets to SFF2 or SFF4 to execute a function of type 43. It uses packets to SFF2 or SFF4 to execute a function of type 43. It uses
its local load balancing algorithm to make this choice. The chosen its local load balancing algorithm to make this choice. The chosen
SFF will send the packets to the SFI that supports SFT 43 before SFF will send the packets to the SFI that supports SFT 43 before
forwarding the packets to their destinations. forwarding the packets to their destinations.
8.10.3. Example SFP With Open Choice of SFIs 8.10.3. Example SFP With Open Choice of SFIs
SFP3: RD = 2001:db8::198:51:100:1/103, SPI = 17, SFP3: RD = 198.51.100.1/103, SPI = 17,
[SI = 255, SFT = 41, RD = 2001:db8::192:0:2:1/1], [SI = 255, SFT = 41, RD = 192.0.2.1/1],
[SI = 250, SFT = 44, RD = 0] [SI = 250, SFT = 44, RD = 0]
In this example, like that in Section 8.3 the path also consists of In this example, like that in Section 8.3 the path also consists of
an SF of type 41 located at SFF1 and this is followed by an SI with an SF of type 41 located at SFF1 and this is followed by an SI with
an RD of zero and SF of type 44. This means that a choice can be an RD of zero and SF of type 44. This means that a choice can be
made between any SFF that supports an SFI of type 44. made between any SFF that supports an SFI of type 44.
SFF1 will receive packets on the path from the Classifier and will SFF1 will receive packets on the path from the Classifier and will
identify the path from the SPI (17). The initial SI will be 255 and identify the path from the SPI (17). The initial SI will be 255 and
so SFF1 will deliver the packets to the SFI for SFT 41. so SFF1 will deliver the packets to the SFI for SFT 41.
skipping to change at page 58, line 4 skipping to change at page 58, line 24
When the packets are returned to SFF1 by the SFI the SI will be When the packets are returned to SFF1 by the SFI the SI will be
decreased to 250 for the next hop. SFF1 now has a free choice of decreased to 250 for the next hop. SFF1 now has a free choice of
next hop SFF to execute the next hop in the path selecting between next hop SFF to execute the next hop in the path selecting between
all SFFs that support SFs of type 44. Looking at the SFIRs it has all SFFs that support SFs of type 44. Looking at the SFIRs it has
received, SFF1 knows that SF type 44 is supported by SFF3 and SFF4. received, SFF1 knows that SF type 44 is supported by SFF3 and SFF4.
SFF1 uses its local load balancing algorithm to make this choice. SFF1 uses its local load balancing algorithm to make this choice.
The chosen SFF will send the packets to the SFI that supports SFT 44 The chosen SFF will send the packets to the SFI that supports SFT 44
before forwarding the packets to their destinations. before forwarding the packets to their destinations.
8.10.4. Example SFP With Choice of SFTs 8.10.4. Example SFP With Choice of SFTs
SFP4: RD = 2001:db8::198:51:100:1/104, SPI = 18,
[SI = 255, SFT = 41, RD = 2001:db8::192:0:2:1/1], SFP4: RD = 198.51.100.1/104, SPI = 18,
[SI = 250, {SFT = 43, RD = 2001:db8::192:0:2:2/2, [SI = 255, SFT = 41, RD = 192.0.2.1/1],
SFT = 44, RD = 2001:db8::192:0:2:3/8 } ] [SI = 250, {SFT = 43, RD = 192.0.2.2/2,
SFT = 44, RD = 192.0.2.3/8 } ]
This example, similar to that in Section 8.4 provides a choice of SF This example, similar to that in Section 8.4 provides a choice of SF
type in the second hop in the path. The SI of 250 indicates a choice type in the second hop in the path. The SI of 250 indicates a choice
between SF type 43 located through SF2 and SF type 44 located at SF3. between SF type 43 located through SF2 and SF type 44 located at SF3.
SFF1 will receive packets on the path from the Classifier and will SFF1 will receive packets on the path from the Classifier and will
identify the path from the SPI (18). The initial SI will be 255 and identify the path from the SPI (18). The initial SI will be 255 and
so SFF1 will deliver the packets to the SFI for SFT 41. so SFF1 will deliver the packets to the SFI for SFT 41.
When the packets are returned to SFF1 by the SFI the SI will be When the packets are returned to SFF1 by the SFI the SI will be
decreased to 250 for the next hop. SFF1 now has a free choice of decreased to 250 for the next hop. SFF1 now has a free choice of
next hop SFF to execute the next hop in the path selecting between next hop SFF to execute the next hop in the path selecting between
all SFF2 that support an SF of type 43 and SFF3 that supports an SF all SFFs that support an SF of type 43 and SFF3 that supports an SF
of type 44. These may be completely different functions that are to of type 44. These may be completely different functions that are to
be executed dependent on specific conditions, or may be similar be executed dependent on specific conditions, or may be similar
functions identified with different type identifiers (such as functions identified with different type identifiers (such as
firewalls from different vendors). SFF1 uses its local policy and firewalls from different vendors). SFF1 uses its local policy and
load balancing algorithm to make this choice, and may use additional load balancing algorithm to make this choice, and may use additional
information passed back from the local SFI to help inform its information passed back from the local SFI to help inform its
selection. The chosen SFF will send the packets to the SFI that selection. The chosen SFF will send the packets to the SFI that
supports the chose SFT before forwarding the packets to their supports the chose SFT before forwarding the packets to their
destinations. destinations.
skipping to change at page 58, line 49 skipping to change at page 59, line 23
Further discussion of security considerations for BGP may be found in Further discussion of security considerations for BGP may be found in
the BGP specification itself [RFC4271] and in the security analysis the BGP specification itself [RFC4271] and in the security analysis
for BGP [RFC4272]. The original discussion of the use of the TCP MD5 for BGP [RFC4272]. The original discussion of the use of the TCP MD5
signature option to protect BGP sessions is found in [RFC5925], while signature option to protect BGP sessions is found in [RFC5925], while
[RFC6952] includes an analysis of BGP keying and authentication [RFC6952] includes an analysis of BGP keying and authentication
issues. issues.
Additionally, this document depends on other documents that specify Additionally, this document depends on other documents that specify
BGP Multiprotocol Extensions and the documents that define the BGP Multiprotocol Extensions and the documents that define the
attributes that are carried by BGP UPDATEs of the SFC AFI/SAFI. attributes that are carried by BGP UPDATEs of the SFC AFI/SAFI.
Relevant additional security measures are considered in [RFC4760] and [RFC4760] observes that the use of AFI/SAFI does not change the
underlying security issues inherent in the existing BGP. Relevant
additional security measures are considered in
[I-D.ietf-idr-tunnel-encaps]. [I-D.ietf-idr-tunnel-encaps].
This document does not fundamentally change the security behavior of This document does not fundamentally change the security behavior of
BGP deployments which depend considerably on the network operator's BGP deployments, which depend considerably on the network operator's
perception of risk in their network. It may be observed that the perception of risk in their network. It may be observed that the
application of the mechanisms described in this document are scoped application of the mechanisms described in this document are scoped
to a single domain as implied by [RFC8300] noted in Section 2.1. to a single domain as implied by [RFC8300] noted in Section 2.1 of
Applicability of BGP within a single domain may enable a network this document. Applicability of BGP within a single domain may
operator to make easier and more consistent decisions about what enable a network operator to make easier and more consistent
security measures to apply, and the domain boundary, which BGP decisions about what security measures to apply, and the domain
enforces by definition, provides a safeguard that prevents leakage of boundary, which BGP enforces by definition, provides a safeguard that
SFC programming in either direction at the boundary. prevents leakage of SFC programming in either direction at the
boundary.
Service Function Chaining provides a significant attack opportunity: Service Function Chaining provides a significant attack opportunity:
packets can be diverted from their normal paths through the network, packets can be diverted from their normal paths through the network,
packets can be made to execute unexpected functions, and the packets can be made to execute unexpected functions, and the
functions that are instantiated in software can be subverted. functions that are instantiated in software can be subverted.
However, this specification does not change the existence of Service However, this specification does not change the existence of Service
Function Chaining and security issues specific to Service Function Function Chaining and security issues specific to Service Function
Chaining are covered in [RFC7665] and [RFC8300]. Chaining are covered in [RFC7665] and [RFC8300].
This document defines a control plane for Service Function Chaining. This document defines a control plane for Service Function Chaining.
skipping to change at page 59, line 41 skipping to change at page 60, line 16
security considerations in that document (Section 13) provide good security considerations in that document (Section 13) provide good
guidance for securing SFC systems reliant on this specification. Of guidance for securing SFC systems reliant on this specification. Of
particular relevance is the need to securely distinguish between particular relevance is the need to securely distinguish between
messages intended for the control of different SFC overlays which is messages intended for the control of different SFC overlays which is
similar to the need to distinguish between different VPNs. similar to the need to distinguish between different VPNs.
Section 19 of [RFC7432] also provides useful guidance on the use of Section 19 of [RFC7432] also provides useful guidance on the use of
BGP in a similar environment. BGP in a similar environment.
Note that a component of an SFC system that uses the procedures Note that a component of an SFC system that uses the procedures
described in this document also requires communications between a described in this document also requires communications between a
controller and the SFC network elements. This communication covers Controller and the SFC network elements (specifically the SFFs and
instructing the Classifiers using BGP mechanisms (see Section 7.4), Classifiers). This communication covers instructing the Classifiers
thus the use of BGP security is strongly recommended.. But it also using BGP mechanisms (see Section 7.4), thus the use of BGP security
covers other mechanisms for programming the Classifier and is strongly recommended. But it also covers other mechanisms for
instructing the SFFs and SFs (for example, to bind SFs to an SFF, and programming the Classifier and instructing the SFFs and SFs (for
to cause the establishment of tunnels between SFFs). This document example, to bind SFs to an SFF, and to cause the establishment of
does not cover these latter mechanisms and so their security is out tunnels between SFFs). This document does not cover these latter
of scope, but it should be noted that these communications provide an mechanisms and so their security is out of scope, but it should be
attack vector on the SFC system and so attention must be paid to noted that these communications provide an attack vector on the SFC
ensuring that they are secure. system and so attention must be paid to ensuring that they are
secure.
There is an intrinsic assumption in SFC systems that nodes that There is an intrinsic assumption in SFC systems that nodes that
announce support for specific SFs actually offer those functions, and announce support for specific SFs actually offer those functions, and
that SFs are not, themselves, attacked or subverted. This is that SFs are not, themselves, attacked or subverted. This is
particularly important when the SFs are implemented as software that particularly important when the SFs are implemented as software that
can be updated. Protection against this sort of concern forms part can be updated. Protection against this sort of concern forms part
of the security of any SFC system and so is outside the scope of the of the security of any SFC system and so is outside the scope of the
control plane mechanisms described in this document. control plane mechanisms described in this document.
Similarly, there is a vulnerablity if a rogue or subverted controller Similarly, there is a vulnerability if a rogue or subverted
announces SFPs especially if that controller "takes over" an existing Controller announces SFPs especially if that controller "takes over"
SFP and changes its contents. This is corresponds to a rogue BGP an existing SFP and changes its contents. This is corresponds to a
speaker entering a routing system, or even to a Route Reflector rogue BGP speaker entering a routing system, or even to a Route
becoming subverted. Protection mechanisms, as above, include Reflector becoming subverted. Protection mechanisms, as above,
securing BGP sessions and protecting software loads on the include securing BGP sessions and protecting software loads on the
controllers. controllers.
In an environment where there is concern that rogue Controllers might
be introduced to the network and inject false SFPRs or take over and
change existing SFPRs, it is RECOMMENDED that each SFF and Classifier
be configured with the identities of authorized Controllers. Thus,
the announcement of an SFPR by any other BGP peer would be rejected.
Lastly, note that Section 3.2.2 makes two operational suggestions Lastly, note that Section 3.2.2 makes two operational suggestions
that have implications for the stability and security of the that have implications for the stability and security of the
mechanisms described in this document: mechanisms described in this document:
o That modifications to active SFPs not be made. o That modifications to active SFPs not be made.
o That SPIs not be immediately re-used. o That SPIs not be immediately re-used.
10. IANA Considerations 10. IANA Considerations
skipping to change at page 63, line 4 skipping to change at page 63, line 33
Come First Served" policy [RFC8126]. Come First Served" policy [RFC8126].
o Values 64496 through 65534 are for Private Use and are not to be o Values 64496 through 65534 are for Private Use and are not to be
recorded by IANA. recorded by IANA.
This document should be given as a reference for this registry. This document should be given as a reference for this registry.
The new registry should track: The new registry should track:
o Value o Value
o Name o Name
o Reference Document or Contact o Reference Document or Contact
o Registration Date o Registration Date
The registry should initially be populated as follows: The registry should initially be populated as follows where
[I-D.darwa] should be expanded to
[I-D.dawra-idr-bgp-ls-sr-service-segments].
Value | Name | Reference | Date Value | Name | Reference | Date
------+-------------------------------+------------+--------------- ------+-------------------------+------------+---------------
0 | Reserved, not to be allocated | [This.I-D] | Date-to-be-set 0 | Reserved, not to be | [This.I-D] | Date-to-be-set
1 | Change Sequence | [This.I-D] | Date-to-be-set | allocated | |
2-31 | Unassigned | | 1 | Change Sequence | [This.I-D] | Date-to-be-set
32 | Classifier | [This.I-D] | Date-to-be-set 2-31 | Unassigned | |
33 | Firewall | [This.I-D] | Date-to-be-set 32 | Classifier | [This.I-D] | Date-to-be-set
34 | Load balancer | [This.I-D] | Date-to-be-set | | [I-D.dawra]|
35 | Deep packet inspection engine | [This.I-D] | Date-to-be-set 33 | Firewall | [This.I-D] | Date-to-be-set
36 | Penalty box | [This.I-D] | Date-to-be-set | | [I-D.dawra]|
37 | WAN accelerator | [This.I-D] | Date-to-be-set 34 | Load balancer | [This.I-D] | Date-to-be-set
38 | Application accelerator | [This.I-D] | Date-to-be-set | | [I-D.dawra]|
39 | TCP optimizer | [This.I-D] | Date-to-be-set 35 | Deep packet inspection | [This.I-D] | Date-to-be-set
40 | Network Address Translator | [This.I-D] | Date-to-be-set | engine | [I-D.dawra]|
41 | NAT44 | [This.I-D] | Date-to-be-set 36 | Penalty box | [This.I-D] | Date-to-be-set
42 | NAT64 | [This.I-D] | Date-to-be-set | | [RFC8300] |
43 | NPTv6 | [This.I-D] | Date-to-be-set 37 | WAN accelerator | [This.I-D] | Date-to-be-set
44 | Lawful intercept | [This.I-D] | Date-to-be-set | | [RFC7665] |
45 | HOST_ID injection | [This.I-D] | Date-to-be-set | | [RFC8300] |
46 | HTTP header enrichment | [This.I-D] | Date-to-be-set 38 | Application accelerator | [This.I-D] | Date-to-be-set
47 | Caching engine | [This.I-D] | Date-to-be-set | | [RFC7665] |
48- | | | 39 | TCP optimizer | [This.I-D] | Date-to-be-set
-65534|Unassigned | | | | [RFC7665] |
65535 | Reserved, not to be allocated | [This.I-D] | Date-to-be-set 40 | Network Address | [This.I-D] | Date-to-be-set
| Translator | [RFC7665] |
41 | NAT44 | [This.I-D] | Date-to-be-set
| | [RFC7665] |
| | [RFC3022] |
42 | NAT64 | [This.I-D] | Date-to-be-set
| | [RFC7665] |
| | [RFC6146] |
43 | NPTv6 | [This.I-D] | Date-to-be-set
| | [RFC7665] |
| | [RFC6296] |
44 | Lawful intercept | [This.I-D] | Date-to-be-set
| | [RFC7665] |
45 | HOST_ID injection | [This.I-D] | Date-to-be-set
| | [RFC7665] |
46 | HTTP header enrichment | [This.I-D] | Date-to-be-set
| | [RFC7665] |
47 | Caching engine | [This.I-D] | Date-to-be-set
| | [RFC7665] |
48- | | |
-65534|Unassigned | |
65535 | Reserved, not to be | |
| allocated | [This.I-D] | Date-to-be-set
10.6. New Generic Transitive Experimental Use Extended Community Sub- 10.6. New Generic Transitive Experimental Use Extended Community Sub-
Types Types
IANA maintains a registry of "Border Gateway Protocol (BGP) IANA maintains a registry of "Border Gateway Protocol (BGP)
Parameters" with a subregistry of "Generic Transitive Experimental Parameters" with a subregistry of "Generic Transitive Experimental
Use Extended Community Sub-Type". IANA is requested to assign a new Use Extended Community Sub-Type". IANA is requested to assign a new
sub-type as follows: sub-type as follows:
"Flow Specification for SFC Classifiers" (TBD4 in this document) "Flow Specification for SFC Classifiers" (TBD4 in this document)
skipping to change at page 64, line 31 skipping to change at page 65, line 42
IANA should include the following note replacing the string "TBD6" IANA should include the following note replacing the string "TBD6"
with the value assigned for Section 10.7: with the value assigned for Section 10.7:
This registry contains values of the second octet (the "Sub-Type" This registry contains values of the second octet (the "Sub-Type"
field) of an extended community when the value of the first octet field) of an extended community when the value of the first octet
(the "Type" field) is set to TBD6. (the "Type" field) is set to TBD6.
The allocation policy for this registry should be First Come First The allocation policy for this registry should be First Come First
Served. Served.
Valid values are 0 to 255. The value 0 is reserved and should not be
allocated.
IANA is requested to populate this registry with the following IANA is requested to populate this registry with the following
entries: entries:
Sub-Type | | | Sub-Type | | |
Value | Name | Reference | Date Value | Name | Reference | Date
---------+----------------------+-------------+--------------- ---------+----------------------+-------------+---------------
TBD7 | SFIR Pool Identifier | [This.I-D] | Date-to-be-set 0 | Reserved, not to be | |
TBD8 | MPLS Label Stack | [This.I-D] | Date-to-be-set | allocated | |
1 | SFIR Pool Identifier | [This.I-D] | Date-to-be-set
2 | MPLS Label Stack | [This.I-D] | Date-to-be-set
| Mixed Swapping/ | | | Mixed Swapping/ | |
| Stacking Labels | | | Stacking Labels | |
3-255 | Unassigned | |
All other values should be marked "Unassigned". All other values should be marked "Unassigned".
10.9. SPI/SI Representation 10.9. SPI/SI Representation
IANA is requested to assign a codepoint from the "BGP Tunnel IANA is requested to assign a codepoint from the "BGP Tunnel
Encapsulation Attribute Sub-TLVs" registry for the "SPI/SI Encapsulation Attribute Sub-TLVs" registry for the "SPI/SI
Representation Sub-TLV" (TBD5 in this document) with this document Representation Sub-TLV" (TBD5 in this document) with this document
being the reference. being the reference.
skipping to change at page 66, line 6 skipping to change at page 67, line 30
Thanks to Tony Przygienda, Jeff Haas, and Andy Malis for helpful Thanks to Tony Przygienda, Jeff Haas, and Andy Malis for helpful
comments, and to Joel Halpern for discussions that improved this comments, and to Joel Halpern for discussions that improved this
document. Yuanlong Jiang provided a useful review and caught some document. Yuanlong Jiang provided a useful review and caught some
important issues. Stephane Litkowski did an exceptionally good and important issues. Stephane Litkowski did an exceptionally good and
detailed document shepherd review. detailed document shepherd review.
Andy Malis contributed text that formed the basis of Section 7.7. Andy Malis contributed text that formed the basis of Section 7.7.
Brian Carpenter and Martin Vigoureux provided useful reviews during Brian Carpenter and Martin Vigoureux provided useful reviews during
IETF last call. Thanks also to Sheng Jiang, Ravi Singh, Benjamin IETF last call. Thanks also to Sheng Jiang, Med Boucadair, Ravi
Kaduk, Roman Danyliw, Adam Roach, Alvaro Retana, and Barry Leiba for Singh, Benjamin Kaduk, Roman Danyliw, Adam Roach, Alvaro Retana,
review comments. Ketan Talaulikar provided helpful discussion of the Barry Leiba, and Murray Kucherawy for review comments. Ketan
SFT code point registry. Talaulikar provided helpful discussion of the SFT code point
registry, and Ron Bonica kept us honest on the difference between an
RD and RT.
13. References 13. References
13.1. Normative References 13.1. Normative References
[I-D.ietf-idr-rfc5575bis] [I-D.ietf-idr-rfc5575bis]
Loibl, C., Hares, S., Raszuk, R., McPherson, D., and M. Loibl, C., Hares, S., Raszuk, R., McPherson, D., and M.
Bacher, "Dissemination of Flow Specification Rules", Bacher, "Dissemination of Flow Specification Rules",
draft-ietf-idr-rfc5575bis-25 (work in progress), May 2020. draft-ietf-idr-rfc5575bis-26 (work in progress), August
2020.
[I-D.ietf-idr-tunnel-encaps] [I-D.ietf-idr-tunnel-encaps]
Patel, K., Velde, G., and S. Ramachandra, "The BGP Tunnel Patel, K., Velde, G., Sangli, S., and J. Scudder, "The BGP
Encapsulation Attribute", draft-ietf-idr-tunnel-encaps-15 Tunnel Encapsulation Attribute", draft-ietf-idr-tunnel-
(work in progress), December 2019. encaps-17 (work in progress), July 2020.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Border Gateway Protocol 4 (BGP-4)", RFC 4271, Border Gateway Protocol 4 (BGP-4)", RFC 4271,
DOI 10.17487/RFC4271, January 2006, DOI 10.17487/RFC4271, January 2006,
<https://www.rfc-editor.org/info/rfc4271>. <https://www.rfc-editor.org/info/rfc4271>.
skipping to change at page 66, line 48 skipping to change at page 68, line 28
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
2006, <https://www.rfc-editor.org/info/rfc4364>. 2006, <https://www.rfc-editor.org/info/rfc4364>.
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
"Multiprotocol Extensions for BGP-4", RFC 4760, "Multiprotocol Extensions for BGP-4", RFC 4760,
DOI 10.17487/RFC4760, January 2007, DOI 10.17487/RFC4760, January 2007,
<https://www.rfc-editor.org/info/rfc4760>. <https://www.rfc-editor.org/info/rfc4760>.
[RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J.,
and D. McPherson, "Dissemination of Flow Specification
Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009,
<https://www.rfc-editor.org/info/rfc5575>.
[RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A.,
Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based
Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February
2015, <https://www.rfc-editor.org/info/rfc7432>. 2015, <https://www.rfc-editor.org/info/rfc7432>.
[RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K.
Patel, "Revised Error Handling for BGP UPDATE Messages", Patel, "Revised Error Handling for BGP UPDATE Messages",
RFC 7606, DOI 10.17487/RFC7606, August 2015, RFC 7606, DOI 10.17487/RFC7606, August 2015,
<https://www.rfc-editor.org/info/rfc7606>. <https://www.rfc-editor.org/info/rfc7606>.
skipping to change at page 68, line 10 skipping to change at page 69, line 28
DOI 10.17487/RFC8596, June 2019, DOI 10.17487/RFC8596, June 2019,
<https://www.rfc-editor.org/info/rfc8596>. <https://www.rfc-editor.org/info/rfc8596>.
13.2. Informative References 13.2. Informative References
[I-D.dawra-idr-bgp-ls-sr-service-segments] [I-D.dawra-idr-bgp-ls-sr-service-segments]
Dawra, G., Filsfils, C., Talaulikar, K., Clad, F., Dawra, G., Filsfils, C., Talaulikar, K., Clad, F.,
daniel.bernier@bell.ca, d., Uttaro, J., Decraene, B., daniel.bernier@bell.ca, d., Uttaro, J., Decraene, B.,
Elmalky, H., Xu, X., Guichard, J., and C. Li, "BGP-LS Elmalky, H., Xu, X., Guichard, J., and C. Li, "BGP-LS
Advertisement of Segment Routing Service Segments", draft- Advertisement of Segment Routing Service Segments", draft-
dawra-idr-bgp-ls-sr-service-segments-03 (work in dawra-idr-bgp-ls-sr-service-segments-04 (work in
progress), January 2020. progress), August 2020.
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network
Address Translator (Traditional NAT)", RFC 3022,
DOI 10.17487/RFC3022, January 2001,
<https://www.rfc-editor.org/info/rfc3022>.
[RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis",
RFC 4272, DOI 10.17487/RFC4272, January 2006, RFC 4272, DOI 10.17487/RFC4272, January 2006,
<https://www.rfc-editor.org/info/rfc4272>. <https://www.rfc-editor.org/info/rfc4272>.
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP
Authentication Option", RFC 5925, DOI 10.17487/RFC5925, Authentication Option", RFC 5925, DOI 10.17487/RFC5925,
June 2010, <https://www.rfc-editor.org/info/rfc5925>. June 2010, <https://www.rfc-editor.org/info/rfc5925>.
[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
NAT64: Network Address and Protocol Translation from IPv6
Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146,
April 2011, <https://www.rfc-editor.org/info/rfc6146>.
[RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix
Translation", RFC 6296, DOI 10.17487/RFC6296, June 2011,
<https://www.rfc-editor.org/info/rfc6296>.
[RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of [RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of
BGP, LDP, PCEP, and MSDP Issues According to the Keying BGP, LDP, PCEP, and MSDP Issues According to the Keying
and Authentication for Routing Protocols (KARP) Design and Authentication for Routing Protocols (KARP) Design
Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013, Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013,
<https://www.rfc-editor.org/info/rfc6952>. <https://www.rfc-editor.org/info/rfc6952>.
[RFC7498] Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for [RFC7498] Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for
Service Function Chaining", RFC 7498, Service Function Chaining", RFC 7498,
DOI 10.17487/RFC7498, April 2015, DOI 10.17487/RFC7498, April 2015,
<https://www.rfc-editor.org/info/rfc7498>. <https://www.rfc-editor.org/info/rfc7498>.
 End of changes. 62 change blocks. 
173 lines changed or deleted 271 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/