draft-ietf-bess-nsh-bgp-control-plane-03.txt   draft-ietf-bess-nsh-bgp-control-plane-04.txt 
BESS Working Group A. Farrel BESS Working Group A. Farrel
Internet-Draft J. Drake Internet-Draft J. Drake
Intended status: Standards Track E. Rosen Intended status: Standards Track E. Rosen
Expires: September 19, 2018 Juniper Networks Expires: January 2, 2019 Juniper Networks
J. Uttaro J. Uttaro
AT&T AT&T
L. Jalil L. Jalil
Verizon Verizon
March 18, 2018 July 1, 2018
BGP Control Plane for NSH SFC BGP Control Plane for NSH SFC
draft-ietf-bess-nsh-bgp-control-plane-03 draft-ietf-bess-nsh-bgp-control-plane-04
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 47
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 September 19, 2018. This Internet-Draft will expire on January 2, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 34 skipping to change at page 2, line 34
1.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 . . . . . . . . . 18 3.2.2. General Rules For The SFP Attribute . . . . . . . . . 19
4. Mode of Operation . . . . . . . . . . . . . . . . . . . . . . 19 4. Mode of Operation . . . . . . . . . . . . . . . . . . . . . . 20
4.1. Route Targets . . . . . . . . . . . . . . . . . . . . . . 19 4.1. Route Targets . . . . . . . . . . . . . . . . . . . . . . 20
4.2. Service Function Instance Routes . . . . . . . . . . . . 19 4.2. Service Function Instance Routes . . . . . . . . . . . . 20
4.3. Service Function Path Routes . . . . . . . . . . . . . . 19 4.3. Service Function Path Routes . . . . . . . . . . . . . . 21
4.4. Classifier Operation . . . . . . . . . . . . . . . . . . 21 4.4. Classifier Operation . . . . . . . . . . . . . . . . . . 23
4.5. Service Function Forwarder Operation . . . . . . . . . . 22 4.5. Service Function Forwarder Operation . . . . . . . . . . 23
4.5.1. Processing With 'Gaps' in the SI Sequence . . . . . . 23 4.5.1. Processing With 'Gaps' in the SI Sequence . . . . . . 24
5. Selection in Service Function Paths . . . . . . . . . . . . . 24 5. Selection in Service Function Paths . . . . . . . . . . . . . 25
6. Looping, Jumping, and Branching . . . . . . . . . . . . . . . 26 6. Looping, Jumping, and Branching . . . . . . . . . . . . . . . 27
6.1. Protocol Control of Looping, Jumping, and Branching . . . 26 6.1. Protocol Control of Looping, Jumping, and Branching . . . 27
6.2. Implications for Forwarding State . . . . . . . . . . . . 27 6.2. Implications for Forwarding State . . . . . . . . . . . . 28
7. Advanced Topics . . . . . . . . . . . . . . . . . . . . . . . 27 7. Advanced Topics . . . . . . . . . . . . . . . . . . . . . . . 29
7.1. Preserving Entropy . . . . . . . . . . . . . . . . . . . 27 7.1. Preserving Entropy . . . . . . . . . . . . . . . . . . . 29
7.2. Correlating Service Function Path Instances . . . . . . . 28 7.2. Correlating Service Function Path Instances . . . . . . . 29
7.3. Considerations for Stateful Service Functions . . . . . . 29 7.3. Considerations for Stateful Service Functions . . . . . . 30
7.4. VPN Considerations and Private Service Functions . . . . 30 7.4. VPN Considerations and Private Service Functions . . . . 31
7.5. Flow Spec for SFC Classifiers . . . . . . . . . . . . . . 30 7.5. Flow Spec for SFC Classifiers . . . . . . . . . . . . . . 31
7.6. Choice of Data Plane SPI/SI Representation . . . . . . . 32 7.6. Choice of Data Plane SPI/SI Representation . . . . . . . 33
7.6.1. MPLS Representation of the SPI/SI . . . . . . . . . . 33 7.6.1. MPLS Representation of the SPI/SI . . . . . . . . . . 34
7.7. MPLS Label Swapping/Stacking Operation . . . . . . . . . 33 7.7. MPLS Label Swapping/Stacking Operation . . . . . . . . . 34
8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 33 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 34
8.1. Example Explicit SFP With No Choices . . . . . . . . . . 35 8.1. Example Explicit SFP With No Choices . . . . . . . . . . 36
8.2. Example SFP With Choice of SFIs . . . . . . . . . . . . . 35 8.2. Example SFP With Choice of SFIs . . . . . . . . . . . . . 36
8.3. Example SFP With Open Choice of SFIs . . . . . . . . . . 36 8.3. Example SFP With Open Choice of SFIs . . . . . . . . . . 37
8.4. Example SFP With Choice of SFTs . . . . . . . . . . . . . 36 8.4. Example SFP With Choice of SFTs . . . . . . . . . . . . . 38
8.5. Example Correlated Bidirectional SFPs . . . . . . . . . . 37 8.5. Example Correlated Bidirectional SFPs . . . . . . . . . . 38
8.6. Example Correlated Asymmetrical Bidirectional SFPs . . . 38 8.6. Example Correlated Asymmetrical Bidirectional SFPs . . . 39
8.7. Example Looping in an SFP . . . . . . . . . . . . . . . . 38 8.7. Example Looping in an SFP . . . . . . . . . . . . . . . . 39
8.8. Example Branching in an SFP . . . . . . . . . . . . . . . 39 8.8. Example Branching in an SFP . . . . . . . . . . . . . . . 40
8.9. Examples of SFPs with Stateful Service Functions . . . . 40 8.9. Examples of SFPs with Stateful Service Functions . . . . 41
8.9.1. Forward and Reverse Choice Made at the SFF . . . . . 40 8.9.1. Forward and Reverse Choice Made at the SFF . . . . . 41
8.9.2. Parallel End-to-End SFPs with Shared SFF . . . . . . 41 8.9.2. Parallel End-to-End SFPs with Shared SFF . . . . . . 42
8.9.3. Parallel End-to-End SFPs with Separate SFFs . . . . . 42 8.9.3. Parallel End-to-End SFPs with Separate SFFs . . . . . 43
8.9.4. Parallel SFPs Downstream of the Choice . . . . . . . 44 8.9.4. Parallel SFPs Downstream of the Choice . . . . . . . 45
9. Security Considerations . . . . . . . . . . . . . . . . . . . 47 9. Security Considerations . . . . . . . . . . . . . . . . . . . 48
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49
10.1. New BGP AF/SAFI . . . . . . . . . . . . . . . . . . . . 48 10.1. New BGP AF/SAFI . . . . . . . . . . . . . . . . . . . . 49
10.2. New BGP Path Attribute . . . . . . . . . . . . . . . . . 48 10.2. New BGP Path Attribute . . . . . . . . . . . . . . . . . 49
10.3. New SFP Attribute TLVs Type Registry . . . . . . . . . . 48 10.3. New SFP Attribute TLVs Type Registry . . . . . . . . . . 49
10.4. New SFP Association Type Registry . . . . . . . . . . . 49 10.4. New SFP Association Type Registry . . . . . . . . . . . 50
10.5. New Service Function Type Registry . . . . . . . . . . . 49 10.5. New Service Function Type Registry . . . . . . . . . . . 51
10.6. New Generic Transitive Experimental Use Extended 10.6. New Generic Transitive Experimental Use Extended
Community Sub-Types . . . . . . . . . . . . . . . . . . 50 Community Sub-Types . . . . . . . . . . . . . . . . . . 51
10.7. New BGP Transitive Extended Community Types . . . . . . 50 10.7. New BGP Transitive Extended Community Types . . . . . . 52
10.8. SPI/SI Representation . . . . . . . . . . . . . . . . . 51 10.8. SPI/SI Representation . . . . . . . . . . . . . . . . . 52
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 51 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 52
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 51 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 52
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 51 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 53
13.1. Normative References . . . . . . . . . . . . . . . . . . 51 13.1. Normative References . . . . . . . . . . . . . . . . . . 53
13.2. Informative References . . . . . . . . . . . . . . . . . 52 13.2. Informative References . . . . . . . . . . . . . . . . . 54
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 53 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 54
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 39 skipping to change at page 11, line 39
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 with Sub-
Type TBD6 called the SFI Pool Identifier. It can be included in SFIR Type TBD6 called the SFI Pool Identifier extended community. It can
advertisements, and is used to indicate the identity of a pool of be included in SFIR advertisements, and is used to indicate the
SFIRs to which an SFIR belongs. Since an SFIR may be a member of identity of a pool of SFIRs to which an SFIR belongs. Since an SFIR
multiple pools, multiple of these extended communities may be present may be a member of multiple pools, multiple of these extended
on a single SFIR advertisement. communities may be present on a single SFIR advertisement.
SFIR pools allow SFIRs to be grouped for any purpose. Possible uses SFIR pools allow SFIRs to be grouped for any purpose. Possible uses
include control plane scalability and stability. include control plane scalability and stability.
The SFI Pool Identifier is encoded as an 8 octet value as shown in The SFI Pool Identifier extended community is encoded in 8 octets as
Figure 4. shown in Figure 4.
+--------------------------------------------+ +--------------------------------------------+
| Type = 0x80 (1 octet) | | Type = 0x80 (1 octet) |
+--------------------------------------------| +--------------------------------------------+
| Sub-Type = TBD6 (1 octet) | | Sub-Type = TBD6 (1 octet) |
+--------------------------------------------| +--------------------------------------------+
| SPI Pool Identifier (6 octets) | | SFI Pool Identifier (6 octets) |
+--------------------------------------------| +--------------------------------------------+
Figure 4: The SFI Pool Identifier Figure 4: The SFI Pool Identifier Extended Community
The SFI Pool Identifier is a six octet, globally unique value encoded The SFI Pool Identifier is encoded in a 6 octet field in network
in network byte order. 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 with Sub-
Type TBD7 called the MPLS Mixed Swapping/Stacking Labels. The Type TBD7 called the MPLS Mixed Swapping/Stacking Labels. The
community is encoded as shown in Figure 5. It contains a pair of community is encoded as shown in Figure 5. It contains a pair of
MPLS labels: an SFC Context Label and an SF Label as described in MPLS labels: an SFC Context Label and an SF Label as described in
[I-D.farrel-mpls-sfc]. Each label is 20 bits encoded in a 3-octet [I-D.ietf-mpls-sfc]. Each label is 20 bits encoded in a 3-octet (24
(24 bit) field with 4 trailing bits that MUST be set to zero. 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 16, line 42 skipping to change at page 16, line 42
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 consist of a sequence of one or more SFT TLVs. The Hop Details field consists of a sequence of one or more sub-
TLVs. These may be SFT-SFI TLVs and SFT-Pool TLVs.
3.2.1.3. The SFT TLV 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
least one sub-TLV MUST be present, and the list of sub-TLVs may
include SFT-SFI and SFT-Pool TLVs as described in the following
sections. This provides a list of which types of SF are acceptable
at a specific hop, and for each type it allow a degree of control to
be imposed on the choice of SFIs of that particular type.
There is one or more SFT TLV in each Hop TLV. There is one SFT TLV 3.2.1.3. The SFT-SFI TLV
for each SFT supported in the specific hop of the SFP. The format of
the SFT TLV is shown in Figure 9. The SFT-SFI TLV MAY be included in the list of sub-TLVs of the Hop
TLV. The format of the SFT-SFI TLV is shown in Figure 9. The TLV
contains a list of SFIR-RD values each taken from the advertisement
of an SFI. Together they form a list of acceptable SFIs of the
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 TLV Figure 9: The Format of the SFT-SFI 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 is used to identify a Service Function The Service Function Type value indicates the category (type) of
Instance Route in the service function overlay network which, in SF that is to be executed at this hop. The types are as
turn, will allow lookup of routes to SFIs implementing the SF. advertised for the SFs supported by the SFFs SFT values in the
SFT values in the range 1-31 are Special Purpose SFT values and range 1-31 are Special Purpose SFT values and have meanings
have meanings defined by the documents that describe them - the defined by the documents that describe them - the value 'Change
value 'Change Sequence' is defined in Section 6.1 of this Sequence' is defined in Section 6.1 of this document.
document.
The SFIR-RD List is made up of one or more SFIR-RD or SPI Pool The hop description is further qualified beyond the specification
Identifiers obtained from the advertisements of SFIs in SFIRs. An of the SFTs by listing, for each SFT in each hop, the SFIs that
SFIR-RD of value zero has special meaning as described in may be used at the hop. The SFIs are identified using the SFIR-
Section 5. Note that If the list contains one or more SPI Pool RDs from the advertisements of the SFIs in the SFIRs. An SFIR-RD
Identifiers, then for each the SFIR-RD list is effectively of value zero has special meaning as described in Section 5. Each
expanded to include the SFIR-RD of each SFIR advertised with that entry in the list is 8 octets long, and the number of entries in
SPI Pool Identifier. Each entry in the list is 8 octets long, and the list can be deduced from the value of the Length field.
the number of entries in the list can be deduced from the value of
the Length field.
3.2.1.4. MPLS Swapping/Stacking TLV 3.2.1.4. The SFT-Pool TLV
The MPLS Swapping/Stacking TLV (Type value 4) is a zero length sub- The SFT-Pool TLV MAY be included in the list of sub-TLVs of the Hop
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
The MPLS Swapping/Stacking TLV (Type value 5) is a zero length sub-
TLV that can be carried in the Hop TLV and is used when the data TLV that can be carried in the Hop TLV and is used when the data
representation is MPLS (see Section 7.6). It indicates to the representation is MPLS (see Section 7.6). It indicates to the
Classifier that imposes an MPLS label stack whether the current hop Classifier that imposes an MPLS label stack whether the current hop
is to use an {SPI, SI} label pair for label swapping or a {Context is to use an {SPI, SI} label pair for label swapping or a {Context
label, SF label}. See Section 7.7 for more details. label, SF label}. See Section 7.7 for more details.
3.2.1.5. SFP Traversal With MPLS Label Stack TLV 3.2.1.6. 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 6) 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 21, line 29 skipping to change at page 22, line 42
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
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 SPI Note that if the SFIR-RD list in an SFT TLV contains one or more SFI
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 SPI Pool number of individual SFIR-RD values and the sum for each SFI Pool
Identifier of the number of SFIRs advertised with that SPI Pool Identifier of the number of SFIRs advertised with that SFI 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 SPI Pool to include the SFIR-RD of each SFIR advertised with each SFI Pool
Identifier in the SFRIR-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 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.
skipping to change at page 26, line 7 skipping to change at page 27, line 14
that SFI. For a particular packet, the SFF chooses a particular SFI that SFI. For a particular packet, the SFF chooses a particular SFI
from the set of relevant SFIRs. This choice is made according to from the set of relevant SFIRs. This choice is made according to
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.
6. Looping, Jumping, and Branching 6. Looping, Jumping, and Branching
As described in Section 2 an SFI or an SFF may cause a packets 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.
Section 2 also describes how an SFI or an SFF may cause a packets to Section 2 also describes how an SFI or an SFF may cause a packets to
"jump forward" to an SF on a path that is not the immediate next SF "jump forward" to an SF on a path that is not the immediate next SF
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.
skipping to change at page 30, line 41 skipping to change at page 32, 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 10: Figure 11:
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 11: 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 32, line 13 skipping to change at page 33, line 17
as indicated in the SPFR for the indicated SPI MUST be used. as indicated in the SPFR for the indicated SPI MUST be used.
7.6. Choice of Data Plane SPI/SI Representation 7.6. 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.farrel-mpls-sfc]. MPLS labels [I-D.ietf-mpls-sfc].
This document defines a new sub-TLV for the Tunnel Encapsulation This document defines a new sub-TLV for the Tunnel Encapsulation
attribute, the SPI/SI Representation sub-TLV of type TBD5. This sub- attribute, the SPI/SI Representation sub-TLV of type TBD5. This sub-
TLV MAY be present in each Tunnel TLV contained in a Tunnel TLV MAY be present in each Tunnel TLV contained in a Tunnel
Encapsulation attribute when the attribute is carried by an SFIR. Encapsulation attribute when the attribute is carried by an SFIR.
The value field of this sub-TLV is a two octet field of flags, each The value field of this sub-TLV is a two octet field of flags, each
of which describes how the originating SFF expects to see the SPI/SI of which describes how the originating SFF expects to see the SPI/SI
represented in the data plane for packets carried in the tunnels represented in the data plane for packets carried in the tunnels
described by the Tunnel TLV. described by the Tunnel TLV.
skipping to change at page 33, line 15 skipping to change at page 34, line 22
NSH itself). It is a requirement that both ends of a tunnel over the NSH itself). It is a requirement that both ends of a tunnel over the
underlay network know that the tunnel is used for SFC and know what underlay network know that the tunnel is used for SFC and know what
form of NSH representation is used. The signaling mechanism form of NSH representation is used. The signaling mechanism
described here allows coordination of this information. described here allows coordination of this information.
7.6.1. MPLS Representation of the SPI/SI 7.6.1. MPLS Representation of the SPI/SI
If bit 1 is set in the in the SPI/SI Representation sub-TLV then If bit 1 is set in the in the SPI/SI Representation sub-TLV then
labels in the MPLS label stack are used to indicate SFC forwarding labels in the MPLS label stack are used to indicate SFC forwarding
and processing instructions to achieve the semantics of a logical and processing instructions to achieve the semantics of a logical
NSH. The label stack is encoded as shown in [I-D.farrel-mpls-sfc]. NSH. The label stack is encoded as shown in [I-D.ietf-mpls-sfc].
7.7. MPLS Label Swapping/Stacking Operation 7.7. MPLS Label Swapping/Stacking Operation
When a classifier constructs an MPLS label stack for an SFP it starts When a classifier constructs an MPLS label stack for an SFP it starts
with that SFP' last hop. If the last hop requires an {SPI, SI} label with that SFP' last hop. If the last hop requires an {SPI, SI} label
pair for label swapping, it pushes the SI (set to the SI value of the pair for label swapping, it pushes the SI (set to the SI value of the
last hop) and the SFP's SPI onto the MPLS label stack. If the last last hop) and the SFP's SPI onto the MPLS label stack. If the last
hop requires a {context label, SFI label} label pair for label hop requires a {context label, SFI label} label pair for label
stcking it selects a specific SFIR and pushes that SFIR's SFI label stcking it selects a specific SFIR and pushes that SFIR's SFI label
and context label onto the MPLS label stack. and context label onto the MPLS label stack.
skipping to change at page 34, line 16 skipping to change at page 35, 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 11. This example service function overlay network is shown in Figure 12.
-------------- --------------
| 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 34, line 40 skipping to change at page 35, 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 11: Example Service Function Overlay Network Figure 12: 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 40, line 15 skipping to change at page 41, 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 12. There are three SFFs Consider the topology shown in Figure 13. 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 12: Example Where Choice is Made at the SFF Figure 13: 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 41, line 38 skipping to change at page 42, 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 12 and with the same Consider the network graph as shown in Figure 13 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 42, line 45 skipping to change at page 43, line 45
SFP19: RD = 198.51.100.1,119, SPI = 33, SFP19: RD = 198.51.100.1,119, SPI = 33,
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 ach subtended from a different SFF as shown in that the SFIs are each subtended from a different SFF as shown in
Figure 13. In this case it is harder to coordinate the choices for Figure 14. 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 43, line 34 skipping to change at page 44, line 34
:.---------.: :.---------.:
| SFF7 | | SFF7 |
|192.0.2.7| |192.0.2.7|
--------- ---------
| |
------ ------
| SFIc | | SFIc |
|SFT=42| |SFT=42|
------ ------
Figure 13: Second Example With Parallel End-to-End SFPs Figure 14: 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 45, line 6 skipping to change at page 46, 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 14 is convey the basic principle. The example presented in Figure 15 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 45, line 38 skipping to change at page 46, line 38
:.---------.: :.---------.:
| SFF7 | | SFF7 |
|192.0.2.7| |192.0.2.7|
--------- ---------
| |
------ ------
| SFIc | | SFIc |
|SFT=43| |SFT=43|
------ ------
Figure 14: Example With Parallel SFPs Downstream of Choice Figure 15: 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 49, line 9 skipping to change at page 50, 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 TLV | [This.I-D] | Date-to-be-set 3 | SFT-SFI TLV | [This.I-D] | Date-to-be-set
4 | MPLS Swapping/Stacking | [This.I-D] | Date-to-be-set 4 | SFT-Pool TLV | [This.I-D] | Date-to-be-set
5 | SFP Traversal With MPLS | [This.I-D] | Date-to-be-set 5 | MPLS Swapping/Stacking | [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 51, line 38 skipping to change at page 52, line 44
Email: keyur@arrcus.com Email: keyur@arrcus.com
Avinash Lingala Avinash Lingala
AT&T AT&T
Email: ar977m@att.com Email: ar977m@att.com
12. Acknowledgements 12. Acknowledgements
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. for discussions that improved this document. Yuanlong Jiang provided
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-09
(work in progress), February 2018. (work in progress), February 2018.
skipping to change at page 52, line 45 skipping to change at page 54, line 7
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[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.farrel-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-
farrel-mpls-sfc-04 (work in progress), March 2018. ietf-mpls-sfc-01 (work in progress), May 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>.
 End of changes. 44 change blocks. 
123 lines changed or deleted 175 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/