draft-ietf-bess-nsh-bgp-control-plane-04.txt   draft-ietf-bess-nsh-bgp-control-plane-05.txt 
BESS Working Group A. Farrel BESS Working Group A. Farrel
Internet-Draft J. Drake Internet-Draft Old Dog Consulting
Intended status: Standards Track E. Rosen Intended status: Standards Track J. Drake
Expires: January 2, 2019 Juniper Networks Expires: July 16, 2019 E. Rosen
Juniper Networks
J. Uttaro J. Uttaro
AT&T AT&T
L. Jalil L. Jalil
Verizon Verizon
July 1, 2018 January 12, 2019
BGP Control Plane for NSH SFC BGP Control Plane for NSH SFC
draft-ietf-bess-nsh-bgp-control-plane-04 draft-ietf-bess-nsh-bgp-control-plane-05
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 47 skipping to change at page 1, line 48
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 January 2, 2019. This Internet-Draft will expire on July 15, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 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
skipping to change at page 2, line 34 skipping to change at page 2, line 34
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Functional Overview . . . . . . . . . . . . . . . . . . . 5 2.1. Functional Overview . . . . . . . . . . . . . . . . . . . 5
2.2. Control Plane Overview . . . . . . . . . . . . . . . . . 7 2.2. Control Plane Overview . . . . . . . . . . . . . . . . . 7
3. BGP SFC Routes . . . . . . . . . . . . . . . . . . . . . . . 9 3. BGP SFC Routes . . . . . . . . . . . . . . . . . . . . . . . 9
3.1. Service Function Instance Route (SFIR) . . . . . . . . . 10 3.1. Service Function Instance Route (SFIR) . . . . . . . . . 10
3.1.1. SFI Pool Identifier Extended Community . . . . . . . 11 3.1.1. SFI Pool Identifier Extended Community . . . . . . . 11
3.1.2. MPLS Mixed Swapping/Stacking Extended Community . . . 12 3.1.2. MPLS Mixed Swapping/Stacking Extended Community . . . 12
3.2. Service Function Path Route (SFPR) . . . . . . . . . . . 13 3.2. Service Function Path Route (SFPR) . . . . . . . . . . . 13
3.2.1. The SFP Attribute . . . . . . . . . . . . . . . . . . 13 3.2.1. The SFP Attribute . . . . . . . . . . . . . . . . . . 13
3.2.2. General Rules For The SFP Attribute . . . . . . . . . 19 3.2.2. General Rules For The SFP Attribute . . . . . . . . . 18
4. Mode of Operation . . . . . . . . . . . . . . . . . . . . . . 20 4. Mode of Operation . . . . . . . . . . . . . . . . . . . . . . 19
4.1. Route Targets . . . . . . . . . . . . . . . . . . . . . . 20 4.1. Route Targets . . . . . . . . . . . . . . . . . . . . . . 19
4.2. Service Function Instance Routes . . . . . . . . . . . . 20 4.2. Service Function Instance Routes . . . . . . . . . . . . 19
4.3. Service Function Path Routes . . . . . . . . . . . . . . 21 4.3. Service Function Path Routes . . . . . . . . . . . . . . 20
4.4. Classifier Operation . . . . . . . . . . . . . . . . . . 23 4.4. Classifier Operation . . . . . . . . . . . . . . . . . . 22
4.5. Service Function Forwarder Operation . . . . . . . . . . 23 4.5. Service Function Forwarder Operation . . . . . . . . . . 22
4.5.1. Processing With 'Gaps' in the SI Sequence . . . . . . 24 4.5.1. Processing With 'Gaps' in the SI Sequence . . . . . . 23
5. Selection in Service Function Paths . . . . . . . . . . . . . 25 5. Selection in Service Function Paths . . . . . . . . . . . . . 24
6. Looping, Jumping, and Branching . . . . . . . . . . . . . . . 27 6. Looping, Jumping, and Branching . . . . . . . . . . . . . . . 26
6.1. Protocol Control of Looping, Jumping, and Branching . . . 27 6.1. Protocol Control of Looping, Jumping, and Branching . . . 26
6.2. Implications for Forwarding State . . . . . . . . . . . . 28 6.2. Implications for Forwarding State . . . . . . . . . . . . 27
7. Advanced Topics . . . . . . . . . . . . . . . . . . . . . . . 29 7. Advanced Topics . . . . . . . . . . . . . . . . . . . . . . . 28
7.1. Preserving Entropy . . . . . . . . . . . . . . . . . . . 29 7.1. Preserving Entropy . . . . . . . . . . . . . . . . . . . 28
7.2. Correlating Service Function Path Instances . . . . . . . 29 7.2. Correlating Service Function Path Instances . . . . . . . 28
7.3. Considerations for Stateful Service Functions . . . . . . 30 7.3. Considerations for Stateful Service Functions . . . . . . 29
7.4. VPN Considerations and Private Service Functions . . . . 31 7.4. VPN Considerations and Private Service Functions . . . . 30
7.5. Flow Spec for SFC Classifiers . . . . . . . . . . . . . . 31 7.5. Flow Spec for SFC Classifiers . . . . . . . . . . . . . . 30
7.6. Choice of Data Plane SPI/SI Representation . . . . . . . 33 7.6. Choice of Data Plane SPI/SI Representation . . . . . . . 32
7.6.1. MPLS Representation of the SPI/SI . . . . . . . . . . 34 7.6.1. MPLS Representation of the SPI/SI . . . . . . . . . . 33
7.7. MPLS Label Swapping/Stacking Operation . . . . . . . . . 34 7.7. MPLS Label Swapping/Stacking Operation . . . . . . . . . 33
8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 34 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 33
8.1. Example Explicit SFP With No Choices . . . . . . . . . . 36 8.1. Example Explicit SFP With No Choices . . . . . . . . . . 35
8.2. Example SFP With Choice of SFIs . . . . . . . . . . . . . 36 8.2. Example SFP With Choice of SFIs . . . . . . . . . . . . . 35
8.3. Example SFP With Open Choice of SFIs . . . . . . . . . . 37 8.3. Example SFP With Open Choice of SFIs . . . . . . . . . . 36
8.4. Example SFP With Choice of SFTs . . . . . . . . . . . . . 38 8.4. Example SFP With Choice of SFTs . . . . . . . . . . . . . 37
8.5. Example Correlated Bidirectional SFPs . . . . . . . . . . 38 8.5. Example Correlated Bidirectional SFPs . . . . . . . . . . 37
8.6. Example Correlated Asymmetrical Bidirectional SFPs . . . 39 8.6. Example Correlated Asymmetrical Bidirectional SFPs . . . 38
8.7. Example Looping in an SFP . . . . . . . . . . . . . . . . 39 8.7. Example Looping in an SFP . . . . . . . . . . . . . . . . 38
8.8. Example Branching in an SFP . . . . . . . . . . . . . . . 40 8.8. Example Branching in an SFP . . . . . . . . . . . . . . . 39
8.9. Examples of SFPs with Stateful Service Functions . . . . 41 8.9. Examples of SFPs with Stateful Service Functions . . . . 40
8.9.1. Forward and Reverse Choice Made at the SFF . . . . . 41 8.9.1. Forward and Reverse Choice Made at the SFF . . . . . 40
8.9.2. Parallel End-to-End SFPs with Shared SFF . . . . . . 42 8.9.2. Parallel End-to-End SFPs with Shared SFF . . . . . . 41
8.9.3. Parallel End-to-End SFPs with Separate SFFs . . . . . 43 8.9.3. Parallel End-to-End SFPs with Separate SFFs . . . . . 42
8.9.4. Parallel SFPs Downstream of the Choice . . . . . . . 45 8.9.4. Parallel SFPs Downstream of the Choice . . . . . . . 44
9. Security Considerations . . . . . . . . . . . . . . . . . . . 48 9. Security Considerations . . . . . . . . . . . . . . . . . . . 47
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48
10.1. New BGP AF/SAFI . . . . . . . . . . . . . . . . . . . . 49 10.1. New BGP AF/SAFI . . . . . . . . . . . . . . . . . . . . 48
10.2. New BGP Path Attribute . . . . . . . . . . . . . . . . . 49 10.2. New BGP Path Attribute . . . . . . . . . . . . . . . . . 48
10.3. New SFP Attribute TLVs Type Registry . . . . . . . . . . 49 10.3. New SFP Attribute TLVs Type Registry . . . . . . . . . . 48
10.4. New SFP Association Type Registry . . . . . . . . . . . 50 10.4. New SFP Association Type Registry . . . . . . . . . . . 49
10.5. New Service Function Type Registry . . . . . . . . . . . 51 10.5. New Service Function Type Registry . . . . . . . . . . . 49
10.6. New Generic Transitive Experimental Use Extended 10.6. New Generic Transitive Experimental Use Extended
Community Sub-Types . . . . . . . . . . . . . . . . . . 51 Community Sub-Types . . . . . . . . . . . . . . . . . . 50
10.7. New BGP Transitive Extended Community Types . . . . . . 52 10.7. New BGP Transitive Extended Community Types . . . . . . 50
10.8. SPI/SI Representation . . . . . . . . . . . . . . . . . 52 10.8. SPI/SI Representation . . . . . . . . . . . . . . . . . 51
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 52 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 51
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 52 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 51
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 53 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 51
13.1. Normative References . . . . . . . . . . . . . . . . . . 53 13.1. Normative References . . . . . . . . . . . . . . . . . . 51
13.2. Informative References . . . . . . . . . . . . . . . . . 54 13.2. Informative References . . . . . . . . . . . . . . . . . 52
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 54 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 53
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., classifiers, firewalls, TCP accelerators, and server load (e.g., classifiers, firewalls, TCP accelerators, and server load
balancers) in a specified order: this is termed "Service Function balancers) in a specified order: this is termed "Service Function
Chaining" (SFC). There are a number of issues associated with Chaining" (SFC). There are a number of issues associated with
deploying and maintaining service function chaining in production deploying and maintaining service function chaining in production
networks, which are described below. networks, which are described below.
skipping to change at page 11, line 25 skipping to change at page 11, line 25
different RDs, where the association of an SFI with an RD is different RDs, where the association of an SFI with an RD is
determined by provisioning. If two SFIRs are originated from determined by provisioning. If two SFIRs are originated from
different administrative domains, they must have different RDs. In different administrative domains, they must have different RDs. In
particular, SFIRs from different VPNs (for different service function particular, SFIRs from different VPNs (for different service function
overlay networks) must have different RDs, and those RDs must be overlay networks) must have different RDs, and those RDs must be
different from any non-VPN SFIRs. different from any non-VPN SFIRs.
The Service Function Type identifies a service function, e.g., The Service Function Type identifies a service function, e.g.,
classifier, firewall, load balancer, etc. There may be several SFIs classifier, firewall, load balancer, etc. There may be several SFIs
that can perform a given Service Function. Each node hosting an SFI that can perform a given Service Function. Each node hosting an SFI
must originate an SFIR for each SFI that it hosts. The SFIR must originate an SFIR for each type of SF that it hosts, and it may
advertize an SFIR for each instance of each type of SF. The SFIR
representing a given SFI will contain an NLRI with RD field set to an 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 that SFI's RD as specified above, and with SFT field set to identify that SFI's
Service Function Type. The values for the SFT field are taken from a Service Function Type. The values for the SFT field are taken from a
registry administered by IANA (see Section 10). A BGP Update registry administered by IANA (see Section 10). A BGP Update
containing one or more SFIRs will also include a Tunnel Encapsulation containing one or more SFIRs will also include a Tunnel Encapsulation
attribute [I-D.ietf-idr-tunnel-encaps]. If a data packet needs to be 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 will be sent to an SFI identified in one of the SFIRs, it will be
encapsulated as specified by the Tunnel Encapsulation attribute, and encapsulated as specified by the Tunnel Encapsulation attribute, and
then transmitted through the underlay network. then transmitted through the underlay network.
3.1.1. SFI Pool Identifier Extended Community 3.1.1. SFI Pool Identifier Extended Community
This document defines a new transitive extended community with Sub- This document defines a new transitive extended community of type
Type TBD6 called the SFI Pool Identifier extended community. It can TBD6 with Sub-Type 0x00 called the SFI Pool Identifier extended
be included in SFIR advertisements, and is used to indicate the community. It can be included in SFIR advertisements, and is used to
identity of a pool of SFIRs to which an SFIR belongs. Since an SFIR indicate the identity of a pool of SFIRs to which an SFIR belongs.
may be a member of multiple pools, multiple of these extended Since an SFIR may be a member of multiple pools, multiple of these
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. include control plane scalability and stability.
The SFI Pool Identifier extended community is encoded in 8 octets as The SFI Pool Identifier extended community is encoded in 8 octets as
shown in Figure 4. shown in Figure 4.
+--------------------------------------------+ +--------------------------------------------+
| Type = 0x80 (1 octet) | | Type = 0x80 (1 octet) |
+--------------------------------------------+ +--------------------------------------------+
| Sub-Type = TBD6 (1 octet) | | Sub-Type = TBD6 (1 octet) |
+--------------------------------------------+ +--------------------------------------------+
| SFI Pool Identifier (6 octets) | | SFI Pool Identifier Value (6 octets) |
+--------------------------------------------+ +--------------------------------------------+
Figure 4: The SFI Pool Identifier Extended Community Figure 4: The SFI Pool Identifier Extended Community
The SFI Pool Identifier is encoded in a 6 octet field in network The SFI Pool Identifier Value is encoded in a 6 octet field in
byte order and is a globally unique value. network byte order, and is a globally unique value.
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 with Sub- This document defines a new transitive extended community of type
Type TBD7 called the MPLS Mixed Swapping/Stacking Labels. The TBD7 with Sub-Type 0x00 called the MPLS Mixed Swapping/Stacking
community is encoded as shown in Figure 5. It contains a pair of Labels. The community is encoded as shown in Figure 5. It contains
MPLS labels: an SFC Context Label and an SF Label as described in a pair of MPLS labels: an SFC Context Label and an SF Label as
[I-D.ietf-mpls-sfc]. Each label is 20 bits encoded in a 3-octet (24 described in [I-D.ietf-mpls-sfc]. Each label is 20 bits encoded in a
bit) field with 4 trailing bits that MUST be set to zero. 3-octet (24 bit) field with 4 trailing bits that MUST be set to zero.
+--------------------------------------------+ +--------------------------------------------+
| Type = 0x80 (1 octet) | | Type = 0x80 (1 octet) |
+--------------------------------------------| +--------------------------------------------|
| Sub-Type = TBD7 (1 octet) | | Sub-Type = TBD7 (1 octet) |
+--------------------------------------------| +--------------------------------------------|
| SFC Context Label (3 octets) | | SFC Context Label (3 octets) |
+--------------------------------------------| +--------------------------------------------|
| SF Label (3 octets) | | SF Label (3 octets) |
+--------------------------------------------+ +--------------------------------------------+
skipping to change at page 15, line 36 skipping to change at page 15, line 36
values are tracked in an IANA registry (see Section 10.4). Only values are tracked in an IANA registry (see Section 10.4). Only
one value is defined in this document: type 1 indicates one value is defined in this document: type 1 indicates
association of two unidirectional SFPs to form a bidirectional association of two unidirectional SFPs to form a bidirectional
SFP. An SFP attribute SHOULD NOT contain more than one SFP. An SFP attribute SHOULD NOT contain more than one
Association TLV with Association Type 1: if more than one is Association TLV with Association Type 1: if more than one is
present, the first one MUST be processed and subsequent instances present, the first one MUST be processed and subsequent instances
MUST be ignored. Note that documents that define new Association MUST be ignored. Note that documents that define new Association
Types must also define the presence rules for Association TLVs of Types must also define the presence rules for Association TLVs of
the new type. the new type.
The Associated SFPR-RD contains the RD of some other SFPR The Associated SFPR-RD contains the RD of the associated SFP as
advertisement that contains the SFP with which this SFP is advertized in an SFPR.
associated.
The Associated SPI contains the SPI of the associated SFP as The Associated SPI contains the SPI of the associated SFP as
advertised in the SFPR indicated by the Associated SFPR-RD field. advertised in an SFPR.
Association TLVs with unknown Association Type values SHOULD be Association TLVs with unknown Association Type values SHOULD be
ignored. Association TLVs that contain an Associated SFPR-RD value ignored. Association TLVs that contain an Associated SFPR-RD value
equal to the RD of the SFPR in which they are contained SHOULD be equal to the RD of the SFPR in which they are contained SHOULD be
ignored. If the Associated SPI is not equal to the SPI advertised in ignored. If the Associated SPI is not equal to the SPI advertised in
the SFPR indicated by the Associated SFPR-RD then the Association TLV the SFPR indicated by the Associated SFPR-RD then the Association TLV
SHOULD be ignored. SHOULD be ignored.
Note that when two SFPRs reference each other using the Association Note that when two SFPRs reference each other using the Association
TLV, one SFPR advertisement will be received before the other. TLV, one SFPR advertisement will be received before the other.
skipping to change at page 16, line 43 skipping to change at page 16, line 41
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 should 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. These may be SFT-SFI TLVs and SFT-Pool 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, and the list of sub-TLVs may least one sub-TLV MUST be present. This provides a list of which
include SFT-SFI and SFT-Pool TLVs as described in the following types of SF are acceptable at a specific hop, and for each type it
sections. This provides a list of which types of SF are acceptable allows a degree of control to be imposed on the choice of SFIs of
at a specific hop, and for each type it allow a degree of control to that particular type.
be imposed on the choice of SFIs of that particular type.
3.2.1.3. The SFT-SFI TLV 3.2.1.3. The SFT TLV
The SFT-SFI TLV MAY be included in the list of sub-TLVs of the Hop The SFT TLV MAY be included in the list of sub-TLVs of the Hop TLV.
TLV. The format of the SFT-SFI TLV is shown in Figure 9. The TLV The format of the SFT TLV is shown in Figure 9. The TLV contains a
contains a list of SFIR-RD values each taken from the advertisement list of SFIR-RD values each taken from the advertisement of an SFI.
of an SFI. Together they form a list of acceptable SFIs of the Together they form a list of acceptable SFIs of the indicated type.
indicated type.
+--------------------------------------------+ +--------------------------------------------+
| Type = 3 (1 octet) | | Type = 3 (1 octet) |
+--------------------------------------------| +--------------------------------------------|
| Length (2 octets) | | Length (2 octets) |
+--------------------------------------------| +--------------------------------------------|
| Service Function Type (2 octets) | | Service Function Type (2 octets) |
+--------------------------------------------| +--------------------------------------------|
| SFIR-RD List (variable) | | SFIR-RD List (variable) |
+--------------------------------------------+ +--------------------------------------------+
Figure 9: The Format of the SFT-SFI TLV Figure 9: The Format of the SFT TLV
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. An SFIR-RD RDs from the advertisements of the SFIs in the SFIRs. Note that
of value zero has special meaning as described in Section 5. Each if the list contains one or more SFI Pool Identifiers, then for
entry in the list is 8 octets long, and the number of entries in each the SFIR-RD list is effectively expanded to include the SFIR-
the list can be deduced from the value of the Length field. RD of each SFIR advertised with that SFI Pool Identifier. An
SFIR-RD of value zero has special meaning as described in
3.2.1.4. The SFT-Pool TLV 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
The SFT-Pool TLV MAY be included in the list of sub-TLVs of the Hop Length field.
TLV. The format of the SFT-Pool TLV is shown in Figure 10. The TLV
contains a list of SFI Pool Identifier values each taken from the
advertisement of an SFI. Together they form a list of pools of
acceptable SFIs of the indicated type.
+--------------------------------------------+
| Type = 4 (1 octet) |
+--------------------------------------------|
| Length (2 octets) |
+--------------------------------------------|
| Service Function Type (2 octets) |
+--------------------------------------------|
| SFI Pool List (variable) |
+--------------------------------------------+
Figure 10: The Format of the SFT TLV
The fields are as follows:
Type is set to 4 to indicate an SFT TLV.
Length indicates the length in octets of the Service Function Type
and SFIR-RD List fields.
The Service Function Type value indicates the category (type) of
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
range 1-31 are Special Purpose SFT values and have meanings
defined by the documents that describe them - the value 'Change
Sequence' is defined in Section 6.1 of this document.
The hop description is further qualified beyond the specification
of the SFTs by listing, for each SFT in each hop, the SFI Pool
Identifiers that may be used at the hop. The SFI pools are
identified using SFI Pool Identifiers from the advertisements of
the SFIs in the SFIRs. Each entry in the list is 6 octets long,
and the number of entries in the list can be deduced from the
value of the Length field.
3.2.1.5. MPLS Swapping/Stacking TLV 3.2.1.4. MPLS Swapping/Stacking TLV
The MPLS Swapping/Stacking TLV (Type value 5) is a zero length sub- The MPLS Swapping/Stacking TLV (Type value 4) is a zero length sub-
TLV that can be carried in the Hop TLV and is used when the data TLV that is optionally present in the Hop TLV and is used when the
representation is MPLS (see Section 7.6). It indicates to the data representation is MPLS (see Section 7.6). When present it
Classifier that imposes an MPLS label stack whether the current hop indicates to the Classifier imposing an MPLS label stack that the
is to use an {SPI, SI} label pair for label swapping or a {Context current hop is to use an {SFC Context Label, SF label} rather than an
label, SF label}. See Section 7.7 for more details. {SPI, SF} label pair. See Section 7.7 for more details.
3.2.1.6. 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 6) 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 SPI/SI Representation sub-TLV (see Section 7.6) with advertised an SPI/SI Representation sub-TLV (see Section 7.6) with
bit 0 set to 0 and bit 1 set to 1 for the SFP to be considered bit 0 set to 0 and bit 1 set to 1 for the SFP to be considered
usable. usable.
3.2.2. General Rules For The SFP Attribute 3.2.2. General Rules For The SFP Attribute
skipping to change at page 20, line 43 skipping to change at page 19, line 43
(i.e., imports more than one RT) may find it helpful to maintain (i.e., imports more than one RT) may find it helpful to maintain
separate forwarding state for each overlay network. 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 category of Service o A Service Function Type (SFT) that is the type of service function
Function that is provided (such as "firewall"). that is provided (such as "firewall").
o A Route Distinguisher (RD) that is unique to a specific instance o A Route Distinguisher (RD) that is unique to a specific instance
of a service function. of a service function.
4.3. Service Function Path Routes 4.3. Service Function Path Routes
The SFPR (see Section 3.2) describes a specific path of a Service The SFPR (see Section 3.2) describes a specific path of a Service
Function Chain. The SFPR contains the Service Path Identifier (SPI) Function Chain. The SFPR contains the Service Path Identifier (SPI)
used to identify the SFP in the NSH in the data plane. It also used to identify the SFP in the NSH in the data plane. It also
contains a sequence of Service Indexes (SIs). Each SI identifies a contains a sequence of Service Indexes (SIs). Each SI identifies a
skipping to change at page 23, line 12 skipping to change at page 22, line 12
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 special Service Function As shown in Figure 1, the Classifier is a special Service Function
that is used to assign packets to an SFP. that is used to 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 (usually by inspecting the packet header), imposing an
NSH, and initializing the NSH to include the SPI of the selected SFPR NSH, and initializing the NSH with the SPI of the selected SFP and
and to include the SI from first hop of the selected SFP. the SI of its first hop.
The Classifier may also provide an entropy indicator as described in The Classifier may also provide an entropy indicator as described in
Section 7.1. Section 7.1.
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
skipping to change at page 24, line 11 skipping to change at page 23, line 11
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 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 is described in Section 6.1 using a looping, jumping, and branching uses a specific resereved SFT value
special value of the SFT within an entry in an SFPR. at a given hop of an SFPR and is described in Section 6.1.
4.5.1. Processing With 'Gaps' in the SI Sequence 4.5.1. Processing With 'Gaps' in the SI Sequence
The behavior of an SF as described in [RFC8300] is to decrement the The behavior of an SF as described in [RFC8300] is to decrement the
value of the SI field in the NSH by one before returning a packet to value of the SI field in the NSH by one before returning a packet to
the local SFF for further processing. This means that there is a the local SFF for further processing. This means that there is a
good reason to assume that the SFP is composed of a series of SFs good reason to assume that the SFP is composed of a series of SFs
each indicated by an SI value one less than the previous. each indicated by an SI value one less than the previous.
However, there is an advantage to having non-successive SIs in an However, there is an advantage to having non-successive SIs in an
skipping to change at page 25, line 8 skipping to change at page 24, line 8
resulting from a change in SPI may have wide ripples and give scope resulting from a change in SPI may have wide ripples and give scope
for errors that are hard to trace. for errors that are hard to trace.
Therefore, while this document requires that the SI values in an SFP Therefore, while this document requires that the SI values in an SFP
are monotonic decreasing, it makes no assumption that the SI values are monotonic decreasing, it makes no assumption that the SI values
are sequential. Configuration tools may apply that rule, but they are sequential. Configuration tools may apply that rule, but they
are not required to. To support this, an SFF SHOULD process as are not required to. To support this, an SFF SHOULD process as
follows when it receives a packet: follows when it receives a packet:
o If the SI indicates a known entry in the SFP, the SFF MUST process o If the SI indicates a known entry in the SFP, the SFF MUST process
the packet as normal, looking up the SI and determining whether to the packet as normal, looking up the SI and determining to which
deliver the packet to a local SFI or to forward it to another SFF. 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].
SFF implementations MAY choose to only support contiguous SI values SFF implementations MAY choose to only support contiguous SI values
skipping to change at page 32, line 6 skipping to change at page 31, line 6
[RFC5575] defines a set of BGP routes that can be used to identify [RFC5575] defines a set of BGP routes that can be used to identify
the packets in a given flow using fields in the header of each the packets in a given flow using fields in the header of each
packet, and a set of actions, encoded as extended communities, that packet, and a set of actions, encoded as extended communities, that
can be used to disposition those packets. This document enables the can be used to disposition those packets. This document enables the
use of RFC 5575 mechanisms by SFC Classifiers by defining a new use of RFC 5575 mechanisms by SFC Classifiers by defining a new
action extended community called "Flow Spec for SFC classifiers" action extended community called "Flow Spec for SFC classifiers"
identified by the value TBD4. Note that other action extended identified by the value TBD4. Note that other action extended
communities may also be present. communities may also be present.
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 11: 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 11: 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] may include
skipping to change at page 35, line 21 skipping to change at page 34, line 21
Types SFT=41, SFT=42, SFT=43, and SFT=44 as follows: Types SFT=41, SFT=42, SFT=43, and SFT=44 as follows:
SFF1 SFT=41 and SFT=42 SFF1 SFT=41 and SFT=42
SFF2 SFT=41 and SFT=43 SFF2 SFT=41 and SFT=43
SFF3 SFT=42 and SFT=44 SFF3 SFT=42 and SFT=44
SFF4 SFT=43 and SFT=44 SFF4 SFT=43 and SFT=44
The service function network also contains a Controller with address The service function network also contains a Controller with address
198.51.100.1. 198.51.100.1.
This example service function overlay network is shown in Figure 12. This example service function overlay network is shown in Figure 11.
-------------- --------------
| Controller | | Controller |
| 198.51.100.1 | ------ ------ ------ ------ | 198.51.100.1 | ------ ------ ------ ------
-------------- | SFI | | SFI | | SFI | | SFI | -------------- | SFI | | SFI | | SFI | | SFI |
|SFT=41| |SFT=42| |SFT=41| |SFT=43| |SFT=41| |SFT=42| |SFT=41| |SFT=43|
------ ------ ------ ------ ------ ------ ------ ------
\ / \ / \ / \ /
--------- --------- --------- ---------
---------- | SFF1 | | SFF2 | ---------- | SFF1 | | SFF2 |
skipping to change at page 35, line 45 skipping to change at page 34, line 45
---------- --------- --------- ---------- --------- ---------
| SFF3 | | SFF4 | | SFF3 | | SFF4 |
|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 12: 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. So we see the
following SFIRs: following SFIRs:
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
skipping to change at page 41, line 15 skipping to change at page 40, line 15
8.9. Examples of SFPs with Stateful Service Functions 8.9. Examples of SFPs with Stateful Service Functions
This section provides some examples to demonstrate establishing SFPs This section provides some examples to demonstrate establishing SFPs
when there is a choice of service functions at a particular hop, and when there is a choice of service functions at a particular hop, and
where consistency of choice is required in both directions. The where consistency of choice is required in both directions. The
scenarios that give rise to this requirement are discussed in scenarios that give rise to this requirement are discussed in
Section 7.3. Section 7.3.
8.9.1. Forward and Reverse Choice Made at the SFF 8.9.1. Forward and Reverse Choice Made at the SFF
Consider the topology shown in Figure 13. There are three SFFs Consider the topology shown in Figure 12. There are three SFFs
arranged neatly in a line, and the middle one (SFF2) supports three arranged neatly in a line, and the middle one (SFF2) supports three
SFIs all of SFT 42. These three instances can be used by SFF2 to SFIs all of SFT 42. These three instances can be used by SFF2 to
load balance so that no one instance is swamped. load balance so that no one instance is swamped.
------ ------ ------ ------ ------ ------ ------ ------ ------ ------
| SFI | | SFIa | | SFIb | | SFIc | | SFI | | SFI | | SFIa | | SFIb | | SFIc | | SFI |
|SFT=41| |SFT=42| |SFT=42| |SFT=42| |SFT=43| |SFT=41| |SFT=42| |SFT=42| |SFT=42| |SFT=43|
------ ------\ ------ /------ ------ ------ ------\ ------ /------ ------
\ \ | / / \ \ | / /
--------- --------- --------- --------- --------- ---------
---------- | SFF1 | | SFF2 | | SFF3 | ---------- | SFF1 | | SFF2 | | SFF3 |
--> | |..|192.0.2.1|...|192.0.2.2|...|192.0.2.3|--> --> | |..|192.0.2.1|...|192.0.2.2|...|192.0.2.3|-->
--> |Classifier| --------- --------- --------- --> |Classifier| --------- --------- ---------
| | | |
---------- ----------
Figure 13: Example Where Choice is Made at the SFF Figure 12: Example Where Choice is Made at the SFF
This leads to the following SFIRs being advertised. This leads to the following SFIRs being advertised.
RD = 192.0.2.1,11, SFT = 41 RD = 192.0.2.1,11, SFT = 41
RD = 192.0.2.2,11, SFT = 42 (for SFIa) RD = 192.0.2.2,11, SFT = 42 (for SFIa)
RD = 192.0.2.2,12, SFT = 42 (for SFIb) RD = 192.0.2.2,12, SFT = 42 (for SFIb)
RD = 192.0.2.2,13, SFT = 42 (for SFIc) RD = 192.0.2.2,13, SFT = 42 (for SFIc)
RD = 192.0.2.3,11, SFT = 43 RD = 192.0.2.3,11, SFT = 43
The controller can create a single forward SFP giving SFF2 the choice The controller can create a single forward SFP giving SFF2 the choice
skipping to change at page 42, line 38 skipping to change at page 41, line 38
8.9.2. Parallel End-to-End SFPs with Shared SFF 8.9.2. Parallel End-to-End SFPs with Shared SFF
The mechanism described in Section 8.9.1 might not be desirable The mechanism described in Section 8.9.1 might not be desirable
because of the functional assumptions it places on SFF2 to be able to because of the functional assumptions it places on SFF2 to be able to
load balance with suitable flow identification, stability, and load balance with suitable flow identification, stability, and
equality in both directions. Instead, it may be desirable to place equality in both directions. Instead, it may be desirable to place
the responsibility for flow classification in the Classifier and let the responsibility for flow classification in the Classifier and let
it determine load balancing with the implied choice of SFIs. it determine load balancing with the implied choice of SFIs.
Consider the network graph as shown in Figure 13 and with the same Consider the network graph as shown in Figure 12 and with the same
set of SFIRs as listed in Section 8.9.1. In this case the controller set of SFIRs as listed in Section 8.9.1. In this case the controller
could specify three forward SFPs with their corresponding associated could specify three forward SFPs with their corresponding associated
reverse SFPs. Each bidirectional pair of SFPs uses a different SFI reverse SFPs. Each bidirectional pair of SFPs uses a different SFI
for the SF of type 42. The controller can instruct the Classifier for the SF of type 42. The controller can instruct the Classifier
how to place traffic on the three bidirectional SFPs, or can treat how to place traffic on the three bidirectional SFPs, or can treat
them as a group leaving the Classifier responsible for balancing the them as a group leaving the Classifier responsible for balancing the
load. load.
SFP14: RD = 198.51.100.1,114, SPI = 28, SFP14: RD = 198.51.100.1,114, SPI = 28,
Assoc-Type = 1, Assoc-RD = 198.51.100.1,117, Assoc-SPI = 31, Assoc-Type = 1, Assoc-RD = 198.51.100.1,117, Assoc-SPI = 31,
skipping to change at page 43, line 46 skipping to change at page 42, line 46
Assoc-Type = 1, Assoc-RD = 198.51.100.1,116, Assoc-SPI = 30, Assoc-Type = 1, Assoc-RD = 198.51.100.1,116, Assoc-SPI = 30,
[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,13], [SI = 254, SFT = 42, RD = 192.0.2.2,13],
[SI = 253, SFT = 41, RD = 192.0.2.1,11] [SI = 253, SFT = 41, RD = 192.0.2.1,11]
8.9.3. Parallel End-to-End SFPs with Separate SFFs 8.9.3. Parallel End-to-End SFPs with Separate SFFs
While the examples in Section 8.9.1 and Section 8.9.2 place the While the examples in Section 8.9.1 and Section 8.9.2 place the
choice of SFI as subtended from the same SFF, it is also possible choice of SFI as subtended from the same SFF, it is also possible
that the SFIs are each subtended from a different SFF as shown in that the SFIs are each subtended from a different SFF as shown in
Figure 14. In this case it is harder to coordinate the choices for Figure 13. In this case it is harder to coordinate the choices for
forward and reverse paths without some form of coordination between forward and reverse paths without some form of coordination between
SFF1 and SFF3. Therefore it would be normal to consider end-to-end SFF1 and SFF3. Therefore it would be normal to consider end-to-end
parallel SFPs as described in Section 8.9.2. parallel SFPs as described in Section 8.9.2.
------ ------
| SFIa | | SFIa |
|SFT=42| |SFT=42|
------ ------
------ | ------ |
| SFI | --------- | SFI | ---------
skipping to change at page 44, line 34 skipping to change at page 43, line 34
:.---------.: :.---------.:
| SFF7 | | SFF7 |
|192.0.2.7| |192.0.2.7|
--------- ---------
| |
------ ------
| SFIc | | SFIc |
|SFT=42| |SFT=42|
------ ------
Figure 14: Second Example With Parallel End-to-End SFPs Figure 13: Second Example With Parallel End-to-End SFPs
In this case, five SFIRs are advertised as follows: In this case, five SFIRs are advertised as follows:
RD = 192.0.2.1,11, SFT = 41 RD = 192.0.2.1,11, SFT = 41
RD = 192.0.2.5,11, SFT = 42 (for SFIa) RD = 192.0.2.5,11, SFT = 42 (for SFIa)
RD = 192.0.2.6,11, SFT = 42 (for SFIb) RD = 192.0.2.6,11, SFT = 42 (for SFIb)
RD = 192.0.2.7,11, SFT = 42 (for SFIc) RD = 192.0.2.7,11, SFT = 42 (for SFIc)
RD = 192.0.2.3,11, SFT = 43 RD = 192.0.2.3,11, SFT = 43
In this case the controller could specify three forward SFPs with In this case the controller could specify three forward SFPs with
skipping to change at page 46, line 6 skipping to change at page 45, line 6
The mechanism of parallel SFPs demonstrated in Section 8.9.3 is The mechanism of parallel SFPs demonstrated in Section 8.9.3 is
perfectly functional and may be practical in many environments. perfectly functional and may be practical in many environments.
However, there may be scaling concerns because of the large amount of However, there may be scaling concerns because of the large amount of
state (knowledge of SFPs, i.e., SFPR advertisements retained) if state (knowledge of SFPs, i.e., SFPR advertisements retained) if
there is a very large amount of choice of SFIs (for example, tens of there is a very large amount of choice of SFIs (for example, tens of
instances of the same stateful SF), or if there are multiple choices instances of the same stateful SF), or if there are multiple choices
of stateful SF along a path. This situation may be mitigated using of stateful SF along a path. This situation may be mitigated using
SFP fragments that are combined to form the end to end SFPs. SFP fragments that are combined to form the end to end SFPs.
The example presented here is necessarily simplistic, but should The example presented here is necessarily simplistic, but should
convey the basic principle. The example presented in Figure 15 is convey the basic principle. The example presented in Figure 14 is
similar to that in Section 8.9.3 but with an additional first hop. similar to that in Section 8.9.3 but with an additional first hop.
------ ------
| SFIa | | SFIa |
|SFT=43| |SFT=43|
------ ------
------ ------ | ------ ------ |
| SFI | | SFI | --------- | SFI | | SFI | ---------
|SFT=41| |SFT=42| | SFF5 | |SFT=41| |SFT=42| | SFF5 |
------ ------ ..|192.0.2.5|.. ------ ------ ..|192.0.2.5|..
skipping to change at page 46, line 38 skipping to change at page 45, line 38
:.---------.: :.---------.:
| SFF7 | | SFF7 |
|192.0.2.7| |192.0.2.7|
--------- ---------
| |
------ ------
| SFIc | | SFIc |
|SFT=43| |SFT=43|
------ ------
Figure 15: Example With Parallel SFPs Downstream of Choice Figure 14: Example With Parallel SFPs Downstream of Choice
The six SFIs are advertised as follows: The six SFIs are advertised as follows:
RD = 192.0.2.1,11, SFT = 41 RD = 192.0.2.1,11, SFT = 41
RD = 192.0.2.2,11, SFT = 42 RD = 192.0.2.2,11, SFT = 42
RD = 192.0.2.5,11, SFT = 43 (for SFIa) RD = 192.0.2.5,11, SFT = 43 (for SFIa)
RD = 192.0.2.6,11, SFT = 43 (for SFIb) RD = 192.0.2.6,11, SFT = 43 (for SFIb)
RD = 192.0.2.7,11, SFT = 43 (for SFIc) RD = 192.0.2.7,11, SFT = 43 (for SFIc)
RD = 192.0.2.3,11, SFT = 44 RD = 192.0.2.3,11, SFT = 44
skipping to change at page 50, line 9 skipping to change at page 49, line 9
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:
Type | Name | Reference | Date Type | Name | Reference | Date
------+-------------------------+---------------+--------------- ------+-------------------------+---------------+---------------
1 | Association TLV | [This.I-D] | Date-to-be-set 1 | Association TLV | [This.I-D] | Date-to-be-set
2 | Hop TLV | [This.I-D] | Date-to-be-set 2 | Hop TLV | [This.I-D] | Date-to-be-set
3 | SFT-SFI TLV | [This.I-D] | Date-to-be-set 3 | SFT TLV | [This.I-D] | Date-to-be-set
4 | SFT-Pool TLV | [This.I-D] | Date-to-be-set 4 | MPLS Swapping/Stacking | [This.I-D] | Date-to-be-set
5 | MPLS Swapping/Stacking | [This.I-D] | Date-to-be-set 5 | SFP Traversal With MPLS | [This.I-D] | Date-to-be-set
6 | SFP Traversal With MPLS | [This.I-D] | Date-to-be-set
10.4. New SFP Association Type Registry 10.4. New SFP Association Type Registry
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
skipping to change at page 53, line 11 skipping to change at page 51, line 47
Thanks to Tony Przygienda for helpful comments, and to Joel Halpern Thanks to Tony Przygienda for helpful comments, and to Joel Halpern
for discussions that improved this document. Yuanlong Jiang provided for discussions that improved this document. Yuanlong Jiang provided
a useful review and caught some important issues. a useful review and caught some important issues.
13. References 13. References
13.1. Normative References 13.1. Normative References
[I-D.ietf-idr-tunnel-encaps] [I-D.ietf-idr-tunnel-encaps]
Rosen, E., Patel, K., and G. Velde, "The BGP Tunnel Rosen, E., Patel, K., and G. Velde, "The BGP Tunnel
Encapsulation Attribute", draft-ietf-idr-tunnel-encaps-09 Encapsulation Attribute", draft-ietf-idr-tunnel-encaps-10
(work in progress), February 2018. (work in progress), August 2018.
[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 54, line 10 skipping to change at page 52, line 48
[RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed.,
"Network Service Header (NSH)", RFC 8300, "Network Service Header (NSH)", RFC 8300,
DOI 10.17487/RFC8300, January 2018, DOI 10.17487/RFC8300, January 2018,
<https://www.rfc-editor.org/info/rfc8300>. <https://www.rfc-editor.org/info/rfc8300>.
13.2. Informative References 13.2. Informative References
[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-01 (work in progress), May 2018. ietf-mpls-sfc-04 (work in progress), November 2018.
[RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and
L. Yong, "The Use of Entropy Labels in MPLS Forwarding", L. Yong, "The Use of Entropy Labels in MPLS Forwarding",
RFC 6790, DOI 10.17487/RFC6790, November 2012, RFC 6790, DOI 10.17487/RFC6790, November 2012,
<https://www.rfc-editor.org/info/rfc6790>. <https://www.rfc-editor.org/info/rfc6790>.
[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>.
skipping to change at page 54, line 35 skipping to change at page 53, line 28
<https://www.rfc-editor.org/info/rfc7510>. <https://www.rfc-editor.org/info/rfc7510>.
[RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function
Chaining (SFC) Architecture", RFC 7665, Chaining (SFC) Architecture", RFC 7665,
DOI 10.17487/RFC7665, October 2015, DOI 10.17487/RFC7665, October 2015,
<https://www.rfc-editor.org/info/rfc7665>. <https://www.rfc-editor.org/info/rfc7665>.
Authors' Addresses Authors' Addresses
Adrian Farrel Adrian Farrel
Juniper Networks Old Dog Consulting
Email: afarrel@juniper.net Email: adrian@olddog.co.uk
John Drake John Drake
Juniper Networks Juniper Networks
Email: jdrake@juniper.net Email: jdrake@juniper.net
Eric Rosen Eric Rosen
Juniper Networks Juniper Networks
Email: erosen@juniper.net Email: erosen@juniper.net
 End of changes. 44 change blocks. 
174 lines changed or deleted 134 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/