draft-ietf-bess-nsh-bgp-control-plane-12.txt   draft-ietf-bess-nsh-bgp-control-plane-13.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: February 21, 2020 E. Rosen Expires: June 15, 2020 E. Rosen
Juniper Networks Juniper Networks
J. Uttaro J. Uttaro
AT&T AT&T
L. Jalil L. Jalil
Verizon Verizon
August 20, 2019 December 13, 2019
BGP Control Plane for NSH SFC BGP Control Plane for NSH SFC
draft-ietf-bess-nsh-bgp-control-plane-12 draft-ietf-bess-nsh-bgp-control-plane-13
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 AFI/SAFI with two introduces a new BGP address family called the SFC 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
skipping to change at page 1, line 49 skipping to change at page 1, line 49
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 February 21, 2020. This Internet-Draft will expire on June 15, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 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 . . . . . . . . . . . . . . . . . 7 2.2. Control Plane Overview . . . . . . . . . . . . . . . . . 8
3. BGP SFC Routes . . . . . . . . . . . . . . . . . . . . . . . 11 3. BGP SFC Routes . . . . . . . . . . . . . . . . . . . . . . . 11
3.1. Service Function Instance Route (SFIR) . . . . . . . . . 12 3.1. Service Function Instance Route (SFIR) . . . . . . . . . 12
3.1.1. SFI Pool Identifier Extended Community . . . . . . . 13 3.1.1. SFIR Pool Identifier Extended Community . . . . . . . 13
3.1.2. MPLS Mixed Swapping/Stacking Extended Community . . . 14 3.1.2. MPLS Mixed Swapping/Stacking Extended Community . . . 14
3.2. Service Function Path Route (SFPR) . . . . . . . . . . . 14 3.2. Service Function Path Route (SFPR) . . . . . . . . . . . 14
3.2.1. The SFP Attribute . . . . . . . . . . . . . . . . . . 15 3.2.1. The SFP Attribute . . . . . . . . . . . . . . . . . . 15
3.2.2. General Rules For The SFP Attribute . . . . . . . . . 21 3.2.2. General Rules For The SFP Attribute . . . . . . . . . 21
4. Mode of Operation . . . . . . . . . . . . . . . . . . . . . . 22 4. Mode of Operation . . . . . . . . . . . . . . . . . . . . . . 22
4.1. Route Targets . . . . . . . . . . . . . . . . . . . . . . 22 4.1. Route Targets . . . . . . . . . . . . . . . . . . . . . . 22
4.2. Service Function Instance Routes . . . . . . . . . . . . 22 4.2. Service Function Instance Routes . . . . . . . . . . . . 22
4.3. Service Function Path Routes . . . . . . . . . . . . . . 22 4.3. Service Function Path Routes . . . . . . . . . . . . . . 22
4.4. Classifier Operation . . . . . . . . . . . . . . . . . . 24 4.4. Classifier Operation . . . . . . . . . . . . . . . . . . 24
4.5. Service Function Forwarder Operation . . . . . . . . . . 25 4.5. Service Function Forwarder Operation . . . . . . . . . . 25
4.5.1. Processing With 'Gaps' in the SI Sequence . . . . . . 26 4.5.1. Processing With 'Gaps' in the SI Sequence . . . . . . 26
5. Selection within Service Function Paths . . . . . . . . . . . 27 5. Selection within Service Function Paths . . . . . . . . . . . 27
6. Looping, Jumping, and Branching . . . . . . . . . . . . . . . 29 6. Looping, Jumping, and Branching . . . . . . . . . . . . . . . 29
6.1. Protocol Control of Looping, Jumping, and Branching . . . 29 6.1. Protocol Control of Looping, Jumping, and Branching . . . 30
6.2. Implications for Forwarding State . . . . . . . . . . . . 30 6.2. Implications for Forwarding State . . . . . . . . . . . . 30
7. Advanced Topics . . . . . . . . . . . . . . . . . . . . . . . 31 7. Advanced Topics . . . . . . . . . . . . . . . . . . . . . . . 31
7.1. Correlating Service Function Path Instances . . . . . . . 31 7.1. Correlating Service Function Path Instances . . . . . . . 31
7.2. Considerations for Stateful Service Functions . . . . . . 32 7.2. Considerations for Stateful Service Functions . . . . . . 32
7.3. VPN Considerations and Private Service Functions . . . . 33 7.3. VPN Considerations and Private Service Functions . . . . 33
7.4. Flow Spec for SFC Classifiers . . . . . . . . . . . . . . 33 7.4. Flow Spec for SFC Classifiers . . . . . . . . . . . . . . 33
7.5. Choice of Data Plane SPI/SI Representation . . . . . . . 34 7.5. Choice of Data Plane SPI/SI Representation . . . . . . . 34
7.5.1. MPLS Representation of the SPI/SI . . . . . . . . . . 36 7.5.1. MPLS Representation of the SPI/SI . . . . . . . . . . 36
7.6. MPLS Label Swapping/Stacking Operation . . . . . . . . . 36 7.6. MPLS Label Swapping/Stacking Operation . . . . . . . . . 36
skipping to change at page 3, line 36 skipping to change at page 3, line 36
10.4. New SFP Association Type Registry . . . . . . . . . . . 54 10.4. New SFP Association Type Registry . . . . . . . . . . . 54
10.5. New Service Function Type Registry . . . . . . . . . . . 55 10.5. New Service Function Type Registry . . . . . . . . . . . 55
10.6. New Generic Transitive Experimental Use Extended 10.6. New Generic Transitive Experimental Use Extended
Community Sub-Types . . . . . . . . . . . . . . . . . . 56 Community Sub-Types . . . . . . . . . . . . . . . . . . 56
10.7. New BGP Transitive Extended Community Types . . . . . . 56 10.7. New BGP Transitive Extended Community Types . . . . . . 56
10.8. SPI/SI Representation . . . . . . . . . . . . . . . . . 56 10.8. SPI/SI Representation . . . . . . . . . . . . . . . . . 56
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 56 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 56
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 57 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 57
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 57 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 57
13.1. Normative References . . . . . . . . . . . . . . . . . . 57 13.1. Normative References . . . . . . . . . . . . . . . . . . 57
13.2. Informative References . . . . . . . . . . . . . . . . . 58 13.2. Informative References . . . . . . . . . . . . . . . . . 59
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 59 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 59
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
skipping to change at page 4, line 40 skipping to change at page 4, line 40
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 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 to advertise the paths of "chains" of service functions, Controller (a centralized network component responsible for planning
and to give a unique designator to each such path so that they can be and coordinating Service Function Chaining within the network) to
used in conjunction with the Network Service Header [RFC8300]. 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
conjunction with the Network Service Header [RFC8300].
This document adopts the SFC architecture described in [RFC7665]. This document adopts the SFC architecture described in [RFC7665].
1.1. Requirements Language 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
skipping to change at page 7, line 30 skipping to change at page 7, line 36
o The SPI and the SI may point to an SF on a different SFP: known as o The SPI and the SI may point to an SF on a different SFP: known as
"branching" (see also Section 6). "branching" (see also Section 6).
Such modifications are limited to within the same service function Such modifications are limited to within the same service function
overlay network. That is, an SPI is known within the scope of overlay network. That is, an SPI is known within the scope of
service function overlay network. Furthermore, the new SI value is service function overlay network. Furthermore, the new SI value is
interpreted in the context of the SFP identified by the SPI. interpreted in the context of the SFP identified by the SPI.
As described in [RFC8300], an unknown or invalid SPI is treated as an As described in [RFC8300], an unknown or invalid SPI is treated as an
error and the SFF drops the packet. Such errors should be logged, error and the SFF drops the packet: such errors should be logged, and
and such logs are subject to rate limits. such logs are subject to rate limits.
An SFF receiving an SI that is unknown in the context of the SPI can Also, as described in [RFC8300], an SFF receiving an SI that is
reduce the value to the next meaningful SI value in the SFP indicated unknown in the context of the SPI can reduce the value to the next
by the SPI. If no such value exists or if the SFF does not support meaningful SI value in the SFP indicated by the SPI. If no such
this function, the SFF drops the packet and should log the event: value exists or if the SFF does not support this function, the SFF
such logs are also subject to rate limits. drops the packet and should log the event: such logs are also subject
to rate limits.
The SFF then selects an SFI that provides the SF denoted by the SPI/ The SFF then selects an SFI that provides the SF denoted by the SPI/
SI, and forwards the packet to the SFF that supports that SFI. SI, and forwards the packet to the SFF that supports that SFI.
[RFC8300] makes it clear that the intended scope is for use within a [RFC8300] makes it clear that the intended scope is for use within a
single provider's operational domain. single provider's operational domain.
This document adopts the SFC architecture described in [RFC7665] and
adds a control plane to support the functions as described in
Section 2.2. An essential component of this solution is the
Controller. This is a network component responsible for planning
SFPs within the network. It gathers information about the
availability of SFIs and SFFs, instructs the control plane about the
SFPs to be programmed, and instructs the Classifiers how to assign
traffic flows to individual SFPs.
2.2. Control Plane Overview 2.2. Control Plane Overview
To accomplish the function described in Section 2.1, this document To accomplish the function described in Section 2.1, this document
introduces the Service Function Type (SFT) that is the category of SF introduces the Service Function Type (SFT) that is the category of SF
that is supported by an SFF (such as "firewall"). An IANA registry that is supported by an SFF (such as "firewall"). An IANA registry
of Service Function Types is introduced in Section 10. An SFF may of Service Function Types is introduced in Section 10. An SFF may
support SFs of multiple different SFTs, and may support multiple SFIs support SFs of multiple different SFTs, and may support multiple SFIs
of each SF. of each SF.
This document also introduces a new BGP AFI/SAFI (values to be This document also introduces a new BGP AFI/SAFI (values to be
skipping to change at page 12, line 27 skipping to change at page 12, line 27
+--------------------------------------------+ +--------------------------------------------+
| Route Distinguisher (RD) (8 octets) | | Route Distinguisher (RD) (8 octets) |
+--------------------------------------------+ +--------------------------------------------+
| Service Function Type (2 octets) | | Service Function Type (2 octets) |
+--------------------------------------------+ +--------------------------------------------+
Figure 3: SFIR Route Type specific NLRI Figure 3: SFIR Route Type specific NLRI
Per [RFC4364] the RD field comprises a two byte Type field and a six Per [RFC4364] the RD field comprises a two byte Type field and a six
byte Value field. Two SFIs of the same SFT MUST be associated with byte Value field. If two SFIRs are originated from different
different RDs, where the association of an SFI with an RD is administrative domains, they MUST have different RDs. In particular,
determined by provisioning. If two SFIRs are originated from SFIRs from different VPNs (for different service function overlay
different administrative domains, they MUST have different RDs. In networks) MUST have different RDs, and those RDs MUST be different
particular, SFIRs from different VPNs (for different service function from any non-VPN SFIRs.
overlay networks) MUST have different RDs, and those RDs MUST be
different from any non-VPN SFIRs.
The Service Function Type identifies the functions/features of The Service Function Type identifies the functions/features of
service function can offer, e.g., classifier, firewall, load service function can offer, e.g., classifier, firewall, load
balancer, etc. There may be several SFIs that can perform a given balancer, etc. There may be several SFIs that can perform a given
Service Function. Each node hosting an SFI MUST originate an SFIR Service Function. Each node hosting an SFI MUST originate an SFIR
for each type of SF that it hosts, and it may advertise an SFIR for for each type of SF that it hosts, and it may advertise an SFIR for
each instance of each type of SF. The minimal advertisement allows each instance of each type of SF. The minimal advertisement allows
construction of valid SFPs and leaves the selection of SFIs to the construction of valid SFPs and leaves the selection of SFIs to the
local SFF; the detailed advertisement may have scaling concerns, but local SFF; the detailed advertisement may have scaling concerns, but
allows a Controller that constructs an SFP to make an explicit choice allows a Controller that constructs an SFP to make an explicit choice
of SFI. of SFI.
Note that a node may advertise all SFIs of one SFT in one shot using
normal BGP Update packing. That is, all of the SFIRs in an Update
share a common Tunnel Encapsulation and RT attribute. See also
Section 3.2.1.
The SFIR representing a given SFI will contain an NLRI with RD field The SFIR representing a given SFI will contain an NLRI with RD field
set to an RD as specified above, and with SFT field set to identify set to an RD as specified above, and with SFT field set to identify
that SFI's Service Function Type. The values for the SFT field are that SFI's Service Function Type. The values for the SFT field are
taken from a registry administered by IANA (see Section 10). A BGP taken from a registry administered by IANA (see Section 10). A BGP
Update containing one or more SFIRs MUST also include a Tunnel Update containing one or more SFIRs MUST also include a Tunnel
Encapsulation attribute [I-D.ietf-idr-tunnel-encaps]. If a data Encapsulation attribute [I-D.ietf-idr-tunnel-encaps]. If a data
packet needs to be sent to an SFI identified in one of the SFIRs, it packet needs to be sent to an SFI identified in one of the SFIRs, it
will be encapsulated as specified by the Tunnel Encapsulation will be encapsulated as specified by the Tunnel Encapsulation
attribute, and then transmitted through the underlay network. attribute, and then transmitted through the underlay network.
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. SFI Pool Identifier Extended Community 3.1.1. SFIR Pool Identifier Extended Community
This document defines a new transitive extended community of type This document defines a new transitive extended community of type
TBD6 with Sub-Type 0x00 called the SFI Pool Identifier extended TBD6 with Sub-Type 0x00 called the SFIR Pool Identifier extended
community. It MAY be included in SFIR advertisements, and is used to community. It MAY be included in SFIR advertisements, and is used to
indicate the identity of a pool of SFIRs to which an SFIR belongs. indicate the identity of a pool of SFIRs to which an SFIR belongs.
Since an SFIR may be a member of multiple pools, multiple of these Since an SFIR may be a member of multiple pools, multiple of these
extended communities may be present on a single SFIR advertisement. extended 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 SFI 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 = 0x00 (1 octet) | | Sub-Type = 0x00 (1 octet) |
+--------------------------------------------+ +--------------------------------------------+
| SFI Pool Identifier Value (6 octets) | | SFIR Pool Identifier Value (6 octets) |
+--------------------------------------------+ +--------------------------------------------+
Figure 4: The SFI Pool Identifier Extended Community Figure 4: The SFIR Pool Identifier Extended Community
The SFI 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 is a globally unique value. This means that network byte order, and is a globally unique value. This means that
pool identifiers need to be centrally managed, which is consistent pool identifiers need to be centrally managed, which is consistent
with the assignment of SFIs to pools. with the assignment of SFIs to pools.
3.1.2. MPLS Mixed Swapping/Stacking Extended Community 3.1.2. MPLS Mixed Swapping/Stacking Extended Community
This document defines a new transitive extended community of type This document defines a new transitive extended community of type
TBD7 with Sub-Type 0x00 called the MPLS Mixed Swapping/Stacking TBD7 with Sub-Type 0x00 called the MPLS Mixed Swapping/Stacking
Labels. The community is encoded as shown in Figure 5. It contains Labels. The community is encoded as shown in Figure 5. It contains
a pair of MPLS labels: an SFC Context Label and an SF Label as a pair of MPLS labels: an SFC Context Label and an SF Label as
skipping to change at page 15, line 42 skipping to change at page 15, line 42
attribute. attribute.
o The Transitive bit is set to 1 to indicate that this is a o The Transitive bit is set to 1 to indicate that this is a
transitive attribute. transitive attribute.
o The Extended Length bit is set according to the length of the SFP o The Extended Length bit is set according to the length of the SFP
attribute as defined in [RFC4271]. attribute as defined in [RFC4271].
o The Attribute Type Code is set to TBD3. o The Attribute Type Code is set to TBD3.
The content of the SFP attribute is a series of Type-Length-Variable The content of the SFP attribute is a series of Type-Length-Value
(TLV) constructs. Each TLV may include sub-TLVs. All TLVs and sub- (TLV) constructs. Each TLV may include sub-TLVs. All TLVs and sub-
TLVs have a common format that is: TLVs have a common format that is:
o Type: A single octet indicating the type of the SFP attribute TLV. o Type: A single octet indicating the type of the SFP attribute TLV.
Values are taken from the registry described in Section 10.3. Values are taken from the registry described in Section 10.3.
o Length: A two octet field indicating the length of the data o Length: A two octet field indicating the length of the data
following the Length field counted in octets. following the Length field counted in octets.
o Value: The contents of the TLV. o Value: The contents of the TLV.
skipping to change at page 19, line 26 skipping to change at page 19, line 26
The fields are as follows: The fields are as follows:
Type is set to 2 to indicate a Hop TLV. Type is set to 2 to indicate a Hop TLV.
Length indicates the length in octets of the Service Index and Hop Length indicates the length in octets of the Service Index and Hop
Details fields. Details fields.
The Service Index is defined in [RFC8300] and is the value found The Service Index is defined in [RFC8300] and is the value found
in the Service Index field of the NSH header that an SFF will use in the Service Index field of the NSH header that an SFF will use
to lookup to which next SFI a packet should be sent. to lookup to which next SFI a packet is to be sent.
The Hop Details field consists of a sequence of one or more sub- The Hop Details field consists of a sequence of one or more sub-
TLVs. TLVs.
Each hop of the SFP may demand that a specific type of SF is Each hop of the SFP may demand that a specific type of SF is
executed, and that type is indicated in sub-TLVs of the Hop TLV. At executed, and that type is indicated in sub-TLVs of the Hop TLV. At
least one sub-TLV MUST be present. This provides a list of which least one sub-TLV MUST be present. This provides a list of which
types of SF are acceptable at a specific hop, and for each type it types of SF are acceptable at a specific hop, and for each type it
allows a degree of control to be imposed on the choice of SFIs of allows a degree of control to be imposed on the choice of SFIs of
that particular type. that particular type.
skipping to change at page 20, line 26 skipping to change at page 20, line 26
The fields are as follows: The fields are as follows:
Type is set to 3 to indicate an SFT TLV. Type is set to 3 to indicate an SFT TLV.
Length indicates the length in octets of the Service Function Type Length indicates the length in octets of the Service Function Type
and SFIR-RD List fields. and SFIR-RD List fields.
The Service Function Type value indicates the category (type) of The Service Function Type value indicates the category (type) of
SF that is to be executed at this hop. The types are as SF that is to be executed at this hop. The types are as
advertised for the SFs supported by the SFFs SFT values in the advertised for the SFs supported by the SFFs. SFT values in the
range 1-31 are Special Purpose SFT values and have meanings range 1-31 are Special Purpose SFT values and have meanings
defined by the documents that describe them - the value 'Change defined by the documents that describe them - the value 'Change
Sequence' is defined in Section 6.1 of this document. Sequence' is defined in Section 6.1 of this document.
The hop description is further qualified beyond the specification The hop description is further qualified beyond the specification
of the SFTs by listing, for each SFT in each hop, the SFIs that of the SFTs by listing, for each SFT in each hop, the SFIs that
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 SFI 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 SFI 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.
3.2.1.4. MPLS Swapping/Stacking TLV 3.2.1.4. MPLS Swapping/Stacking TLV
The MPLS Swapping/Stacking TLV (Type value 4) is a zero length sub- The MPLS Swapping/Stacking TLV (Type value 4) is a zero length sub-
TLV that is OPTIONAL in the Hop TLV and is used when the data 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 sub-TLV that can be carried in the SFP Attribute and indicates length sub-TLV that can be carried in the SFP Attribute and indicates
to the Classifier and the SFFs on the SFP that an MPLS labels stack to 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 with 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 SFP. All of the SFF specified at each the SFP's hops MUST have
advertised 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.
skipping to change at page 24, line 22 skipping to change at page 24, line 22
Service Function Type in a specific hop Service Function Type in a specific hop
SI: Service Index used in the NSH to indicate a specific hop SI: Service Index used in the NSH to indicate a specific hop
SFT: The Service Function Type used in the same advertisement of SFT: The Service Function Type used in the same advertisement of
the Service Function Instance Route the Service Function Instance Route
SFIR-RD: The Route Descriptor used in an advertisement of the SFIR-RD: The Route Descriptor used in an advertisement of the
Service Function Instance Route Service Function Instance Route
That is, there can be multiple SFTs at a given hop as described in
Section 5.
Note that the values of SI are from the set {255, ..., 1} and are Note that the values of SI are from the set {255, ..., 1} and are
monotonically decreasing within the SFP. SIs MUST appear in order monotonically decreasing within the SFP. SIs MUST appear in order
within the SFPR (i.e., monotonically decreasing) and MUST NOT appear within the SFPR (i.e., monotonically decreasing) and MUST NOT appear
more than once. Gaps MAY appear in the sequence as described in more than once. Gaps MAY appear in the sequence as described in
Section 4.5.1. Malformed SFPRs MUST be discarded and MUST cause any Section 4.5.1. Malformed SFPRs MUST be discarded and MUST cause any
previous instance of the SFPR (same SFPR-RD and SPI) to be discarded. previous instance of the SFPR (same SFPR-RD and SPI) to be discarded.
Note that if the SFIR-RD list in an SFT TLV contains one or more SFI Note that if the SFIR-RD list in an SFT TLV contains one or more SFIR
Pool identifiers, then in the above expression, 'p' is the sum of the Pool identifiers, then in the above expression, 'p' is the sum of the
number of individual SFIR-RD values and the sum for each SFI Pool number of individual SFIR-RD values and the sum for each SFIR Pool
Identifier of the number of SFIRs advertised with that SFI Pool Identifier of the number of SFIRs advertised with that SFIR Pool
Identifier. I.e., the list of SFIR-RD values is effectively expanded Identifier. I.e., the list of SFIR-RD values is effectively expanded
to include the SFIR-RD of each SFIR advertised with each SFI Pool to include the SFIR-RD of each SFIR advertised with each SFIR Pool
Identifier in the SFIR-RD list. Identifier in the SFIR-RD list.
The choice of SFI is explained further in Section 5. Note that an The choice of SFI is explained further in Section 5. Note that an
SFIR-RD value of zero has special meaning as described in that SFIR-RD value of zero has special meaning as described in that
Section. Section.
4.4. Classifier Operation 4.4. Classifier Operation
As shown in Figure 1, the Classifier is a component that is used to As shown in Figure 1, the Classifier is a component that is used to
assign packets to an SFP. assign packets to an SFP.
The Classifier is responsible for determining to which packet flow a The Classifier is responsible for determining to which packet flow a
packet belongs (usually by inspecting the packet header), imposing an packet belongs. The mechanism it uses to achieve that classification
NSH, and initializing the NSH with the SPI of the selected SFP and is out of scope of this document, but might include inspection of the
the SI of its first hop. packet header. The Classifier has been instructed (by the Controller
or through some other configuration mechanism) which flows are to be
assigned to which SFPs, and so it can impose an NSH on each packet
and initialize the NSH with the SPI of the selected SFP and the SI of
its first hop.
4.5. Service Function Forwarder Operation 4.5. Service Function Forwarder Operation
Each packet sent to an SFF is transmitted encapsulated in an NSH. Each packet sent to an SFF is transmitted encapsulated in an NSH.
The NSH includes an SPI and SI: the SPI indicates the SFPR The NSH includes an SPI and SI: the SPI indicates the SFPR
advertisement that announced the Service Function Path; the tuple advertisement that announced the Service Function Path; the tuple
SPI/SI indicates a specific hop in a specific path and maps to the SPI/SI indicates a specific hop in a specific path and maps to the
RD/SFT of a particular SFIR advertisement. RD/SFT of a particular SFIR advertisement.
When an SFF gets an SFPR advertisement it will first determine When an SFF gets an SFPR advertisement it will first determine
skipping to change at page 25, line 39 skipping to change at page 25, line 44
The SFF also creates next hop forwarding state for packets received The SFF also creates next hop forwarding state for packets received
back from the local SFI that need to be forwarded to the next hop in back from the local SFI that need to be forwarded to the next hop in
the SFP. There may be a choice of next hops as described in the SFP. There may be a choice of next hops as described in
Section 4.3. The SFF could install forwarding state for all Section 4.3. The SFF could install forwarding state for all
potential next hops, or it could choose to only install forwarding potential next hops, or it could choose to only install forwarding
state to a subset of the potential next hops. If a choice is made state to a subset of the potential next hops. If a choice is made
then it will be as described in Section 5. then it will be as described in Section 5.
The installed forwarding state may change over time reacting to The installed forwarding state may change over time reacting to
changes in the underlay network and the availability of particular changes in the underlay network and the availability of particular
SFIs. SFIs. Note that the forwarding state describes how one SFF send
packets to another SFF, but not how those packets are routed through
the underlay network. SFFs may be connected by tunnels across the
underlay, or packets may be sent addressed to the next SFF and routed
through the underlay. In any case, transmission across the underlay
requires encapsulation of packets with a header for transport in the
underlay network.
Note that SFFs only create and store forwarding state for the SFPs on Note that SFFs only create and store forwarding state for the SFPs on
which they are included. They do not retain state for all SFPs which they are included. They do not retain state for all SFPs
advertised. advertised.
An SFF may also install forwarding state to support looping, jumping, An SFF may also install forwarding state to support looping, jumping,
and branching. The protocol mechanism for explicit control of and branching. The protocol mechanism for explicit control of
looping, jumping, and branching uses a specific reserved SFT value at looping, jumping, and branching uses a specific reserved SFT value at
a given hop of an SFPR and is described in Section 6.1. a given hop of an SFPR and is described in Section 6.1.
skipping to change at page 27, line 9 skipping to change at page 27, line 19
local SFI to deliver the packet. local SFI to deliver the packet.
o If the SI does not match an entry in the SFP, the SFF MUST reduce o If the SI does not match an entry in the SFP, the SFF MUST reduce
the SI value to the next (smaller) value present in the SFP and the SI value to the next (smaller) value present in the SFP and
process the packet using that SI. process the packet using that SI.
o If there is no smaller SI (i.e., if the end of the SFP has been o If there is no smaller SI (i.e., if the end of the SFP has been
reached) the SFF MUST treat the SI value as invalid as described reached) the SFF MUST treat the SI value as invalid as described
in [RFC8300]. in [RFC8300].
This makes the bevahior described in this document a superset of the
function in [RFC8300]. That is, an implementation that strictly
follows RFC 8300 in performing SI decrements in units of one, is
perfectly in line with the mechanisms defined in this document.
SFF implementations MAY choose to only support contiguous SI values SFF implementations MAY choose to only support contiguous SI values
in an SFP. Such an implementation will not support receiving an SI in an SFP. Such an implementation will not support receiving an SI
value that is not present in the SFP and will discard the packets as value that is not present in the SFP and will discard the packets as
described in [RFC8300]. described in [RFC8300].
5. Selection within Service Function Paths 5. Selection within Service Function Paths
As described in Section 2 the SPI/SI in the NSH passed back from an As described in Section 2 the SPI/SI in the NSH passed back from an
SFI to the SFF may leave the SFF with a choice of next hop SFTs, and SFI to the SFF may leave the SFF with a choice of next hop SFTs, and
a choice of SFIs for each SFT. That is, the SPI indicates an SFPR, a choice of SFIs for each SFT. That is, the SPI indicates an SFPR,
skipping to change at page 29, line 6 skipping to change at page 29, line 22
local policy. local policy.
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 its local set of SFIRs. If the the SFPR and the RDs contained in its local set of SFIRs. If the
intersection is null, the SFPR is unusable. Similarly, when this intersection is null, the SFPR is unusable. Similarly, when this
condition obtains the originator of the SFPR should either withdraw condition obtains the originator of the SFPR SHOULD either withdraw
the SFPR or re-advertise it with a new set of RDs for the affected the SFPR or re-advertise it with a new set of RDs for the affected
hop. 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 29, line 30 skipping to change at page 29, line 46
in the SFP. This is simply achieved by replacing the SI in the NSH in the SFP. This is simply achieved by replacing the SI in the NSH
with a lower value than would be achieved by decreasing it by the with a lower value than would be achieved by decreasing it by the
normal amount. normal amount.
A more complex option to move packets from one SFP to another is A more complex option to move packets from one SFP to another is
described in [RFC8300] and Section 2 where it is termed "branching". described in [RFC8300] and Section 2 where it is termed "branching".
This mechanism allows an SFI or SFF to make a choice of downstream This mechanism allows an SFI or SFF to make a choice of downstream
treatments for packets based on local policy and output of the local treatments for packets based on local policy and output of the local
SF. Branching is achieved by changing the SPI in the NSH to indicate SF. Branching is achieved by changing the SPI in the NSH to indicate
the new path and setting the SI to indicate the point in the path at the new path and setting the SI to indicate the point in the path at
which the packets should enter. which the packets enter.
Note that the NSH does not include a marker to indicate whether a Note that the NSH does not include a marker to indicate whether a
specific packet has been around a loop before. Therefore, the use of specific packet has been around a loop before. Therefore, the use of
NSH metadata may be required in order to prevent infinite loops. NSH metadata may be required in order to prevent infinite loops.
6.1. Protocol Control of Looping, Jumping, and Branching 6.1. Protocol Control of Looping, Jumping, and Branching
If the SFT value in an SFT TLV in an SFPR has the Special Purpose SFT If the SFT value in an SFT TLV in an SFPR has the Special Purpose SFT
value "Change Sequence" (see Section 10) then this is an indication value "Change Sequence" (see Section 10) then this is an indication
that the SFF may make a loop, jump, or branch according to local that the SFF may make a loop, jump, or branch according to local
skipping to change at page 31, line 25 skipping to change at page 31, line 36
contain a direction indicator, so each direction must use a different contain a direction indicator, so each direction must use a different
SPI. SPI.
As described in Section 3.2.1.1 an SFPR can contain one or more As described in Section 3.2.1.1 an SFPR can contain one or more
correlators encoded in Association TLVs. If the Association Type correlators encoded in Association TLVs. If the Association Type
indicates "Bidirectional SFP" then the SFP advertised in the SFPR is indicates "Bidirectional SFP" then the SFP advertised in the SFPR is
one direction of a bidirectional pair of SFPs where the other in the one direction of a bidirectional pair of SFPs where the other in the
pair is advertised in the SFPR with RD as carried in the Associated pair is advertised in the SFPR with RD as carried in the Associated
SFPR-RD field of the Association TLV. The SPI carried in the SFPR-RD field of the Association TLV. The SPI carried in the
Associated SPI field of the Association TLV provides a cross-check Associated SPI field of the Association TLV provides a cross-check
and should match the SPI advertised in the SFPR with RD as carried in against the SPI advertised in the SFPR with RD as carried in the
the Associated SFPR-RD field of the Association TLV. Associated SFPR-RD field of the Association TLV.
As noted in Section 3.2.1.1 SFPRs reference each other one SFPR As noted in Section 3.2.1.1 SFPRs reference each other one SFPR
advertisement will be received before the other. Therefore advertisement will be received before the other. Therefore
processing of an association will require that the first SFPR is not processing of an association will require that the first SFPR is not
rejected simply because the Associated SFPR-RD it carries is unknown. rejected simply because the Associated SFPR-RD it carries is unknown.
However, the SFP defined by the first SFPR is valid and SHOULD be However, the SFP defined by the first SFPR is valid and SHOULD be
available for use as a unidirectional SFP even in the absence of an available for use as a unidirectional SFP even in the absence of an
advertisement of its partner. advertisement of its partner.
Furthermore, in error cases where SFPR-a associates with SFPR-b, but Furthermore, in error cases where SFPR-a associates with SFPR-b, but
skipping to change at page 34, line 34 skipping to change at page 34, line 39
o If an SFC Classifiers Extended Community is received with SFT = 0 o If an SFC Classifiers Extended Community is received with SFT = 0
then there are two sub-cases: then there are two sub-cases:
* If there is a choice of SFT in the hop indicated by the value * If there is a choice of SFT in the hop indicated by the value
of the SI (including SI = 0) then SFT = 0 means there is a free of the SI (including SI = 0) then SFT = 0 means there is a free
choice according to local policy of which SFT to use). choice according to local policy of which SFT to use).
* If there is no choice of SFT in the hop indicated by the value * If there is no choice of SFT in the hop indicated by the value
of SI, then SFT = 0 means that the value of the SFT at that hop of SI, then SFT = 0 means that the value of the SFT at that hop
as indicated in the SPFR for the indicated SPI MUST be used. as indicated in the SFPR for the indicated SPI MUST be used.
One of the filters that the Flow Spec may describe is the VPN to One of the filters that the Flow Spec may describe is the VPN to
which the traffic belongs. Additionally, note that to put the which the traffic belongs. Additionally, note that to put the
indicated SPI into context when multiple SFC overlays are present in indicated SPI into context when multiple SFC overlays are present in
one network, each FlowSpec update MUST be tagged with the route one network, each FlowSpec update MUST be tagged with the route
target of the overlay or VPN network for which it is intended. target of the overlay or VPN network for which it is intended.
7.5. Choice of Data Plane SPI/SI Representation 7.5. Choice of Data Plane SPI/SI Representation
This document ties together the control and data planes of an SFC This document ties together the control and data planes of an SFC
skipping to change at page 45, line 28 skipping to change at page 45, line 28
with the same flow use the same SFI regardless of the direction of with the same flow use the same SFI regardless of the direction of
travel. travel.
How an SFF knows that an attached SFI is stateful is is out of scope How an SFF knows that an attached SFI is stateful is is out of scope
of this document. It is assumed that this will form part of the of this document. It is assumed that this will form part of the
process by which SFIs are registered as local to SFFs. Section 7.2 process by which SFIs are registered as local to SFFs. Section 7.2
provides additional observations about the coordination of the use of provides additional observations about the coordination of the use of
stateful SFIs in the case of bidirectional SFPs. stateful SFIs in the case of bidirectional SFPs.
In general, the problems of load balancing and the selection of the In general, the problems of load balancing and the selection of the
same SFIs in both directions of a bidirectional SPF can be addressed same SFIs in both directions of a bidirectional SFP can be addressed
by using sufficiently precisely specified SFPs (specifying the exact by using sufficiently precisely specified SFPs (specifying the exact
SFIs to use) and suitable programming of the Classifiers at each end SFIs to use) and suitable programming of the Classifiers at each end
of the SFPs to make sure that the matching pair of SFPs are used. of the SFPs to make sure that the matching pair of SFPs are used.
SFP13: RD = 198.51.100.1:113, SPI = 27, SFP13: RD = 198.51.100.1:113, SPI = 27,
Assoc-Type = 1, Assoc-RD = 198.51.100.1:112, Assoc-SPI = 26, Assoc-Type = 1, Assoc-RD = 198.51.100.1:112, Assoc-SPI = 26,
[SI = 255, SFT = 43, RD = 192.0.2.3:11], [SI = 255, SFT = 43, RD = 192.0.2.3:11],
[SI = 254, SFT = 42, {RD = 192.0.2.2:11, [SI = 254, SFT = 42, {RD = 192.0.2.2:11,
192.0.2.2:12, 192.0.2.2:12,
192.0.2.2:13 }], 192.0.2.2:13 }],
skipping to change at page 54, line 5 skipping to change at page 54, line 5
IANA maintains a registry of "Border Gateway Protocol (BGP) IANA maintains a registry of "Border Gateway Protocol (BGP)
Parameters". IANA is request to create a new subregistry called the Parameters". IANA is request to create a new subregistry called the
"SFP Attribute TLVs" registry. "SFP Attribute TLVs" registry.
Valid values are in the range 0 to 65535. Valid values are in the range 0 to 65535.
o Values 0 and 65535 are to be marked "Reserved, not to be o Values 0 and 65535 are to be marked "Reserved, not to be
allocated". allocated".
o Values 1 through 65524 are to be assigned according to the "First o Values 1 through 65534 are to be assigned according to the "First
Come First Served" policy [RFC8126]. Come First Served" policy [RFC8126].
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 Type o Type
o Name o Name
skipping to change at page 54, line 41 skipping to change at page 54, line 41
IANA maintains a registry of "Border Gateway Protocol (BGP) IANA maintains a registry of "Border Gateway Protocol (BGP)
Parameters". IANA is request to create a new subregistry called the Parameters". IANA is request to create a new subregistry called the
"SFP Association Type" registry. "SFP Association Type" registry.
Valid values are in the range 0 to 65535. Valid values are in the range 0 to 65535.
o Values 0 and 65535 are to be marked "Reserved, not to be o Values 0 and 65535 are to be marked "Reserved, not to be
allocated". allocated".
o Values 1 through 65524 are to be assigned according to the "First o Values 1 through 65534 are to be assigned according to the "First
Come First Served" policy [RFC8126]. Come First Served" policy [RFC8126].
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 Association Type o Association Type
o Name o Name
o Reference Document or Contact o Reference Document or Contact
skipping to change at page 56, line 22 skipping to change at page 56, line 22
"Flow Spec for SFC Classifiers" (TBD4 in this document) with this "Flow Spec for SFC Classifiers" (TBD4 in this document) with this
document as the reference. document as the reference.
10.7. New BGP Transitive Extended Community Types 10.7. New BGP Transitive Extended Community Types
IANA maintains a registry of "Border Gateway Protocol (BGP) IANA maintains a registry of "Border Gateway Protocol (BGP)
Parameters" with a subregistry of "BGP Transitive Extended Community Parameters" with a subregistry of "BGP Transitive Extended Community
Types". IANA is requested to assign new types as follows: Types". IANA is requested to assign new types as follows:
"SFI Pool Identifier" (TBD6 in this document) with this document "SFIR Pool Identifier" (TBD6 in this document) with this document
as the reference. as the reference.
"MPLS Label Stack Mixed Swapping/Stacking Labels" (TBD7 in this "MPLS Label Stack Mixed Swapping/Stacking Labels" (TBD7 in this
document) with this document as the reference. document) with this document as the reference.
10.8. SPI/SI Representation 10.8. 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
skipping to change at page 57, line 15 skipping to change at page 57, line 15
12. Acknowledgements 12. Acknowledgements
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
IETF last call.
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-17 (work in progress), June draft-ietf-idr-rfc5575bis-18 (work in progress), November
2019. 2019.
[I-D.ietf-idr-tunnel-encaps] [I-D.ietf-idr-tunnel-encaps]
Patel, K., Velde, G., Ramachandra, S., and E. Rosen, "The Patel, K., Velde, G., and S. Ramachandra, "The BGP Tunnel
BGP Tunnel Encapsulation Attribute", draft-ietf-idr- Encapsulation Attribute", draft-ietf-idr-tunnel-encaps-15
tunnel-encaps-13 (work in progress), July 2019. (work in progress), December 2019.
[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>.
 End of changes. 45 change blocks. 
59 lines changed or deleted 95 lines changed or added

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