draft-ietf-bess-nsh-bgp-control-plane-10.txt   draft-ietf-bess-nsh-bgp-control-plane-11.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: October 28, 2019 E. Rosen Expires: December 1, 2019 E. Rosen
Juniper Networks Juniper Networks
J. Uttaro J. Uttaro
AT&T AT&T
L. Jalil L. Jalil
Verizon Verizon
April 26, 2019 May 30, 2019
BGP Control Plane for NSH SFC BGP Control Plane for NSH SFC
draft-ietf-bess-nsh-bgp-control-plane-10 draft-ietf-bess-nsh-bgp-control-plane-11
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 October 28, 2019. This Internet-Draft will expire on December 1, 2019.
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
skipping to change at page 3, line 13 skipping to change at page 3, line 13
7.5.1. MPLS Representation of the SPI/SI . . . . . . . . . . 35 7.5.1. MPLS Representation of the SPI/SI . . . . . . . . . . 35
7.6. MPLS Label Swapping/Stacking Operation . . . . . . . . . 35 7.6. MPLS Label Swapping/Stacking Operation . . . . . . . . . 35
7.7. Support for MPLS-Encapsulated NSH Packets . . . . . . . . 36 7.7. Support for MPLS-Encapsulated NSH Packets . . . . . . . . 36
8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 36 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 36
8.1. Example Explicit SFP With No Choices . . . . . . . . . . 38 8.1. Example Explicit SFP With No Choices . . . . . . . . . . 38
8.2. Example SFP With Choice of SFIs . . . . . . . . . . . . . 38 8.2. Example SFP With Choice of SFIs . . . . . . . . . . . . . 38
8.3. Example SFP With Open Choice of SFIs . . . . . . . . . . 39 8.3. Example SFP With Open Choice of SFIs . . . . . . . . . . 39
8.4. Example SFP With Choice of SFTs . . . . . . . . . . . . . 39 8.4. Example SFP With Choice of SFTs . . . . . . . . . . . . . 39
8.5. Example Correlated Bidirectional SFPs . . . . . . . . . . 40 8.5. Example Correlated Bidirectional SFPs . . . . . . . . . . 40
8.6. Example Correlated Asymmetrical Bidirectional SFPs . . . 40 8.6. Example Correlated Asymmetrical Bidirectional SFPs . . . 41
8.7. Example Looping in an SFP . . . . . . . . . . . . . . . . 41 8.7. Example Looping in an SFP . . . . . . . . . . . . . . . . 41
8.8. Example Branching in an SFP . . . . . . . . . . . . . . . 42 8.8. Example Branching in an SFP . . . . . . . . . . . . . . . 42
8.9. Examples of SFPs with Stateful Service Functions . . . . 42 8.9. Examples of SFPs with Stateful Service Functions . . . . 43
8.9.1. Forward and Reverse Choice Made at the SFF . . . . . 43 8.9.1. Forward and Reverse Choice Made at the SFF . . . . . 43
8.9.2. Parallel End-to-End SFPs with Shared SFF . . . . . . 44 8.9.2. Parallel End-to-End SFPs with Shared SFF . . . . . . 44
8.9.3. Parallel End-to-End SFPs with Separate SFFs . . . . . 46 8.9.3. Parallel End-to-End SFPs with Separate SFFs . . . . . 46
8.9.4. Parallel SFPs Downstream of the Choice . . . . . . . 48 8.9.4. Parallel SFPs Downstream of the Choice . . . . . . . 48
9. Security Considerations . . . . . . . . . . . . . . . . . . . 51 9. Security Considerations . . . . . . . . . . . . . . . . . . . 51
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 52 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 52
10.1. New BGP AF/SAFI . . . . . . . . . . . . . . . . . . . . 52 10.1. New BGP AF/SAFI . . . . . . . . . . . . . . . . . . . . 52
10.2. New BGP Path Attribute . . . . . . . . . . . . . . . . . 52 10.2. New BGP Path Attribute . . . . . . . . . . . . . . . . . 52
10.3. New SFP Attribute TLVs Type Registry . . . . . . . . . . 52 10.3. New SFP Attribute TLVs Type Registry . . . . . . . . . . 52
10.4. New SFP Association Type Registry . . . . . . . . . . . 53 10.4. New SFP Association Type Registry . . . . . . . . . . . 53
10.5. New Service Function Type Registry . . . . . . . . . . . 54 10.5. New Service Function Type Registry . . . . . . . . . . . 54
10.6. New Generic Transitive Experimental Use Extended 10.6. New Generic Transitive Experimental Use Extended
Community Sub-Types . . . . . . . . . . . . . . . . . . 55 Community Sub-Types . . . . . . . . . . . . . . . . . . 55
10.7. New BGP Transitive Extended Community Types . . . . . . 55 10.7. New BGP Transitive Extended Community Types . . . . . . 55
10.8. SPI/SI Representation . . . . . . . . . . . . . . . . . 55 10.8. SPI/SI Representation . . . . . . . . . . . . . . . . . 55
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 55 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 55
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 56 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 56
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 56 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 56
13.1. Normative References . . . . . . . . . . . . . . . . . . 56 13.1. Normative References . . . . . . . . . . . . . . . . . . 56
13.2. Informative References . . . . . . . . . . . . . . . . . 57 13.2. Informative References . . . . . . . . . . . . . . . . . 57
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 57 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 58
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 17, line 5 skipping to change at page 17, line 5
3. Unknown TLV type field found in SFP attribute. 3. Unknown TLV type field found in SFP attribute.
4. TLV length that suggests the TLV extends beyond the end of the 4. TLV length that suggests the TLV extends beyond the end of the
SFP attribute. SFP attribute.
5. Association TLV contains an unknown SFPR-RD. 5. Association TLV contains an unknown SFPR-RD.
6. No Hop TLV found in the SFP attribute. 6. No Hop TLV found in the SFP attribute.
7. No SFT TLV found in a Hop TLV. 7. No sub-TLV found in a Hop TLV.
8. Unknown SFIR-RD found in a Hop TLV. 8. Unknown SFIR-RD found in a Hop TLV.
o The errors listed above are treated as follows: o The errors listed above are treated as follows:
1., 2., 6., 7.: The attribute MUST be treated as malformed and 1., 2., 6., 7.: The attribute MUST be treated as malformed and
the "treat-as-withdraw" approach used as per [RFC7606]. the "treat-as-withdraw" approach used as per [RFC7606].
3.: Unknown TLVs SHOULD be ignored, and message processing SHOULD 3.: Unknown TLVs SHOULD be ignored, and message processing SHOULD
continue. continue.
4.: Treated as a malformed message and the "treat-as-withdraw" 4.: Treated as a malformed message and the "treat-as-withdraw"
approach used as per [RFC7606] approach used as per [RFC7606]
5., 8.: The absence of an RD with which to corollate is nothing 5., 8.: The absence of an RD with which to correlate is nothing
more than a soft error. The receiver SHOULD store the more than a soft error. The receiver SHOULD store the
information from the SFP attribute until a corresponding information from the SFP attribute until a corresponding
advertisement is received. An implementation MAY time-out such advertisement is received. An implementation MAY time-out such
stored SFP attributes to avoid becoming over-loaded. stored SFP attributes to avoid becoming over-loaded. The time-
out value should be configurable and measured in minutes; a
default value of 30 minutes is suggested. Whenever an
implementation removes a stored SFP attribute, it SHOULD
generate a notification to the network operator.
3.2.1.1. The Association TLV 3.2.1.1. The Association TLV
The Association TLV is an optional TLV in the SFP attribute. It MAY The Association TLV is an optional TLV in the SFP attribute. It MAY
be present multiple times. Each occurrence provides an association be present multiple times. Each occurrence provides an association
with another SFP as advertised in another SFPR. The format of the with another SFP as advertised in another SFPR. The format of the
Association TLV is shown in Figure 7 Association TLV is shown in Figure 7
+--------------------------------------------+ +--------------------------------------------+
| Type = 1 (1 octet) | | Type = 1 (1 octet) |
skipping to change at page 20, line 46 skipping to change at page 20, line 46
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 SFI 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 optionally present in the Hop TLV and is used when the TLV that is OPTIONAL in the Hop TLV and is used when the data
data representation is MPLS (see Section 7.5). When present it representation is MPLS (see Section 7.5). When present it indicates
indicates to the Classifier imposing an MPLS label stack that the to the Classifier imposing an MPLS label stack that the current hop
current hop is to use an {SFC Context Label, SF label} rather than an is to use an {SFC Context Label, SF label} rather than an {SPI, SF}
{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 labels 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.
skipping to change at page 33, line 7 skipping to change at page 33, line 7
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 Spec for SFC Classifiers 7.4. Flow Spec for SFC Classifiers
[RFC5575] defines a set of BGP routes that can be used to identify [RFC5575] and [I-D.ietf-idr-rfc5575bis] define a set of BGP routes
the packets in a given flow using fields in the header of each that can be used to identify the packets in a given flow using fields
packet, and a set of actions, encoded as extended communities, that in the header of each packet, and a set of actions, encoded as
can be used to disposition those packets. This document enables the extended communities, that can be used to disposition those packets.
use of RFC 5575 mechanisms by SFC Classifiers by defining a new This document enables the use of these mechanisms by SFC Classifiers
action extended community called "Flow Spec for SFC classifiers" by defining a new action extended community called "Flow Spec for SFC
identified by the value TBD4. Note that other action extended Classifiers" identified by the value TBD4. Note that other action
communities may also be present. extended communities MUST NOT be present at the same time: the
inclusion of the "Flow Spec for SFC Classifiers" action extended
community along with any other action MUST be treated as an error
which SHOULD result in the Flow Specification UPDATE message being
handled as Treat-as-withdraw according to [RFC7606] Section 2.
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.
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=0x80 | Sub-Type=TBD4 | SPI | | Type=0x80 | Sub-Type=TBD4 | SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SPI (cont.) | SI | SFT | | SPI (cont.) | SI | SFT |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: The Format of the Flow Spec for SFC Classifiers Extended Figure 10: The Format of the Flow Spec for SFC Classifiers Extended
Community 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 Spec update according to [RFC5575] may include Note that a given Flow Spec update according to [RFC5575] and
multiple of these action extended communities, and that if a given [I-D.ietf-idr-rfc5575bis] may include multiple of these action
action extended community does not contain an installed SFPR with the extended communities, and that if a given action extended community
specified {SPI, SI, SFT} it MUST NOT be used for dispositioning the does not contain an installed SFPR with the specified {SPI, SI, SFT}
packets of the specified flow. it MUST NOT be used for dispositioning the packets of the specified
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 34, line 20 skipping to change at page 34, line 22
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 SPFR for the indicated SPI MUST be used.
Note that each FlowSpec update MUST be tagged with the route target One of the filters that the Flow Spec may describe is the VPN to
of the overlay or VPN network for which it is intended to put the which the traffic belongs. Additionally, note that to put the
indicated SPI into context. indicated SPI into context when multiple SFC overlays 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 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
overlay network through the use of the SPI/SI which is nominally overlay network through the use of the SPI/SI which is nominally
carried in the NSH of a given packet. However, in order to handle carried in the NSH of a given packet. However, in order to handle
situations in which the NSH is not ubiquitously deployed, it is also situations in which the NSH is not ubiquitously deployed, it is also
possible to use alternative data plane representations of the SPI/SI possible to use alternative data plane representations of the SPI/SI
by carrying the identical semantics in other protocol fields such as by carrying the identical semantics in other protocol fields such as
MPLS labels [I-D.ietf-mpls-sfc]. MPLS labels [I-D.ietf-mpls-sfc].
skipping to change at page 44, line 25 skipping to change at page 44, line 25
to SFF2. This is safe, even in the case that the SFs of type 42 are to SFF2. This is safe, even in the case that the SFs of type 42 are
stateful because SFF2 is doing the load balancing in both directions stateful because SFF2 is doing the load balancing in both directions
and can apply the same algorithm to ensure that packets associated and can apply the same algorithm to ensure that packets associated
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 bidirecitonal 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 SPF 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],
skipping to change at page 52, line 15 skipping to change at page 52, line 15
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. This communication covers
instructing the Classifiers using BGP mechanisms (see Section 7.4) instructing the Classifiers using BGP mechanisms (see Section 7.4)
which is covered by BGP security. But it also covers other which is covered by BGP security. But it also covers other
mechanisms for programming the Classifier and instructing the SFFs mechanisms for programming the Classifier and instructing the SFFs
and SFs (for example, to bind SFs to an SFF, and to cause the and SFs (for example, to bind SFs to an SFF, and to cause the
estblishment of tunnels between SFFs). This document does not cover establishment of tunnels between SFFs). This document does not cover
these latter mechanisms and so their security is out of scope, but it these latter mechanisms and so their security is out of scope, but it
should be noted that these communications provide an attack vector on should be noted that these communications provide an attack vector on
the SFC system and so attention must be paid to ensuring that they the SFC system and so attention must be paid to ensuring that they
are secure. are secure.
10. IANA Considerations 10. IANA Considerations
10.1. New BGP AF/SAFI 10.1. New BGP AF/SAFI
IANA maintains a registry of "Address Family Numbers". IANA is IANA maintains a registry of "Address Family Numbers". IANA is
skipping to change at page 56, line 19 skipping to change at page 56, line 19
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.
13. References 13. References
13.1. Normative References 13.1. Normative References
[I-D.ietf-idr-rfc5575bis]
Loibl, C., Hares, S., Raszuk, R., McPherson, D., and M.
Bacher, "Dissemination of Flow Specification Rules",
draft-ietf-idr-rfc5575bis-15 (work in progress), May 2019.
[I-D.ietf-idr-tunnel-encaps] [I-D.ietf-idr-tunnel-encaps]
Rosen, E., Patel, K., and G. Velde, "The BGP Tunnel Patel, K., Velde, G., Ramachandra, S., and E. Rosen, "The
Encapsulation Attribute", draft-ietf-idr-tunnel-encaps-11 BGP Tunnel Encapsulation Attribute", draft-ietf-idr-
(work in progress), February 2019. tunnel-encaps-12 (work in progress), May 2019.
[I-D.ietf-mpls-sfc] [I-D.ietf-mpls-sfc]
Farrel, A., Bryant, S., and J. Drake, "An MPLS-Based Farrel, A., Bryant, S., and J. Drake, "An MPLS-Based
Forwarding Plane for Service Function Chaining", draft- Forwarding Plane for Service Function Chaining", draft-
ietf-mpls-sfc-07 (work in progress), March 2019. ietf-mpls-sfc-07 (work in progress), March 2019.
[I-D.ietf-mpls-sfc-encapsulation] [I-D.ietf-mpls-sfc-encapsulation]
Malis, A., Bryant, S., Halpern, J., and W. Henderickx, Malis, A., Bryant, S., Halpern, J., and W. Henderickx,
"MPLS Transport Encapsulation For The SFC NSH", draft- "MPLS Transport Encapsulation For The SFC NSH", draft-
ietf-mpls-sfc-encapsulation-04 (work in progress), March ietf-mpls-sfc-encapsulation-04 (work in progress), March
 End of changes. 19 change blocks. 
37 lines changed or deleted 53 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/