draft-ietf-bess-nsh-bgp-control-plane-01.txt   draft-ietf-bess-nsh-bgp-control-plane-02.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: March 29, 2018 Juniper Networks Expires: May 3, 2018 Juniper Networks
J. Uttaro J. Uttaro
AT&T AT&T
L. Jalil L. Jalil
Verizon Verizon
September 25, 2017 October 30, 2017
BGP Control Plane for NSH SFC BGP Control Plane for NSH SFC
draft-ietf-bess-nsh-bgp-control-plane-01 draft-ietf-bess-nsh-bgp-control-plane-02
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 2, line 7 skipping to change at page 2, line 7
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 March 29, 2018. This Internet-Draft will expire on May 3, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. 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.2. Service Function Path Route (SFPR) . . . . . . . . . . . 11 3.1.1. SFI Pool Identifier Extended Community . . . . . . . 11
3.2.1. The SFP Attribute . . . . . . . . . . . . . . . . . . 12 3.1.2. MPLS Mixed Swapping/Stacking Extended Community . . . 12
3.2.2. General Rules For The SFP Attribute . . . . . . . . . 16 3.2. Service Function Path Route (SFPR) . . . . . . . . . . . 13
4. Mode of Operation . . . . . . . . . . . . . . . . . . . . . . 17 3.2.1. The SFP Attribute . . . . . . . . . . . . . . . . . . 13
4.1. Route Targets . . . . . . . . . . . . . . . . . . . . . . 17 3.2.2. General Rules For The SFP Attribute . . . . . . . . . 18
4.2. Service Function Instance Routes . . . . . . . . . . . . 17 4. Mode of Operation . . . . . . . . . . . . . . . . . . . . . . 19
4.3. Service Function Path Routes . . . . . . . . . . . . . . 18 4.1. Route Targets . . . . . . . . . . . . . . . . . . . . . . 19
4.4. Classifier Operation . . . . . . . . . . . . . . . . . . 19 4.2. Service Function Instance Routes . . . . . . . . . . . . 19
4.5. Service Function Forwarder Operation . . . . . . . . . . 20 4.3. Service Function Path Routes . . . . . . . . . . . . . . 19
4.5.1. Processing With 'Gaps' in the SI Sequence . . . . . . 21 4.4. Classifier Operation . . . . . . . . . . . . . . . . . . 21
5. Selection in Service Function Paths . . . . . . . . . . . . . 22 4.5. Service Function Forwarder Operation . . . . . . . . . . 22
6. Looping, Jumping, and Branching . . . . . . . . . . . . . . . 24 4.5.1. Processing With 'Gaps' in the SI Sequence . . . . . . 23
6.1. Protocol Control of Looping, Jumping, and Branching . . . 24 5. Selection in Service Function Paths . . . . . . . . . . . . . 24
6.2. Implications for Forwarding State . . . . . . . . . . . . 25 6. Looping, Jumping, and Branching . . . . . . . . . . . . . . . 26
7. Advanced Topics . . . . . . . . . . . . . . . . . . . . . . . 25 6.1. Protocol Control of Looping, Jumping, and Branching . . . 26
7.1. Preserving Entropy . . . . . . . . . . . . . . . . . . . 25 6.2. Implications for Forwarding State . . . . . . . . . . . . 27
7.2. Correlating Service Function Path Instances . . . . . . . 26 7. Advanced Topics . . . . . . . . . . . . . . . . . . . . . . . 27
7.3. Considerations for Stateful Service Functions . . . . . . 27 7.1. Preserving Entropy . . . . . . . . . . . . . . . . . . . 27
7.4. VPN Considerations and Private Service Functions . . . . 28 7.2. Correlating Service Function Path Instances . . . . . . . 28
7.5. Flow Spec for SFC Classifiers . . . . . . . . . . . . . . 28 7.3. Considerations for Stateful Service Functions . . . . . . 29
7.6. Choice of Data Plane SPI/SI Representation . . . . . . . 30 7.4. VPN Considerations and Private Service Functions . . . . 30
7.6.1. MPLS Representation of the SPI/SI . . . . . . . . . . 31 7.5. Flow Spec for SFC Classifiers . . . . . . . . . . . . . . 30
8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 32 7.6. Choice of Data Plane SPI/SI Representation . . . . . . . 32
8.1. Example Explicit SFP With No Choices . . . . . . . . . . 34 7.6.1. MPLS Representation of the SPI/SI . . . . . . . . . . 33
8.2. Example SFP With Choice of SFIs . . . . . . . . . . . . . 34 7.7. MPLS Label Swapping/Stacking Operation . . . . . . . . . 33
8.3. Example SFP With Open Choice of SFIs . . . . . . . . . . 35 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 33
8.1. Example Explicit SFP With No Choices . . . . . . . . . . 35
8.2. Example SFP With Choice of SFIs . . . . . . . . . . . . . 35
8.3. Example SFP With Open Choice of SFIs . . . . . . . . . . 36
8.4. Example SFP With Choice of SFTs . . . . . . . . . . . . . 36 8.4. Example SFP With Choice of SFTs . . . . . . . . . . . . . 36
8.5. Example Correlated Bidirectional SFPs . . . . . . . . . . 36 8.5. Example Correlated Bidirectional SFPs . . . . . . . . . . 37
8.6. Example Correlated Asymmetrical Bidirectional SFPs . . . 37 8.6. Example Correlated Asymmetrical Bidirectional SFPs . . . 38
8.7. Example Looping in an SFP . . . . . . . . . . . . . . . . 37 8.7. Example Looping in an SFP . . . . . . . . . . . . . . . . 38
8.8. Example Branching in an SFP . . . . . . . . . . . . . . . 38 8.8. Example Branching in an SFP . . . . . . . . . . . . . . . 39
8.9. Examples of SFPs with Stateful Service Functions . . . . 39 8.9. Examples of SFPs with Stateful Service Functions . . . . 40
8.9.1. Forward and Reverse Choice Made at the SFF . . . . . 39 8.9.1. Forward and Reverse Choice Made at the SFF . . . . . 40
8.9.2. Parallel End-to-End SFPs with Shared SFF . . . . . . 40 8.9.2. Parallel End-to-End SFPs with Shared SFF . . . . . . 41
8.9.3. Parallel End-to-End SFPs with Separate SFFs . . . . . 41 8.9.3. Parallel End-to-End SFPs with Separate SFFs . . . . . 42
8.9.4. Parallel SFPs Downstream of the Choice . . . . . . . 43 8.9.4. Parallel SFPs Downstream of the Choice . . . . . . . 44
9. Security Considerations . . . . . . . . . . . . . . . . . . . 46 9. Security Considerations . . . . . . . . . . . . . . . . . . . 47
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48
10.1. New BGP AF/SAFI . . . . . . . . . . . . . . . . . . . . 47 10.1. New BGP AF/SAFI . . . . . . . . . . . . . . . . . . . . 48
10.2. New BGP Path Attribute . . . . . . . . . . . . . . . . . 47 10.2. New BGP Path Attribute . . . . . . . . . . . . . . . . . 48
10.3. New SFP Attribute TLVs Type Registry . . . . . . . . . . 47 10.3. New SFP Attribute TLVs Type Registry . . . . . . . . . . 48
10.4. New SFP Association Type Registry . . . . . . . . . . . 48 10.4. New SFP Association Type Registry . . . . . . . . . . . 49
10.5. New Service Function Type Registry . . . . . . . . . . . 48 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-Type . . . . . . . . . . . . . . . . . . . 49 Community Sub-Types . . . . . . . . . . . . . . . . . . 50
10.7. SPI/SI Representation . . . . . . . . . . . . . . . . . 49 10.7. SPI/SI Representation . . . . . . . . . . . . . . . . . 51
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 50 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 51
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 50 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 51
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 50 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 51
13.1. Normative References . . . . . . . . . . . . . . . . . . 50 13.1. Normative References . . . . . . . . . . . . . . . . . . 51
13.2. Informative References . . . . . . . . . . . . . . . . . 51 13.2. Informative References . . . . . . . . . . . . . . . . . 52
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 51 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 36 skipping to change at page 11, line 36
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
This document defines a new transitive extended community with Sub-
Type TBD6 called the SFI Pool Identifier. It can be included in SFIR
advertisements, and is used to indicate the identity of a pool of
SFIRs to which an SFIR belongs. Since an SFIR may be a member of
multiple pools, multiple of these extended communities may be present
on a single SFIR advertisement.
SFIR pools allow SFIRs to be grouped for any purpose. Possible uses
include control plane scalability and stability.
The SFI Pool Identifier is encoded as an 8 octet value as shown in
Figure 4.
+--------------------------------------------+
| Type = 0x80 (1 octet) |
+--------------------------------------------|
| Sub-Type = TBD6 (1 octet) |
+--------------------------------------------|
| SPI Pool Identifier (6 octets) |
+--------------------------------------------|
Figure 4: The SFI Pool Identifier
The SFI Pool Identifier is a six octet, globally unique value encoded
in network byte order.
3.1.2. MPLS Mixed Swapping/Stacking Extended Community
This document defines a new transitive extended community with Sub-
Type TBD7 called the MPLS Mixed Swapping/Stacking Labels. The
community is encoded as shown in Figure 5. It contains a pair of
MPLS labels: an SFC Context Label and an SF Label as described in
[I-D.farrel-mpls-sfc]. Each label is 20 bits encoded in a 3-octet
(24 bit) field with 4 trailing bits that MUST be set to zero.
+--------------------------------------------+
| Type = 0x80 (1 octet) |
+--------------------------------------------|
| Sub-Type = TBD7 (1 octet) |
+--------------------------------------------|
| SFC Context Label (3 octets) |
+--------------------------------------------|
| SF Label (3 octets) |
+--------------------------------------------+
Figure 5: The MPLS Mixed Swapping/Stacking Labels
Note that it is assumed that each SFF has one or more globally unique
SFC Context Labels and that the context label space and the SPI
address space are disjoint.
See Section 7.7 for a description of how this extended community is
used.
3.2. Service Function Path Route (SFPR) 3.2. Service Function Path Route (SFPR)
Figure 4 shows the Route Type specific NLRI of the SFPR. Figure 6 shows the Route Type specific NLRI of the SFPR.
+-----------------------------------------------+ +-----------------------------------------------+
| Route Distinguisher (RD) (8 octets) | | Route Distinguisher (RD) (8 octets) |
+-----------------------------------------------+ +-----------------------------------------------+
| Service Path Identifier (SPI) (3 octets) | | Service Path Identifier (SPI) (3 octets) |
+-----------------------------------------------+ +-----------------------------------------------+
Figure 4: SFPR Route Type Specific NLRI Figure 6: SFPR Route Type Specific NLRI
Per [RFC4364] the RD field comprises a two byte Type field and a six Per [RFC4364] the RD field comprises a two byte Type field and a six
byte Value field. All SFPs must be associated with different RDs. byte Value field. All SFPs must be associated with different RDs.
The association of an SFP with an RD is determined by provisioning. The association of an SFP with an RD is determined by provisioning.
If two SFPRs are originated from different Controllers they must have If two SFPRs are originated from different Controllers they must have
different RDs. Additionally, SFPRs from different VPNs (i.e., in different RDs. Additionally, SFPRs from different VPNs (i.e., in
different service function overlay networks) must have different RDs, different service function overlay networks) must have different RDs,
and those RDs must be different from any non-VPN SFPRs. and those RDs must be different from any non-VPN SFPRs.
The Service Path Identifier is defined in [I-D.ietf-sfc-nsh] and is The Service Path Identifier is defined in [I-D.ietf-sfc-nsh] and is
the value to be placed in the Service Path Identifier field of the the value to be placed in the Service Path Identifier field of the
NSH header of any packet sent on this Service Function Path. It is NSH header of any packet sent on this Service Function Path. It is
expected that one or more Controllers will originate these routes in expected that one or more Controllers will originate these routes in
skipping to change at page 13, line 29 skipping to change at page 14, line 43
SFT TLVs. Each SFT TLV contains an SFI reference for each SFT TLVs. Each SFT TLV contains an SFI reference for each
instance of an SF that is allowed at this hop of the SFP for the instance of an SF that is allowed at this hop of the SFP for the
specific SFT. Each SFI is indicated using the RD with which it is specific SFT. Each SFI is indicated using the RD with which it is
advertised (we say the SFIR-RD to avoid ambiguity). advertised (we say the SFIR-RD to avoid ambiguity).
3.2.1.1. The Association TLV 3.2.1.1. The Association TLV
The Association TLV is an optional TLV in the SFP attribute. It may The Association TLV is an optional TLV in the SFP attribute. It may
be present multiple times. Each occurrence provides an association be present multiple times. Each occurrence provides an association
with another SFP as advertised in another SFPR. The format of the with another SFP as advertised in another SFPR. The format of the
Association TLV is shown in Figure 5 Association TLV is shown in Figure 7
+--------------------------------------------+ +--------------------------------------------+
| Type = 1 (1 octet) | | Type = 1 (1 octet) |
+--------------------------------------------| +--------------------------------------------|
| Length (2 octets) | | Length (2 octets) |
+--------------------------------------------| +--------------------------------------------|
| Association Type (1 octet) | | Association Type (1 octet) |
+--------------------------------------------| +--------------------------------------------|
| Associated SFPR-RD (8 octets) | | Associated SFPR-RD (8 octets) |
+--------------------------------------------| +--------------------------------------------|
| Associated SPI (3 octets) | | Associated SPI (3 octets) |
+--------------------------------------------+ +--------------------------------------------+
Figure 5: The Format of the Association TLV Figure 7: The Format of the Association TLV
The fields are as follows: The fields are as follows:
Type is set to 1 to indicate an Association TLV. Type is set to 1 to indicate an Association TLV.
Length indicates the length in octets of the Association Type and Length indicates the length in octets of the Association Type and
Associated SFPR-RD fields. The value of the Length field is 12. Associated SFPR-RD fields. The value of the Length field is 12.
The Association Type field indicate the type of association. The The Association Type field indicate the type of association. The
values are tracked in an IANA registry (see Section 10.4). Only values are tracked in an IANA registry (see Section 10.4). Only
skipping to change at page 14, line 41 skipping to change at page 16, line 16
TLV, one SFPR advertisement will be received before the other. TLV, one SFPR advertisement will be received before the other.
Therefore, processing of an association MUST NOT be rejected simply Therefore, processing of an association MUST NOT be rejected simply
because the Associated SFPR-RD is unknown. because the Associated SFPR-RD is unknown.
Further discussion of correlation of SFPRs is provided in Further discussion of correlation of SFPRs is provided in
Section 7.2. Section 7.2.
3.2.1.2. The Hop TLV 3.2.1.2. The Hop TLV
There is one Hop TLV in the SFP attribute for each hop in the SFP. There is one Hop TLV in the SFP attribute for each hop in the SFP.
The format of the Hop TLV is shown in Figure 6. At least one Hop TLV The format of the Hop TLV is shown in Figure 8. At least one Hop TLV
must be present in an SFP attribute. must be present in an SFP attribute.
+--------------------------------------------+ +--------------------------------------------+
| Type = 2 (1 octet) | | Type = 2 (1 octet) |
+--------------------------------------------| +--------------------------------------------|
| Length (2 octets) | | Length (2 octets) |
+--------------------------------------------| +--------------------------------------------|
| Service Index (1 octet) | | Service Index (1 octet) |
+--------------------------------------------| +--------------------------------------------|
| Hop Details (variable) | | Hop Details (variable) |
+--------------------------------------------+ +--------------------------------------------+
Figure 6: The Format of the Hop TLV Figure 8: The Format of the Hop TLV
The fields are as follows: The fields are as follows:
Type is set to 2 to indicate a Hop TLV. Type is set to 2 to indicate a Hop TLV.
Length indicates the length in octets of the Service Index and Hop Length indicates the length in octets of the Service Index and Hop
Details fields. Details fields.
The Service Index is defined in [I-D.ietf-sfc-nsh] and is the The Service Index is defined in [I-D.ietf-sfc-nsh] and is the
value found in the Service Index field of the NSH header that an value found 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. SFF will use 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 consist of a sequence of one or more SFT TLVs.
3.2.1.3. The SFT TLV 3.2.1.3. The SFT TLV
There is one or more SFT TLV in each Hop TLV. There is one SFT TLV There is one or more SFT TLV in each Hop TLV. There is one SFT TLV
for each SFT supported in the specific hop of the SFP. The format of for each SFT supported in the specific hop of the SFP. The format of
the SFT TLV is shown in Figure 7. the SFT TLV is shown in Figure 9.
+--------------------------------------------+ +--------------------------------------------+
| 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 7: The Format of the SFT 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 is used to identify a Service Function The Service Function Type is used to identify a Service Function
Instance Route in the service function overlay network which, in Instance Route in the service function overlay network which, in
turn, will allow lookup of routes to SFIs implementing the SF. turn, will allow lookup of routes to SFIs implementing the SF.
SFT values in the range 1-31 are Special Purpose SFT values and SFT values in the range 1-31 are Special Purpose SFT values and
have meanings defined by the documents that describe them - the have meanings defined by the documents that describe them - the
value 'Change Sequence' is defined in Section 6.1 of this value 'Change Sequence' is defined in Section 6.1 of this
document. document.
The SFIR-RD List is made up of one or more SFIR-RD values from the The SFIR-RD List is made up of one or more SFIR-RD or SPI Pool
advertisements of SFIs in SFIRs. An SFIR-RD of value zero has Identifiers obtained from the advertisements of SFIs in SFIRs. An
special meaning as described in Section 5. Each entry in the list SFIR-RD of value zero has special meaning as described in
is 8 octets long, and the number of entries in the list can be Section 5. Note that If the list contains one or more SPI Pool
deduced from the value of the Length field. Identifiers, then for each the SFIR-RD list is effectively
expanded to include the SFIR-RD of each SFIR advertised with that
SPI Pool Identifier. Each entry in the list is 8 octets long, and
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
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
representation is MPLS (see Section 7.6). It indicates to the
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
label, SF label}. See Section 7.7 for more details.
3.2.1.5. SFP Traversal With MPLS Label Stack
The MPLS Swapping/Stacking TLV (Type value 5) is a zero 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 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 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 usable.
3.2.2. General Rules For The SFP Attribute 3.2.2. General Rules For The SFP Attribute
It is possible for the same SFI, as described by an SFIR, to be used It is possible for the same SFI, as described by an SFIR, to be used
in multiple SFPRs. in multiple SFPRs.
When two SFPRs have the same SPI but different SFPR-RDs there can be When two SFPRs have the same SPI but different SFPR-RDs there can be
three cases: three cases:
o Two or more Controllers are originating SFPRs for the same SFP. o Two or more Controllers are originating SFPRs for the same SFP.
skipping to change at page 19, line 42 skipping to change at page 21, line 29
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
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
Identifier of the number of SFIRs advertised with that SPI Pool
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
Identifier in the SFRIR-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.
The Classifier is responsible for determining to which packet flow a The Classifier is responsible for determining to which packet flow a
skipping to change at page 28, line 36 skipping to change at page 30, line 36
similar way. The RT field is used to indicate a set of Service similar way. The RT field is used to indicate a set of Service
Functions from which all choices must be made. Functions from which all choices must be made.
7.5. Flow Spec for SFC Classifiers 7.5. Flow Spec for SFC Classifiers
[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 8: 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 8: 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 30, line 13 skipping to change at page 32, line 13
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. MPLS labels [I-D.farrel-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 31, line 12 skipping to change at page 33, line 12
Note that the MPLS representation of the logical NSH may be used even Note that the MPLS representation of the logical NSH may be used even
if the tunnel is not an MPLS tunnel. Conversely, MPLS tunnels may be if the tunnel is not an MPLS tunnel. Conversely, MPLS tunnels may be
used to carry other encodings of the logical NSH (specifically, the used to carry other encodings of the logical NSH (specifically, the
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 two If bit 1 is set in the in the SPI/SI Representation sub-TLV then
labels in the label stack are used to indicate the SPI and SI to labels in the MPLS label stack are used to indicate SFC forwarding
achieve the semantics of a logical NSH. The label stack appears as and processing instructions to achieve the semantics of a logical
shown in Figure 9. NSH. The label stack is encoded as shown in [I-D.farrel-mpls-sfc].
---------------
| Tunnel Labels |
+---------------+
~ Optional ~
~ Entropy Label ~
+---------------+
| SPI Label |
+---------------+
| SI Label |
+---------------+
| |
~ Payload ~
| |
---------------
Figure 9: The MPLS Label Stack with Logical NSH
As can be seen from the figure, the top of the label stack comprises
the labels necessary to deliver the packet over the MPLS tunnel
between SFFs. Any of the MPLS encapsulations defined for the Tunnel
Encapsulation may be used (i.e., MPLS, MPLS in GRE, and MPLS in VXLAN
or GPE) and an entropy label ([RFC6790]) may also be present as
described in Section 7.1.
Under these labels comes the SPI label stack entry and the SI label
stack entry. Each of these label stack entries is formatted as
normal (see [RFC3032] and the fields are encoded as follows:
Label: The Label field contains the value of the SPI or SI encoded
as a 20 bit integer. Since the SI only requires 8 bits, it is
right-justified with the high order 12 bits set to zero. Note
that an SPI as defined by [I-D.ietf-sfc-nsh] can be encoded in 3
octets (i.e., 24 bits) but that the Label field allows for only 20
bits. Thus, a system using MPLS representation of the logical NSH
MUST NOT assign SPI values greater than 2^20 - 1.
TC: The TC bits have no meaning. They SHOULD be set to zero and
MUTS be ignored.
S: The bottom of stack flag has its usual meaning in MPLS. It MUST
be clear in the SPI label stack entry and MAY be set in the SI
label stack entry depending on whether the payload is MPLS (not
set) or not MPLS (set).
TTL: The TTL field in the SPI label stack entry SHOULD be set to 1.
The TTL in SI label stack entry (called the SI TTL) is used to
count progress along the SFP and to prevent looping. It is
decremented once for each hop in the SFP, i.e., for each SFI
executed.
* When a Classifier places a packet onto an SFP it MUST set the
SI TTL to a value between 1 and 255. It should set this
according to the expected length of the SFP, but it MAY set it
to a larger value according to local configuration.
* When an SFF receives a packet from the Classifier or another
SFF it MUST discard any packets with SI TTL set to zero. It
SHOULD log such occurrences, but MUST apply rate limiting to
any such logs.
* An SFF MUST decrement the SI TTL by one each time it sends the 7.7. MPLS Label Swapping/Stacking Operation
packet to an SFI (local or remote) or to another SFF
* If an SFF decrements the SI TTL to zero it MUST NOT send the When a classifier constructs an MPLS label stack for an SFP it starts
packet, but MUST discard the packet. It SHOULD log such with that SFP' last hop. If the last hop requires an {SPI, SI} label
occurrences, but MUST apply rate limiting to any such logs. 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
hop requires a {context label, SFI label} label pair for label
stcking it selects a specific SFIR and pushes that SFIR's SFI label
and context label onto the MPLS label stack.
* SFIs MUST ignore the SI TTL, but MUST mirror it back to the SFF The classifier then moves sequentially back through the SFP one hop
unmodified along with the SI (which may have been changed). at a time. For each hop, if the hop requires an {SPI, SI]} and there
is an {SPI, SI} at the top of the MPLS label stack, the SI is set to
the SI value of the current hop. If there is not an {SPI, SI} at the
top of the MPLS label stack, it pushes the SI (set to the SI value of
the current hop) and the SFP's SPI onto the MPLS label stack.
* If a Classifier along the SFP makes any change to the intended If the hop requires a {context label, SFI label}, it selects a
path of the packet including for looping, jumping, or branching specific SFIR and pushes that SFIR's SFI label and context label onto
(see Section 6 and Section 6.1) it MUST NOT change the SI TTL the MPLS label stack.
of the packet. In particular, every component of the SFC
system MUST NOT increase the SI TTL value.
8. Examples 8. Examples
Assume we have a service function overlay network with four SFFs Assume we have a service function overlay network with four SFFs
(SFF1, SFF3, SFF3, and SFF4). The SFFs have addresses in the (SFF1, SFF3, SFF3, and SFF4). The SFFs have addresses in the
underlay network as follows: underlay network as follows:
SFF1 192.0.2.1 SFF1 192.0.2.1
SFF2 192.0.2.2 SFF2 192.0.2.2
SFF3 192.0.2.3 SFF3 192.0.2.3
skipping to change at page 33, line 21 skipping to change at page 34, line 16
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 10. 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 33, line 45 skipping to change at page 34, line 40
---------- --------- --------- ---------- --------- ---------
| 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 10: 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 39, 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 11. 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 11: 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 40, 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 11 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 41, 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 ach subtended from a different SFF as shown in that the SFIs are ach subtended from a different SFF as shown in
Figure 12. 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 42, 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 12: 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 44, 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 13 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 44, 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 13: 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 48, line 5 skipping to change at page 49, line 5
o Type o Type
o Name o Name
o Reference Document or Contact o Reference Document or Contact
o Registration Date o Registration Date
The registry should initially be populated as follows: The registry should initially be populated as follows:
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 TLV | [This.I-D] | Date-to-be-set
4 | MPLS Swapping/Stacking | [This.I-D] | Date-to-be-set
5 | 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 49, line 33 skipping to change at page 50, line 35
o Registration Date o Registration Date
The registry should initially be populated as follows: The registry should initially be populated as follows:
Value | Name | Reference | Date Value | Name | Reference | Date
------+-----------------------+---------------+--------------- ------+-----------------------+---------------+---------------
1 | Change Sequence | [This.I-D] | Date-to-be-set 1 | Change Sequence | [This.I-D] | Date-to-be-set
10.6. New Generic Transitive Experimental Use Extended Community Sub- 10.6. New Generic Transitive Experimental Use Extended Community Sub-
Type Types
IANA maintains a registry of "Border Gateway Protocol (BGP) IANA maintains a registry of "Border Gateway Protocol (BGP)
Parameters" with a subregistry of "Generic Transitive Experimental Parameters" with a subregistry of "Generic Transitive Experimental
Use Extended Community Sub-Type". IANA is requested to assign a new Use Extended Community Sub-Type". IANA is requested to assign a new
sub-type called "Flow spec for SFC classifiers" (TBD4 in this sub-types as follows:
document) with this document as the reference.
"Flow Spec for SFC Classifiers" (TBD4 in this document) with this
document as the reference.
"SFI Pool Identifier" (TBD6 in this document) with this document
as the reference.
"MPLS Label Stack Mixed Swapping/Stacking Labels" (TBD7 in this
document) with this document as the reference.
10.7. SPI/SI Representation 10.7. SPI/SI Representation
IANA is requested to assign a codepoint from the "BGP Tunnel IANA is requested to assign a codepoint from the "BGP Tunnel
Encapsulation Attribute Sub-TLVs" registry for the "SPI/SI Encapsulation Attribute Sub-TLVs" registry for the "SPI/SI
Representation Sub-TLV" (TBD5 in this document) with this document Representation Sub-TLV" (TBD5 in this document) with this document
being the reference. being the reference.
11. Contributors 11. Contributors
Stuart Mackie Stuart Mackie
Juniper Networks Juniper Networks
Email: wsmackie@juinper.net Email: wsmackie@juinper.net
Keyur Patel Keyur Patel
Arrcus, Inc. Arrcus, Inc.
Email: keyur@arrcus.com Email: keyur@arrcus.com
Avinash Lingala
AT&T
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.
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-07 Encapsulation Attribute", draft-ietf-idr-tunnel-encaps-07
(work in progress), July 2017. (work in progress), July 2017.
[I-D.ietf-sfc-nsh] [I-D.ietf-sfc-nsh]
Quinn, P., Elzur, U., and C. Pignataro, "Network Service Quinn, P., Elzur, U., and C. Pignataro, "Network Service
Header (NSH)", draft-ietf-sfc-nsh-23 (work in progress), Header (NSH)", draft-ietf-sfc-nsh-27 (work in progress),
September 2017. October 2017.
[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>.
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001,
<https://www.rfc-editor.org/info/rfc3032>.
[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>.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
2006, <https://www.rfc-editor.org/info/rfc4364>. 2006, <https://www.rfc-editor.org/info/rfc4364>.
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
skipping to change at page 51, line 26 skipping to change at page 52, line 36
Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009,
<https://www.rfc-editor.org/info/rfc5575>. <https://www.rfc-editor.org/info/rfc5575>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
13.2. Informative References 13.2. Informative References
[I-D.farrel-mpls-sfc]
Farrel, A., Bryant, S., and J. Drake, "An MPLS-Based
Forwarding Plane for Service Function Chaining", draft-
farrel-mpls-sfc-02 (work in progress), October 2017.
[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. 45 change blocks. 
174 lines changed or deleted 222 lines changed or added

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