draft-ietf-bess-nsh-bgp-control-plane-08.txt   draft-ietf-bess-nsh-bgp-control-plane-09.txt 
BESS Working Group A. Farrel BESS Working Group A. Farrel
Internet-Draft Old Dog Consulting Internet-Draft Old Dog Consulting
Intended status: Standards Track J. Drake Intended status: Standards Track J. Drake
Expires: September 2, 2019 E. Rosen Expires: September 7, 2019 E. Rosen
Juniper Networks Juniper Networks
J. Uttaro J. Uttaro
AT&T AT&T
L. Jalil L. Jalil
Verizon Verizon
March 1, 2019 March 6, 2019
BGP Control Plane for NSH SFC BGP Control Plane for NSH SFC
draft-ietf-bess-nsh-bgp-control-plane-08 draft-ietf-bess-nsh-bgp-control-plane-09
Abstract Abstract
This document describes the use of BGP as a control plane for This document describes the use of BGP as a control plane for
networks that support Service Function Chaining (SFC). The document networks that support Service Function Chaining (SFC). The document
introduces a new BGP address family called the SFC AFI/SAFI with two introduces a new BGP address family called the SFC AFI/SAFI with two
route types. One route type is originated by a node to advertise route types. One route type is originated by a node to advertise
that it hosts a particular instance of a specified service function. that it hosts a particular instance of a specified service function.
This route type also provides "instructions" on how to send a packet This route type also provides "instructions" on how to send a packet
to the hosting node in a way that indicates that the service function to the hosting node in a way that indicates that the service function
skipping to change at page 1, line 49 skipping to change at page 1, line 49
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 2, 2019. This Internet-Draft will expire on September 7, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 28 skipping to change at page 2, line 28
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Overview of Service Function Chaining . . . . . . . . . . 6 2.1. Overview of Service Function Chaining . . . . . . . . . . 6
2.2. Control Plane Overview . . . . . . . . . . . . . . . . . 7 2.2. Control Plane Overview . . . . . . . . . . . . . . . . . 7
3. BGP SFC Routes . . . . . . . . . . . . . . . . . . . . . . . 10 3. BGP SFC Routes . . . . . . . . . . . . . . . . . . . . . . . 11
3.1. Service Function Instance Route (SFIR) . . . . . . . . . 11 3.1. Service Function Instance Route (SFIR) . . . . . . . . . 12
3.1.1. SFI Pool Identifier Extended Community . . . . . . . 12 3.1.1. SFI Pool Identifier Extended Community . . . . . . . 13
3.1.2. MPLS Mixed Swapping/Stacking Extended Community . . . 13 3.1.2. MPLS Mixed Swapping/Stacking Extended Community . . . 14
3.2. Service Function Path Route (SFPR) . . . . . . . . . . . 13 3.2. Service Function Path Route (SFPR) . . . . . . . . . . . 14
3.2.1. The SFP Attribute . . . . . . . . . . . . . . . . . . 14 3.2.1. The SFP Attribute . . . . . . . . . . . . . . . . . . 15
3.2.2. General Rules For The SFP Attribute . . . . . . . . . 19 3.2.2. General Rules For The SFP Attribute . . . . . . . . . 20
4. Mode of Operation . . . . . . . . . . . . . . . . . . . . . . 20 4. Mode of Operation . . . . . . . . . . . . . . . . . . . . . . 21
4.1. Route Targets . . . . . . . . . . . . . . . . . . . . . . 20 4.1. Route Targets . . . . . . . . . . . . . . . . . . . . . . 21
4.2. Service Function Instance Routes . . . . . . . . . . . . 20 4.2. Service Function Instance Routes . . . . . . . . . . . . 21
4.3. Service Function Path Routes . . . . . . . . . . . . . . 21 4.3. Service Function Path Routes . . . . . . . . . . . . . . 21
4.4. Classifier Operation . . . . . . . . . . . . . . . . . . 23 4.4. Classifier Operation . . . . . . . . . . . . . . . . . . 23
4.5. Service Function Forwarder Operation . . . . . . . . . . 23 4.5. Service Function Forwarder Operation . . . . . . . . . . 24
4.5.1. Processing With 'Gaps' in the SI Sequence . . . . . . 24 4.5.1. Processing With 'Gaps' in the SI Sequence . . . . . . 25
5. Selection in Service Function Paths . . . . . . . . . . . . . 25 5. Selection in Service Function Paths . . . . . . . . . . . . . 26
6. Looping, Jumping, and Branching . . . . . . . . . . . . . . . 27 6. Looping, Jumping, and Branching . . . . . . . . . . . . . . . 28
6.1. Protocol Control of Looping, Jumping, and Branching . . . 27 6.1. Protocol Control of Looping, Jumping, and Branching . . . 28
6.2. Implications for Forwarding State . . . . . . . . . . . . 28 6.2. Implications for Forwarding State . . . . . . . . . . . . 29
7. Advanced Topics . . . . . . . . . . . . . . . . . . . . . . . 29 7. Advanced Topics . . . . . . . . . . . . . . . . . . . . . . . 29
7.1. Preserving Entropy . . . . . . . . . . . . . . . . . . . 29 7.1. Correlating Service Function Path Instances . . . . . . . 29
7.2. Correlating Service Function Path Instances . . . . . . . 29 7.2. Considerations for Stateful Service Functions . . . . . . 30
7.3. Considerations for Stateful Service Functions . . . . . . 30 7.3. VPN Considerations and Private Service Functions . . . . 31
7.4. VPN Considerations and Private Service Functions . . . . 31 7.4. Flow Spec for SFC Classifiers . . . . . . . . . . . . . . 32
7.5. Flow Spec for SFC Classifiers . . . . . . . . . . . . . . 31 7.5. Choice of Data Plane SPI/SI Representation . . . . . . . 33
7.6. Choice of Data Plane SPI/SI Representation . . . . . . . 33 7.5.1. MPLS Representation of the SPI/SI . . . . . . . . . . 34
7.6.1. MPLS Representation of the SPI/SI . . . . . . . . . . 34
7.7. MPLS Label Swapping/Stacking Operation . . . . . . . . . 34 7.6. MPLS Label Swapping/Stacking Operation . . . . . . . . . 34
7.8. Support for MPLS-Encapsulated NSH Packets . . . . . . . . 34 7.7. Support for MPLS-Encapsulated NSH Packets . . . . . . . . 35
8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 35 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 35
8.1. Example Explicit SFP With No Choices . . . . . . . . . . 36 8.1. Example Explicit SFP With No Choices . . . . . . . . . . 37
8.2. Example SFP With Choice of SFIs . . . . . . . . . . . . . 37 8.2. Example SFP With Choice of SFIs . . . . . . . . . . . . . 37
8.3. Example SFP With Open Choice of SFIs . . . . . . . . . . 38 8.3. Example SFP With Open Choice of SFIs . . . . . . . . . . 38
8.4. Example SFP With Choice of SFTs . . . . . . . . . . . . . 38 8.4. Example SFP With Choice of SFTs . . . . . . . . . . . . . 38
8.5. Example Correlated Bidirectional SFPs . . . . . . . . . . 39 8.5. Example Correlated Bidirectional SFPs . . . . . . . . . . 39
8.6. Example Correlated Asymmetrical Bidirectional SFPs . . . 39 8.6. Example Correlated Asymmetrical Bidirectional SFPs . . . 39
8.7. Example Looping in an SFP . . . . . . . . . . . . . . . . 40 8.7. Example Looping in an SFP . . . . . . . . . . . . . . . . 40
8.8. Example Branching in an SFP . . . . . . . . . . . . . . . 41 8.8. Example Branching in an SFP . . . . . . . . . . . . . . . 41
8.9. Examples of SFPs with Stateful Service Functions . . . . 41 8.9. Examples of SFPs with Stateful Service Functions . . . . 41
8.9.1. Forward and Reverse Choice Made at the SFF . . . . . 42 8.9.1. Forward and Reverse Choice Made at the SFF . . . . . 42
8.9.2. Parallel End-to-End SFPs with Shared SFF . . . . . . 43 8.9.2. Parallel End-to-End SFPs with Shared SFF . . . . . . 43
8.9.3. Parallel End-to-End SFPs with Separate SFFs . . . . . 44 8.9.3. Parallel End-to-End SFPs with Separate SFFs . . . . . 45
8.9.4. Parallel SFPs Downstream of the Choice . . . . . . . 46 8.9.4. Parallel SFPs Downstream of the Choice . . . . . . . 47
9. Security Considerations . . . . . . . . . . . . . . . . . . . 49 9. Security Considerations . . . . . . . . . . . . . . . . . . . 50
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 51
10.1. New BGP AF/SAFI . . . . . . . . . . . . . . . . . . . . 50 10.1. New BGP AF/SAFI . . . . . . . . . . . . . . . . . . . . 51
10.2. New BGP Path Attribute . . . . . . . . . . . . . . . . . 50 10.2. New BGP Path Attribute . . . . . . . . . . . . . . . . . 51
10.3. New SFP Attribute TLVs Type Registry . . . . . . . . . . 50 10.3. New SFP Attribute TLVs Type Registry . . . . . . . . . . 51
10.4. New SFP Association Type Registry . . . . . . . . . . . 51 10.4. New SFP Association Type Registry . . . . . . . . . . . 52
10.5. New Service Function Type Registry . . . . . . . . . . . 51 10.5. New Service Function Type Registry . . . . . . . . . . . 53
10.6. New Generic Transitive Experimental Use Extended 10.6. New Generic Transitive Experimental Use Extended
Community Sub-Types . . . . . . . . . . . . . . . . . . 52 Community Sub-Types . . . . . . . . . . . . . . . . . . 54
10.7. New BGP Transitive Extended Community Types . . . . . . 52 10.7. New BGP Transitive Extended Community Types . . . . . . 54
10.8. SPI/SI Representation . . . . . . . . . . . . . . . . . 53 10.8. SPI/SI Representation . . . . . . . . . . . . . . . . . 54
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 53 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 54
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 53 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 55
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 53 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 55
13.1. Normative References . . . . . . . . . . . . . . . . . . 54 13.1. Normative References . . . . . . . . . . . . . . . . . . 55
13.2. Informative References . . . . . . . . . . . . . . . . . 55 13.2. Informative References . . . . . . . . . . . . . . . . . 56
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 55 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 56
1. Introduction 1. Introduction
As described in [RFC7498], the delivery of end-to-end services can As described in [RFC7498], the delivery of end-to-end services can
require a packet to pass through a series of Service Functions (SFs) require a packet to pass through a series of Service Functions (SFs)
(e.g., WAN and application accelerators, Deep Packet Inspection (DPI) (e.g., WAN and application accelerators, Deep Packet Inspection (DPI)
engines, firewalls, TCP optimizers, and server load balancers) in a engines, firewalls, TCP optimizers, and server load balancers) in a
specified order: this is termed "Service Function Chaining" (SFC). specified order: this is termed "Service Function Chaining" (SFC).
There are a number of issues associated with deploying and There are a number of issues associated with deploying and
maintaining service function chaining in production networks, which maintaining service function chaining in production networks, which
skipping to change at page 6, line 41 skipping to change at page 6, line 41
sets the SI to the value of the SI for the first hop in the SFP, and sets the SI to the value of the SI for the first hop in the SFP, and
then prepends a Network Services Header (NSH) [RFC8300] containing then prepends a Network Services Header (NSH) [RFC8300] containing
the assigned SPI/SI to that packet. Note that the Classifier and the the assigned SPI/SI to that packet. Note that the Classifier and the
node that hosts the first Service Function in a Service Function Path node that hosts the first Service Function in a Service Function Path
need not be located at the same point in the service function overlay need not be located at the same point in the service function overlay
network. network.
Note that the presence of the NSH can make it difficult for nodes in Note that the presence of the NSH can make it difficult for nodes in
the underlay network to locate the fields in the original packet that the underlay network to locate the fields in the original packet that
would normally be used to constrain equal cost multipath (ECMP) would normally be used to constrain equal cost multipath (ECMP)
forwarding. Therefore, it is recommended, as described in forwarding. Therefore, it is recommended that the node prepending
Section 7.1, that the node prepending the NSH also provide some form the NSH also provide some form of entropy indicator that can be used
of entropy indicator that can be used in the underlay network. in the underlay network. How this indicator is generated and
supplied, and how an SFF generates a new entropy indicator when it
forwards a packet to the next SFF are out of scope of this document.
The Service Function Forwarder (SFF) receives a packet from the The Service Function Forwarder (SFF) receives a packet from the
previous node in a Service Function Path, removes the packet's link previous node in a Service Function Path, removes the packet's link
layer or tunnel encapsulation and hands the packet and the NSH to the layer or tunnel encapsulation and hands the packet and the NSH to the
Service Function Instance for processing. The SFI has no knowledge Service Function Instance for processing. The SFI has no knowledge
of the SFP. of the SFP.
When the SFF receives the packet and the NSH back from the SFI it When the SFF receives the packet and the NSH back from the SFI it
MUST select the next SFI along the path using the SPI and SI in the must select the next SFI along the path using the SPI and SI in the
NSH and potentially choosing between multiple SFIs (possibly of NSH and potentially choosing between multiple SFIs (possibly of
different Service Function Types) as described in Section 5. In the different Service Function Types) as described in Section 5. In the
normal case the SPI remains unchanged and the SI will have been normal case the SPI remains unchanged and the SI will have been
decremented to indicate the next SF along the path. But other decremented to indicate the next SF along the path. But other
possibilities exist if the SF makes other changes to the NSH through possibilities exist if the SF makes other changes to the NSH through
a process of re-classification: a process of re-classification:
o The SI in the NSH may indicate: o The SI in the NSH may indicate:
* A previous SF in the path: known as "looping" (see Section 6). * A previous SF in the path: known as "looping" (see Section 6).
skipping to change at page 7, line 39 skipping to change at page 7, line 42
An SFF receiving an SI that is unknown in the context of the SPI can An SFF receiving an SI that is unknown in the context of the SPI can
reduce the value to the next meaningful SI value in the SFP indicated reduce the value to the next meaningful SI value in the SFP indicated
by the SPI. If no such value exists or if the SFF does not support by the SPI. If no such value exists or if the SFF does not support
this function, the SFF drops the packet and should log the event: this function, the SFF drops the packet and should log the event:
such logs are also subject to rate limits. such logs are also subject to rate limits.
The SFF then selects an SFI that provides the SF denoted by the SPI/ The SFF then selects an SFI that provides the SF denoted by the SPI/
SI, and forwards the packet to the SFF that supports that SFI. SI, and forwards the packet to the SFF that supports that SFI.
[RFC8300] makes it clear that the intended scope is for use within a
single provider's operational domain.
2.2. Control Plane Overview 2.2. Control Plane Overview
To accomplish the function described in Section 2.1, this document To accomplish the function described in Section 2.1, this document
introduces the Service Function Type (SFT) that is the category of SF introduces the Service Function Type (SFT) that is the category of SF
that is supported by an SFF (such as "firewall"). An IANA registry that is supported by an SFF (such as "firewall"). An IANA registry
of Service Function Types is introduced in Section 10. An SFF may of Service Function Types is introduced in Section 10. An SFF may
support SFs of multiple different SFTs, and may support multiple SFIs support SFs of multiple different SFTs, and may support multiple SFIs
of each SF. of each SF.
This document also introduces a new BGP AFI/SAFI (values to be This document also introduces a new BGP AFI/SAFI (values to be
skipping to change at page 8, line 39 skipping to change at page 8, line 43
When choosing the next SFI in a path, the SFF uses the SPI and SI as When choosing the next SFI in a path, the SFF uses the SPI and SI as
well as the SFT to choose among the SFIs, applying, for example, a well as the SFT to choose among the SFIs, applying, for example, a
load balancing algorithm or direct knowledge of the underlay network load balancing algorithm or direct knowledge of the underlay network
topology as described in Section 4. topology as described in Section 4.
The SFF then encapsulates the packet using the encapsulation The SFF then encapsulates the packet using the encapsulation
specified by the SFIR of the selected SFI and forwards the packet. specified by the SFIR of the selected SFI and forwards the packet.
See Figure 1. See Figure 1.
Thus the SFF can be seen as a gateway in the underlay network through Thus the SFF can be seen as a portal in the underlay network through
which a particular SFI is reached. which a particular SFI is reached.
Figure 1 shows a reference model for the SFC architecture. There are Figure 1 shows a reference model for the SFC architecture. There are
four SFFs (SFF-1 through SFF-4) connected by tunnels across the four SFFs (SFF-1 through SFF-4) connected by tunnels across the
underlay network. Packets arrive at a Classifier and are channelled underlay network. Packets arrive at a Classifier and are channelled
along SFPs to destinations reachable through SFF-4. along SFPs to destinations reachable through SFF-4.
SFF-1 and SFF-4 each have one instance of one SF attached (SFa and SFF-1 and SFF-4 each have one instance of one SF attached (SFa and
SFe). SFF-2 has two types of SF attached: there is one instance of SFe). SFF-2 has two types of SF attached: there is one instance of
one (SFc), and three instances of the other (SFb). SFF-3 has just one (SFc), and three instances of the other (SFb). SFF-3 has just
one instance of an SF (SFd), but it in this case the type of SFd is one instance of an SF (SFd), but it in this case the type of SFd is
the same type as SFb (SFTx). the same type as SFb (SFTx).
This figure demonstrates how load balancing can be achieved. Suppose This figure demonstrates how load balancing can be achieved by
an SFC needs to include SFa, an SF of type SFTx, and SFd. A number creating several SFPs that satisfy the same SFC. Suppose an SFC
of SFPs can be constructed using any instance of SFb or using SFd. needs to include SFa, an SF of type SFTx, and SFc. A number of SFPs
can be constructed using any instance of SFb or using SFd. Load
balancing may be applied at two places:
o The Classifier may distribute different flows onto different SFPs
to share the load in the network and across SFIs.
o SFF-2 may distribute different flows (on the same SFP) to
different instances of SFb to share the processing load.
Note that, for convenience and clarity, Figure 1 shows only a few
tunnels between SFFs. There could be a full mesh of such tunnels, or
more likely, a selection of tunnels connecting key SFFs to enable the
construction of SFPs and to balance load and traffic in the network.
Packets Packets
| | | | | |
| | |
| | |
------------ ------------
| | | |
| Classifier | | Classifier |
| | | |
------------ ------+-----
|
| |
------- --------- ------- ---+--- --------- -------
| | Tunnel | | | | | | Tunnel | | | |
| SFF-1 |===============| SFF-2 |=========| SFF-4 | | SFF-1 |===============| SFF-2 |=========| SFF-4 |
| | | | | | | | | | | |
| | -+-----+- | | | | -+-----+- | |
| | ,,,,,,,,,,,,,,/,, \ | | | | ,,,,,,,,,,,,,,/,, \ | |
| | ' .........../. ' ..\...... | | | | ' .........../. ' ..\...... | |
| | ' : SFb / : ' : \ SFc : | | | | ' : SFb / : ' : \ SFc : | |
| | ' : ---+- : ' : --+-- : | | | | ' : ---+- : ' : --+-- : | |
| | ' : -| SFI | : ' : | SFI | : | | | | ' : -| SFI | : ' : | SFI | : | |
| | ' : -| ----- : ' : ----- : | | | | ' : -| ----- : ' : ----- : | |
| | ' : | ----- : ' ......... | | | | ' : | ----- : ' ......... | |
| | ' : ----- : ' | | | | ' : ----- : ' | |
| | ' ............. ' | |--- Dests | | ' ............. ' | |--- Dests
| | ' ' | |--- Dests | | ' ' | |--- Dests
| | ' ' | |
| | ' ......... ' | | | | ' ......... ' | |
| | ' : ----- : ' | | | | ' : ----- : ' | |
| | ' : | SFI | : ' | | | | ' : | SFI | : ' | |
| | ' : --+-- : ' | | | | ' : --+-- : ' | |
| | ' :SFd | : ' | | | | ' :SFd | : ' | |
| | ' ....|.... ' | | | | ' ....|.... ' | |
| | ' | ' | | | | ' | ' | |
| | ' SFTx | ' | | | | ' SFTx | ' | |
| | ',,,,,,,,|,,,,,,,,' | | | | ',,,,,,,,|,,,,,,,,' | |
| | | | | | | | | |
| | | | |
| | ---+--- | | | | ---+--- | |
| | | | | | | | | | | |
| |======| SFF-3 |====================| | | |======| SFF-3 |====================| |
---+--- | | ---+--- ---+--- | | ---+---
| ------- | | ------- |
....|.... ....|.... ....|.... ....|....
: | SFa: : | SFe: : | SFa: : | SFe:
: --+-- : : --+-- : : --+-- : : --+-- :
: | SFI | : : | SFI | : : | SFI | : : | SFI | :
: ----- : : ----- : : ----- : : ----- :
......... ......... ......... .........
Figure 1: The SFC Architecture Reference Model Figure 1: The SFC Architecture Reference Model
As previously noted, [RFC8300] makes it clear that the mechanisms it
defines are intended for use within a single provider's operational
domain. This reduces the requirements on the control plane function.
3. BGP SFC Routes 3. BGP SFC Routes
This document defines a new AFI/SAFI for BGP, known as "SFC", with an This document defines a new AFI/SAFI for BGP, known as "SFC", with an
NLRI that is described in this section. NLRI that is described in this section.
The format of the SFC NLRI is shown in Figure 2. The format of the SFC NLRI is shown in Figure 2.
+---------------------------------------+ +---------------------------------------+
| Route Type (2 octets) | | Route Type (2 octets) |
+---------------------------------------+ +---------------------------------------+
skipping to change at page 11, line 20 skipping to change at page 12, line 11
and a Subsequent Address Family Identifier (SAFI) of TBD2. The NLRI and a Subsequent Address Family Identifier (SAFI) of TBD2. The NLRI
field in the MP_REACH_NLRI/MP_UNREACH_NLRI attribute contains the SFC field in the MP_REACH_NLRI/MP_UNREACH_NLRI attribute contains the SFC
NLRI, encoded as specified above. NLRI, encoded as specified above.
In order for two BGP speakers to exchange SFC NLRIs, they MUST use In order for two BGP speakers to exchange SFC NLRIs, they MUST use
BGP Capabilities Advertisements to ensure that they both are capable BGP Capabilities Advertisements to ensure that they both are capable
of properly processing such NLRIs. This is done as specified in of properly processing such NLRIs. This is done as specified in
[RFC4760], by using capability code 1 (Multiprotocol BGP) with an AFI [RFC4760], by using capability code 1 (Multiprotocol BGP) with an AFI
of TBD1 and a SAFI of TBD2. of TBD1 and a SAFI of TBD2.
The nexthop field of the MP_REACH_NLRI attribute of the SFC NLRI MUST
be set to loopback address of the advertising SFF.
3.1. Service Function Instance Route (SFIR) 3.1. Service Function Instance Route (SFIR)
Figure 3 shows the Route Type specific NLRI of the SFIR. Figure 3 shows the Route Type specific NLRI of the SFIR.
+--------------------------------------------+ +--------------------------------------------+
| Route Distinguisher (RD) (8 octets) | | Route Distinguisher (RD) (8 octets) |
+--------------------------------------------+ +--------------------------------------------+
| Service Function Type (2 octets) | | Service Function Type (2 octets) |
+--------------------------------------------+ +--------------------------------------------+
skipping to change at page 11, line 41 skipping to change at page 12, line 35
Per [RFC4364] the RD field comprises a two byte Type field and a six Per [RFC4364] the RD field comprises a two byte Type field and a six
byte Value field. Two SFIs of the same SFT MUST be associated with byte Value field. Two SFIs of the same SFT MUST be associated with
different RDs, where the association of an SFI with an RD is different RDs, where the association of an SFI with an RD is
determined by provisioning. If two SFIRs are originated from determined by provisioning. If two SFIRs are originated from
different administrative domains, they MUST have different RDs. In different administrative domains, they MUST have different RDs. In
particular, SFIRs from different VPNs (for different service function particular, SFIRs from different VPNs (for different service function
overlay networks) MUST have different RDs, and those RDs MUST be overlay networks) MUST have different RDs, and those RDs MUST be
different from any non-VPN SFIRs. different from any non-VPN SFIRs.
The Service Function Type identifies a service function type, e.g., The Service Function Type identifies the functions/features of
classifier, firewall, load balancer, etc. There may be several SFIs service function can offer, e.g., classifier, firewall, load
that can perform a given Service Function. Each node hosting an SFI balancer, etc. There may be several SFIs that can perform a given
MUST originate an SFIR for each type of SF that it hosts, and it may Service Function. Each node hosting an SFI MUST originate an SFIR
advertise an SFIR for each instance of each type of SF. The minimal for each type of SF that it hosts, and it may advertise an SFIR for
advertisement allows construction of valid SFPs and leaves the each instance of each type of SF. The minimal advertisement allows
selection of SFIs to the local SFF; the detailed advertisement may construction of valid SFPs and leaves the selection of SFIs to the
have scaling concerns, but allows a Controller that constructs an SFP local SFF; the detailed advertisement may have scaling concerns, but
to make an explicit choice of SFI. allows a Controller that constructs an SFP to make an explicit choice
of SFI.
The SFIR representing a given SFI will contain an NLRI with RD field The SFIR representing a given SFI will contain an NLRI with RD field
set to an RD as specified above, and with SFT field set to identify set to an RD as specified above, and with SFT field set to identify
that SFI's Service Function Type. The values for the SFT field are that SFI's Service Function Type. The values for the SFT field are
taken from a registry administered by IANA (see Section 10). A BGP taken from a registry administered by IANA (see Section 10). A BGP
Update containing one or more SFIRs MUST also include a Tunnel Update containing one or more SFIRs MUST also include a Tunnel
Encapsulation attribute [I-D.ietf-idr-tunnel-encaps]. If a data Encapsulation attribute [I-D.ietf-idr-tunnel-encaps]. If a data
packet needs to be sent to an SFI identified in one of the SFIRs, it packet needs to be sent to an SFI identified in one of the SFIRs, it
will be encapsulated as specified by the Tunnel Encapsulation will be encapsulated as specified by the Tunnel Encapsulation
attribute, and then transmitted through the underlay network. attribute, and then transmitted through the underlay network.
skipping to change at page 13, line 35 skipping to change at page 14, line 33
Figure 5: The MPLS Mixed Swapping/Stacking Extended Community Figure 5: The MPLS Mixed Swapping/Stacking Extended Community
Note that it is assumed that each SFF has one or more globally unique 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 SFC Context Labels and that the context label space and the SPI
address space are disjoint. address space are disjoint.
If an SFF supports SFP Traversal with an MPLS Label Stack it MUST If an SFF supports SFP Traversal with an MPLS Label Stack it MUST
include this extended community with the SFIRs that it advertises. include this extended community with the SFIRs that it advertises.
See Section 7.7 for a description of how this extended community is See Section 7.6 for a description of how this extended community is
used. used.
3.2. Service Function Path Route (SFPR) 3.2. Service Function Path Route (SFPR)
Figure 6 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) |
skipping to change at page 15, line 36 skipping to change at page 16, line 24
o The SFP attribute contains a sequence of one or more Hop TLVs. o The SFP attribute contains a sequence of one or more Hop TLVs.
Each Hop TLV contains all of the information about a single hop in Each Hop TLV contains all of the information about a single hop in
the SFP. the SFP.
o Each Hop TLV contains an SI value and a sequence of one or more o Each Hop TLV contains an SI value and a sequence of one or more
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).
Malformed SFP attributes, or those that in error in some way, MUST be Malformed SFP attributes, or those that are in error in some way,
handled as described in Section 6 of [RFC4271]. MUST be handled as described in Section 6 of [RFC4271].
3.2.1.1. The Association TLV 3.2.1.1. The Association TLV
The Association TLV is an optional TLV in the SFP attribute. It MAY The Association TLV is an optional TLV in the SFP attribute. It MAY
be present multiple times. Each occurrence provides an association be present multiple times. Each occurrence provides an association
with another SFP as advertised in another SFPR. The format of the with another SFP as advertised in another SFPR. The format of the
Association TLV is shown in Figure 7 Association TLV is shown in Figure 7
+--------------------------------------------+ +--------------------------------------------+
| Type = 1 (1 octet) | | Type = 1 (1 octet) |
+--------------------------------------------| +--------------------------------------------|
| 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) |
skipping to change at page 17, line 4 skipping to change at page 17, line 34
Association TLVs with unknown Association Type values SHOULD be Association TLVs with unknown Association Type values SHOULD be
ignored. Association TLVs that contain an Associated SFPR-RD value ignored. Association TLVs that contain an Associated SFPR-RD value
equal to the RD of the SFPR in which they are contained SHOULD be equal to the RD of the SFPR in which they are contained SHOULD be
ignored. If the Associated SPI is not equal to the SPI advertised in ignored. If the Associated SPI is not equal to the SPI advertised in
the SFPR indicated by the Associated SFPR-RD then the Association TLV the SFPR indicated by the Associated SFPR-RD then the Association TLV
SHOULD be ignored. SHOULD be ignored.
Note that when two SFPRs reference each other using the Association Note that when two SFPRs reference each other using the Association
TLV, one SFPR advertisement will be received before the other. TLV, one SFPR advertisement will be received before the other.
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.1.
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 8. 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) |
+--------------------------------------------| +--------------------------------------------|
skipping to change at page 19, line 11 skipping to change at page 19, line 47
RD of each SFIR advertised with that SFI Pool Identifier. An RD of each SFIR advertised with that SFI Pool Identifier. An
SFIR-RD of value zero has special meaning as described in SFIR-RD of value zero has special meaning as described in
Section 5. Each entry in the list is eight octets long, and the Section 5. Each entry in the list is eight octets long, and the
number of entries in the list can be deduced from the value of the number of entries in the list can be deduced from the value of the
Length field. Length field.
3.2.1.4. MPLS Swapping/Stacking TLV 3.2.1.4. MPLS Swapping/Stacking TLV
The MPLS Swapping/Stacking TLV (Type value 4) is a zero length sub- The MPLS Swapping/Stacking TLV (Type value 4) is a zero length sub-
TLV that is optionally present in the Hop TLV and is used when the TLV that is optionally present in the Hop TLV and is used when the
data representation is MPLS (see Section 7.6). When present it data representation is MPLS (see Section 7.5). When present it
indicates to the Classifier imposing an MPLS label stack that the indicates to the Classifier imposing an MPLS label stack that the
current hop is to use an {SFC Context Label, SF label} rather than an current hop is to use an {SFC Context Label, SF label} rather than an
{SPI, SF} label pair. See Section 7.7 for more details. {SPI, SF} label pair. See Section 7.6 for more details.
3.2.1.5. SFP Traversal With MPLS Label Stack TLV 3.2.1.5. SFP Traversal With MPLS Label Stack TLV
The SFP Traversal With MPLS Label Stack TLV (Type value 5) is a zero The SFP Traversal With MPLS Label Stack TLV (Type value 5) is a zero
length sub-TLV that can be carried in the SFP Attribute and indicates length sub-TLV that can be carried in the SFP Attribute and indicates
to the Classifier and the SFFs on the SFP that an MPLS labels stack to the Classifier and the SFFs on the SFP that an MPLS labels stack
with label swapping/stacking is to be used for packets traversing the with label swapping/stacking is to be used for packets traversing the
SFP. All of the SFF specified at each the SFP's hops MUST have SFP. All of the SFF specified at each the SFP's hops MUST have
advertised an MPLS Mixed Swapping/Stacking Extended Community (see advertised an MPLS Mixed Swapping/Stacking Extended Community (see
Section 3.1.2) for the SFP to be considered usable. Section 3.1.2) for the SFP to be considered usable.
skipping to change at page 20, line 34 skipping to change at page 21, line 24
Targets (RTs) [RFC4364]. Targets (RTs) [RFC4364].
Every BGP UPDATE containing an SFIR or SFPR carries one or more RTs. Every BGP UPDATE containing an SFIR or SFPR carries one or more RTs.
The RT carried by a particular SFIR or SFPR is determined by the The RT carried by a particular SFIR or SFPR is determined by the
provisioning of the route's originator. provisioning of the route's originator.
Every node in a service function overlay network is configured with Every node in a service function overlay network is configured with
one or more import RTs. Thus, each SFF will import only the SFPRs one or more import RTs. Thus, each SFF will import only the SFPRs
with matching RTs allowing the construction of multiple service with matching RTs allowing the construction of multiple service
function overlay networks or the instantiation of Service Function function overlay networks or the instantiation of Service Function
Chains within an L3VPN or EVPN instance (see Section 7.4). An SFF Chains within an L3VPN or EVPN instance (see Section 7.3). An SFF
that has a presence in multiple service function overlay networks that has a presence in multiple service function overlay networks
(i.e., imports more than one RT) may find it helpful to maintain (i.e., imports more than one RT) will usually maintain separate
separate forwarding state for each overlay network. forwarding state for each overlay network.
4.2. Service Function Instance Routes 4.2. Service Function Instance Routes
The SFIR (see Section 3.1) is used to advertise the existence and The SFIR (see Section 3.1) is used to advertise the existence and
location of a specific Service Function Instance and consists of: location of a specific Service Function Instance and consists of:
o The RT as just described. o The RT as just described.
o A Service Function Type (SFT) that is the type of service function o A Service Function Type (SFT) that is the type of service function
that is provided (such as "firewall"). that is provided (such as "firewall").
skipping to change at page 23, line 15 skipping to change at page 24, line 5
4.4. Classifier Operation 4.4. Classifier Operation
As shown in Figure 1, the Classifier is a component that is used to As shown in Figure 1, the Classifier is a component that is used to
assign packets to an SFP. assign packets to an SFP.
The Classifier is responsible for determining to which packet flow a The Classifier is responsible for determining to which packet flow a
packet belongs (usually by inspecting the packet header), imposing an packet belongs (usually by inspecting the packet header), imposing an
NSH, and initializing the NSH with the SPI of the selected SFP and NSH, and initializing the NSH with the SPI of the selected SFP and
the SI of its first hop. the SI of its first hop.
The Classifier may also provide an entropy indicator as described in
Section 7.1.
4.5. Service Function Forwarder Operation 4.5. Service Function Forwarder Operation
Each packet sent to an SFF is transmitted encapsulated in an NSH. Each packet sent to an SFF is transmitted encapsulated in an NSH.
The NSH includes an SPI and SI: the SPI indicates the SFPR The NSH includes an SPI and SI: the SPI indicates the SFPR
advertisement that announced the Service Function Path; the tuple advertisement that announced the Service Function Path; the tuple
SPI/SI indicates a specific hop in a specific path and maps to the SPI/SI indicates a specific hop in a specific path and maps to the
RD/SFT of a particular SFIR advertisement. RD/SFT of a particular SFIR advertisement.
When an SFF gets an SFPR advertisement it will first determine When an SFF gets an SFPR advertisement it will first determine
whether to import the route by examining the RT. If the SFPR is whether to import the route by examining the RT. If the SFPR is
skipping to change at page 25, line 34 skipping to change at page 26, line 24
5. Selection in Service Function Paths 5. Selection in Service Function Paths
As described in Section 2 the SPI/SI in the NSH passed back from an As described in Section 2 the SPI/SI in the NSH passed back from an
SFI to the SFF may leave the SFF with a choice of next hop SFTs, and SFI to the SFF may leave the SFF with a choice of next hop SFTs, and
a choice of SFIs for each SFT. That is, the SPI indicates an SFPR, a choice of SFIs for each SFT. That is, the SPI indicates an SFPR,
and the SI indicates an entry in that SFPR. Each entry in an SFPR is and the SI indicates an entry in that SFPR. Each entry in an SFPR is
a set of one or more SFT/SFIR-RD pairs. The SFF MUST choose one of a set of one or more SFT/SFIR-RD pairs. The SFF MUST choose one of
these, identify the SFF that supports the chosen SFI, and send the these, identify the SFF that supports the chosen SFI, and send the
packet to that next hop SFF. packet to that next hop SFF.
The choice may offered for load balancing across multiple SFIs, or The choice be may offered for load balancing across multiple SFIs, or
for discrimination between different actions necessary at a specific for discrimination between different actions necessary at a specific
hop in the SFP. Different SFT values may exist at a given hop in an hop in the SFP. Different SFT values may exist at a given hop in an
SFP to support several cases: SFP to support several cases:
o There may be multiple instances of similar service functions that o There may be multiple instances of similar service functions that
are distinguished by different SFT values. For example, firewalls are distinguished by different SFT values. For example, firewalls
made by vendor A and vendor B may need to be identified by made by vendor A and vendor B may need to be identified by
different SFT values because, while they have similar different SFT values because, while they have similar
functionality, their behavior is not identical. Then, some SFPs functionality, their behavior is not identical. Then, some SFPs
may limit the choice of SF at a given hop by specifying the SFT may limit the choice of SF at a given hop by specifying the SFT
skipping to change at page 29, line 10 skipping to change at page 29, line 47
needed to create the forwarding state. This is a matter of local needed to create the forwarding state. This is a matter of local
configuration and implementation: for example, an implementation configuration and implementation: for example, an implementation
could be configured to install forwarding state for specific could be configured to install forwarding state for specific
branching (identified by SPI and SI). branching (identified by SPI and SI).
7. Advanced Topics 7. Advanced Topics
This section highlights several advanced topics introduced elsewhere This section highlights several advanced topics introduced elsewhere
in this document. in this document.
7.1. Preserving Entropy 7.1. Correlating Service Function Path Instances
Forwarding decisions in the underlay network in the presence of equal
cost multipath (ECMP) are usually made by inspecting key invariant
fields in a packet header so that all packets from the same packet
flow receive the same forwarding treatment. However, when an NSH is
included in a packet, those key fields may be inaccessible. For
example, the fields may be too far inside the packet for a forwarding
engine to quickly find them and extract their values, or the node
performing the examination may be unaware of the format and meaning
of the NSH and so unable to parse far enough into the packet.
Various mechanisms exist within forwarding technologies to include an
"entropy indicator" within a forwarded packet. For example, in MPLS
there is the entropy label [RFC6790], while for encapsulations in UDP
the source port field is often used to carry an entropy indicator
(such as for MPLS in UDP [RFC7510]).
Implementations of this specification are RECOMMENDED to include an
entropy indicator within the packet's underlay network header, and
SHOULD preserve any entropy indicator from a received packet for use
on the same packet when it is forwarded along the path but MAY choose
to generate a new entropy indicator so long as the method used is
constant for all packets. Note that preserving per packet entropy
may require that the entropy indicator is passed to and returned by
the SFI to prevent the SFF from having to maintain per-packet state.
7.2. Correlating Service Function Path Instances
It is often useful to create bidirectional SFPs to enable packet It is often useful to create bidirectional SFPs to enable packet
flows to traverse the same set of SFs, but in the reverse order. flows to traverse the same set of SFs, but in the reverse order.
However, packets on SFPs in the data plane (per [RFC8300]) do not However, packets on SFPs in the data plane (per [RFC8300]) do not
contain a direction indicator, so each direction must use a different contain a direction indicator, so each direction must use a different
SPI. SPI.
As described in Section 3.2.1.1 an SFPR can contain one or more As described in Section 3.2.1.1 an SFPR can contain one or more
correlators encoded in Association TLVs. If the Association Type correlators encoded in Association TLVs. If the Association Type
indicates "Bidirectional SFP" then the SFP advertised in the SFPR is indicates "Bidirectional SFP" then the SFP advertised in the SFPR is
skipping to change at page 30, line 29 skipping to change at page 30, line 39
log this situation because it represents a Controller error. log this situation because it represents a Controller error.
Usage of a bidirectional SFP may be programmed into the Classifiers Usage of a bidirectional SFP may be programmed into the Classifiers
by the Controller. Alternatively, a Classifier may look at incoming by the Controller. Alternatively, a Classifier may look at incoming
packets on a bidirectional packet flow, extract the SPI from the packets on a bidirectional packet flow, extract the SPI from the
received NSH, and look up the SFPR to find the reverse direction SFP received NSH, and look up the SFPR to find the reverse direction SFP
to use when it sends packets. to use when it sends packets.
See Section 8 for an example of how this works. See Section 8 for an example of how this works.
7.3. Considerations for Stateful Service Functions 7.2. Considerations for Stateful Service Functions
Some service functions are stateful. That means that they build and Some service functions are stateful. That means that they build and
maintain state derived from configuration or from the packet flows maintain state derived from configuration or from the packet flows
that they handle. In such cases it can be important or necessary that they handle. In such cases it can be important or necessary
that all packets from a flow continue to traverse the same instance that all packets from a flow continue to traverse the same instance
of a service function so that the state can be leveraged and does not of a service function so that the state can be leveraged and does not
need to be regenerated. need to be regenerated.
In the case of bidirectional SFPs, it may be necessary to traverse In the case of bidirectional SFPs, it may be necessary to traverse
the same instances of a stateful service function in both directions. the same instances of a stateful service function in both directions.
skipping to change at page 31, line 27 skipping to change at page 31, line 38
that makes the choice in both directions. that makes the choice in both directions.
Note that this approach necessarily increases the amount of SFP state Note that this approach necessarily increases the amount of SFP state
in the network (i.e., there are more SFPs). It is possible to in the network (i.e., there are more SFPs). It is possible to
mitigate this effect by careful construction of SFPs built from a mitigate this effect by careful construction of SFPs built from a
concatenation of other SFPs. concatenation of other SFPs.
Section 8.9 includes some simple examples of SFPs for stateful Section 8.9 includes some simple examples of SFPs for stateful
service functions. service functions.
7.4. VPN Considerations and Private Service Functions 7.3. VPN Considerations and Private Service Functions
Likely deployments include reserving specific instances of Service Likely deployments include reserving specific instances of Service
Functions for specific customers or allowing customers to deploy Functions for specific customers or allowing customers to deploy
their own Service Functions within the network. Building Service their own Service Functions within the network. Building Service
Functions in such environments requires that suitable identifiers are Functions in such environments requires that suitable identifiers are
used to ensure that SFFs distinguish which SFIs can be used and which used to ensure that SFFs distinguish which SFIs can be used and which
cannot. cannot.
This problem is similar to how VPNs are supported and is solved in a This problem is similar to how VPNs are supported and is solved in a
similar way. The RT field is used to indicate a set of Service similar way. The RT field is used to indicate a set of Service
Functions from which all choices must be made. Functions from which all choices must be made.
7.5. Flow Spec for SFC Classifiers 7.4. Flow Spec for SFC Classifiers
[RFC5575] defines a set of BGP routes that can be used to identify [RFC5575] 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.
skipping to change at page 33, line 10 skipping to change at page 33, line 21
* If there is a choice of SFT in the hop indicated by the value * If there is a choice of SFT in the hop indicated by the value
of the SI (including SI = 0) then SFT = 0 means there is a free of the SI (including SI = 0) then SFT = 0 means there is a free
choice according to local policy of which SFT to use). choice according to local policy of which SFT to use).
* If there is no choice of SFT in the hop indicated by the value * If there is no choice of SFT in the hop indicated by the value
of SI, then SFT = 0 means that the value of the SFT at that hop of SI, then SFT = 0 means that the value of the SFT at that hop
as indicated in the SPFR for the indicated SPI MUST be used. as indicated in the SPFR for the indicated SPI MUST be used.
Note that each FlowSpec update MUST be tagged with the route target Note that each FlowSpec update MUST be tagged with the route target
of the overlay or VPN network for which it is intended. of the overlay or VPN network for which it is intended to put the
indicated SPI into context.
7.6. Choice of Data Plane SPI/SI Representation 7.5. Choice of Data Plane SPI/SI Representation
This document ties together the control and data planes of an SFC This document ties together the control and data planes of an SFC
overlay network through the use of the SPI/SI which is nominally overlay network through the use of the SPI/SI which is nominally
carried in the NSH of a given packet. However, in order to handle carried in the NSH of a given packet. However, in order to handle
situations in which the NSH is not ubiquitously deployed, it is also situations in which the NSH is not ubiquitously deployed, it is also
possible to use alternative data plane representations of the SPI/SI possible to use alternative data plane representations of the SPI/SI
by carrying the identical semantics in other protocol fields such as by carrying the identical semantics in other protocol fields such as
MPLS labels [I-D.ietf-mpls-sfc]. MPLS labels [I-D.ietf-mpls-sfc].
This document defines a new sub-TLV for the Tunnel Encapsulation This document defines a new sub-TLV for the Tunnel Encapsulation
skipping to change at page 33, line 37 skipping to change at page 33, line 49
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.
The following bits are defined by this document: The following bits are defined by this document:
Bit 0: If this bit is set the NSH is to be used to carry the SPI/SI Bit 0: If this bit is set the NSH is to be used to carry the SPI/SI
in the data plane. in the data plane.
Bit 1: If this bit is set two labels in an MPLS label stack are to Bit 1: If this bit is set two labels in an MPLS label stack are to
be used as described in Section 7.6.1. be used as described in Section 7.5.1.
If a given Tunnel TLV does not contain an SPI/SI Representation sub- If a given Tunnel TLV does not contain an SPI/SI Representation sub-
TLV then it MUST be processed as if such a sub-TLV is present with TLV then it MUST be processed as if such a sub-TLV is present with
Bit 0 set and no other bits set. That is, the absence of the sub-TLV Bit 0 set and no other bits set. That is, the absence of the sub-TLV
SHALL be interpreted to mean that the NSH is to be used. SHALL be interpreted to mean that the NSH is to be used.
If a given Tunnel TLV contains an SPI/SI Representation sub-TLV with If a given Tunnel TLV contains an SPI/SI Representation sub-TLV with
value field that has no flag set then the tunnel indicated by the value field that has no flag set then the tunnel indicated by the
Tunnel TLV MUST NOT be used for forwarding SFC packets. If a given Tunnel TLV MUST NOT be used for forwarding SFC packets. If a given
Tunnel TLV contains an SPI/SI Representation sub-TLV with both bit 0 Tunnel TLV contains an SPI/SI Representation sub-TLV with both bit 0
skipping to change at page 34, line 17 skipping to change at page 34, line 29
instances MUST be ignored. instances MUST be ignored.
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.5.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.ietf-mpls-sfc]. NSH. The label stack is encoded as shown in [I-D.ietf-mpls-sfc].
7.7. MPLS Label Swapping/Stacking Operation 7.6. 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
stacking it selects a specific SFIR and pushes that SFIR's SFI label stacking 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.
The classifier then moves sequentially back through the SFP one hop The classifier then moves sequentially back through the SFP one hop
at a time. For each hop, if the hop requires an {SPI, SI]} and there 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 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 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 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. the current hop) and the SFP's SPI onto the MPLS label stack.
If the hop requires a {context label, SFI label}, it selects a If the hop requires a {context label, SFI label}, it selects a
specific SFIR and pushes that SFIR's SFI label and context label onto specific SFIR and pushes that SFIR's SFI label and context label onto
the MPLS label stack. the MPLS label stack.
7.8. Support for MPLS-Encapsulated NSH Packets 7.7. Support for MPLS-Encapsulated NSH Packets
[I-D.ietf-mpls-sfc-encapsulation] describes how to transport SFC [I-D.ietf-mpls-sfc-encapsulation] describes how to transport SFC
packets using the NSH over an MPLS transport network. Signaling MPLS packets using the NSH over an MPLS transport network. Signaling MPLS
encapsulation of SFC packets using the NSH is also supported by this encapsulation of SFC packets using the NSH is also supported by this
document by using the "BGP Tunnel Encapsulation Attribute Sub-TLV" document by using the "BGP Tunnel Encapsulation Attribute Sub-TLV"
with the codepoint 10 (representing "MPLS Label Stack") from the "BGP with the codepoint 10 (representing "MPLS Label Stack") from the "BGP
Tunnel Encapsulation Attribute Sub-TLVs" registry defined in Tunnel Encapsulation Attribute Sub-TLVs" registry defined in
[I-D.ietf-idr-tunnel-encaps], and also using the "SFP Traversal With [I-D.ietf-idr-tunnel-encaps], and also using the "SFP Traversal With
MPLS Label Stack TLV" and the "SPI/SI Representation sub-TLV" with MPLS Label Stack TLV" and the "SPI/SI Representation sub-TLV" with
bit 0 set and bit 1 cleared. bit 0 set and bit 1 cleared.
In this case the MPLS label stack constructed by the SFF to forward a In this case the MPLS label stack constructed by the SFF to forward a
packet to the next SFF on the SFP will consist of the labels needed packet to the next SFF on the SFP will consist of the labels needed
to reach that SFF, and if label stacking is used it will also include to reach that SFF, and if label stacking is used it will also include
the labels advertised in the MPLS Label Stack sub-TLV and the labels the labels advertised in the MPLS Label Stack sub-TLV and the labels
remaining in the stack needed to traverse the remainder of the SFP. remaining in the stack needed to traverse the remainder of the SFP.
skipping to change at page 36, line 32 skipping to change at page 36, line 34
------ ------ ------ ------ ------ ------ ------ ------
| 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 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
RD = 192.0.2.4,5, SFT = 43 RD = 192.0.2.4:5, SFT = 43
RD = 192.0.2.4,6, SFT = 44 RD = 192.0.2.4:6, SFT = 44
Note that the addressing used for communicating between SFFs is taken Note that the addressing used for communicating between SFFs is taken
from the Tunnel Encapsulation attribute of the SFIR and not from the from the Tunnel Encapsulation attribute of the SFIR and not from the
SFIR-RD. SFIR-RD.
8.1. Example Explicit SFP With No Choices 8.1. Example Explicit SFP With No Choices
Consider the following SFPR. Consider the following SFPR.
SFP1: RD = 198.51.100.1,101, SPI = 15, SFP1: RD = 198.51.100.1:101, SPI = 15,
[SI = 255, SFT = 41, RD = 192.0.2.1,1], [SI = 255, SFT = 41, RD = 192.0.2.1:1],
[SI = 250, SFT = 43, RD = 192.0.2.2,2] [SI = 250, SFT = 43, RD = 192.0.2.2:2]
The Service Function Path consists of an SF of type 41 located at The Service Function Path consists of an SF of type 41 located at
SFF1 followed by an SF of type 43 located at SFF2. This path is SFF1 followed by an SF of type 43 located at SFF2. This path is
fully explicit and each SFF is offered no choice in forwarding packet fully explicit and each SFF is offered no choice in forwarding packet
along the path. along the path.
SFF1 will receive packets on the path from the Classifier and will SFF1 will receive packets on the path from the Classifier and will
identify the path from the SPI (15). The initial SI will be 255 and identify the path from the SPI (15). The initial SI will be 255 and
so SFF1 will deliver the packets to the SFI for SFT 41. so SFF1 will deliver the packets to the SFI for SFT 41.
When the packets are returned to SFF1 by the SFI the SI will be When the packets are returned to SFF1 by the SFI the SI will be
decreased to 250 for the next hop. SFF1 has no flexibility in the decreased to 250 for the next hop. SFF1 has no flexibility in the
choice of SFF to support the next hop SFI and will forward the packet choice of SFF to support the next hop SFI and will forward the packet
to SFF2 which will send the packets to the SFI that supports SFT 43 to SFF2 which will send the packets to the SFI that supports SFT 43
before forwarding the packets to their destinations. before forwarding the packets to their destinations.
8.2. Example SFP With Choice of SFIs 8.2. Example SFP With Choice of SFIs
SFP2: RD = 198.51.100.1,102, SPI = 16, SFP2: RD = 198.51.100.1:102, SPI = 16,
[SI = 255, SFT = 41, RD = 192.0.2.1,], [SI = 255, SFT = 41, RD = 192.0.2.1:1],
[SI = 250, SFT = 43, {RD = 192.0.2.2,2, [SI = 250, SFT = 43, {RD = 192.0.2.2:2,
RD = 192.0.2.4,5 } ] RD = 192.0.2.4:5 } ]
In this example the path also consists of an SF of type 41 located at In this example the path also consists of an SF of type 41 located at
SFF1 and this is followed by an SF of type 43, but in this case the SFF1 and this is followed by an SF of type 43, but in this case the
SI = 250 contains a choice between the SFI located at SFF2 and the SI = 250 contains a choice between the SFI located at SFF2 and the
SFI located at SFF4. SFI located at SFF4.
SFF1 will receive packets on the path from the Classifier and will SFF1 will receive packets on the path from the Classifier and will
identify the path from the SPI (16). The initial SI will be 255 and identify the path from the SPI (16). The initial SI will be 255 and
so SFF1 will deliver the packets to the SFI for SFT 41. so SFF1 will deliver the packets to the SFI for SFT 41.
When the packets are returned to SFF1 by the SFI the SI will be When the packets are returned to SFF1 by the SFI the SI will be
decreased to 250 for the next hop. SFF1 now has a choice of next hop decreased to 250 for the next hop. SFF1 now has a choice of next hop
SFF to execute the next hop in the path. It can either forward SFF to execute the next hop in the path. It can either forward
packets to SFF2 or SFF4 to execute a function of type 43. It uses packets to SFF2 or SFF4 to execute a function of type 43. It uses
its local load balancing algorithm to make this choice. The chosen its local load balancing algorithm to make this choice. The chosen
SFF will send the packets to the SFI that supports SFT 43 before SFF will send the packets to the SFI that supports SFT 43 before
forwarding the packets to their destinations. forwarding the packets to their destinations.
8.3. Example SFP With Open Choice of SFIs 8.3. Example SFP With Open Choice of SFIs
SFP3: RD = 198.51.100.1,103, SPI = 17, SFP3: RD = 198.51.100.1:103, SPI = 17,
[SI = 255, SFT = 41, RD = 192.0.2.1,1], [SI = 255, SFT = 41, RD = 192.0.2.1:1],
[SI = 250, SFT = 44, RD = 0] [SI = 250, SFT = 44, RD = 0]
In this example the path also consists of an SF of type 41 located at In this example the path also consists of an SF of type 41 located at
SFF1 and this is followed by an SI with an RD of zero and SF of type SFF1 and this is followed by an SI with an RD of zero and SF of type
44. This means that a choice can be made between any SFF that 44. This means that a choice can be made between any SFF that
supports an SFI of type 44. supports an SFI of type 44.
SFF1 will receive packets on the path from the Classifier and will SFF1 will receive packets on the path from the Classifier and will
identify the path from the SPI (17). The initial SI will be 255 and identify the path from the SPI (17). The initial SI will be 255 and
so SFF1 will deliver the packets to the SFI for SFT 41. so SFF1 will deliver the packets to the SFI for SFT 41.
skipping to change at page 38, line 31 skipping to change at page 38, line 33
decreased to 250 for the next hop. SFF1 now has a free choice of decreased to 250 for the next hop. SFF1 now has a free choice of
next hop SFF to execute the next hop in the path selecting between next hop SFF to execute the next hop in the path selecting between
all SFFs that support SFs of type 44. Looking at the SFIRs it has all SFFs that support SFs of type 44. Looking at the SFIRs it has
received, SFF1 knows that SF type 44 is supported by SFF3 and SFF4. received, SFF1 knows that SF type 44 is supported by SFF3 and SFF4.
SFF1 uses its local load balancing algorithm to make this choice. SFF1 uses its local load balancing algorithm to make this choice.
The chosen SFF will send the packets to the SFI that supports SFT 44 The chosen SFF will send the packets to the SFI that supports SFT 44
before forwarding the packets to their destinations. before forwarding the packets to their destinations.
8.4. Example SFP With Choice of SFTs 8.4. Example SFP With Choice of SFTs
SFP4: RD = 198.51.100.1,104, SPI = 18, SFP4: RD = 198.51.100.1:104, SPI = 18,
[SI = 255, SFT = 41, RD = 192.0.2.1,1], [SI = 255, SFT = 41, RD = 192.0.2.1:1],
[SI = 250, {SFT = 43, RD = 192.0.2.2,2, [SI = 250, {SFT = 43, RD = 192.0.2.2:2,
SFT = 44, RD = 192.0.2.3,8 } ] SFT = 44, RD = 192.0.2.3:8 } ]
This example provides a choice of SF type in the second hop in the This example provides a choice of SF type in the second hop in the
path. The SI of 250 indicates a choice between SF type 43 located path. The SI of 250 indicates a choice between SF type 43 located
through SF2 and SF type 44 located at SF3. through SF2 and SF type 44 located at SF3.
SFF1 will receive packets on the path from the Classifier and will SFF1 will receive packets on the path from the Classifier and will
identify the path from the SPI (18). The initial SI will be 255 and identify the path from the SPI (18). The initial SI will be 255 and
so SFF1 will deliver the packets to the SFI for SFT 41. so SFF1 will deliver the packets to the SFI for SFT 41.
When the packets are returned to SFF1 by the SFI the SI will be When the packets are returned to SFF1 by the SFI the SI will be
skipping to change at page 39, line 15 skipping to change at page 39, line 18
functions identified with different type identifiers (such as functions identified with different type identifiers (such as
firewalls from different vendors). SFF1 uses its local policy and firewalls from different vendors). SFF1 uses its local policy and
load balancing algorithm to make this choice, and may use additional load balancing algorithm to make this choice, and may use additional
information passed back from the local SFI to help inform its information passed back from the local SFI to help inform its
selection. The chosen SFF will send the packets to the SFI that selection. The chosen SFF will send the packets to the SFI that
supports the chose SFT before forwarding the packets to their supports the chose SFT before forwarding the packets to their
destinations. destinations.
8.5. Example Correlated Bidirectional SFPs 8.5. Example Correlated Bidirectional SFPs
SFP5: RD = 198.51.100.1,105, SPI = 19, SFP5: RD = 198.51.100.1:105, SPI = 19,
Assoc-Type = 1, Assoc-RD = 198.51.100.1,106, Assoc-SPI = 20, Assoc-Type = 1, Assoc-RD = 198.51.100.1:106, Assoc-SPI = 20,
[SI = 255, SFT = 41, RD = 192.0.2.1,1], [SI = 255, SFT = 41, RD = 192.0.2.1:1],
[SI = 250, SFT = 43, RD = 192.0.2.2,2] [SI = 250, SFT = 43, RD = 192.0.2.2:2]
SFP6: RD = 198.51.100.1,106, SPI = 20, SFP6: RD = 198.51.100.1:106, SPI = 20,
Assoc-Type = 1, Assoc-RD = 198.51.100.1,105, Assoc-SPI = 19, Assoc-Type = 1, Assoc-RD = 198.51.100.1:105, Assoc-SPI = 19,
[SI = 254, SFT = 43, RD = 192.0.2.2,2], [SI = 254, SFT = 43, RD = 192.0.2.2:2],
[SI = 249, SFT = 41, RD = 192.0.2.1,1] [SI = 249, SFT = 41, RD = 192.0.2.1:1]
This example demonstrates correlation of two SFPs to form a This example demonstrates correlation of two SFPs to form a
bidirectional SFP as described in Section 7.2. bidirectional SFP as described in Section 7.1.
Two SFPRs are advertised by the Controller. They have different SPIs Two SFPRs are advertised by the Controller. They have different SPIs
(19 and 20) so they are known to be separate SFPs, but they both have (19 and 20) so they are known to be separate SFPs, but they both have
Association TLVs with Association Type set to 1 indicating Association TLVs with Association Type set to 1 indicating
bidirectional SFPs. Each has an Associated SFPR-RD fields containing bidirectional SFPs. Each has an Associated SFPR-RD fields containing
the value of the other SFPR-RD to correlated the two SFPs as a the value of the other SFPR-RD to correlated the two SFPs as a
bidirectional pair. bidirectional pair.
As can be seen from the SFPRs in this example, the paths are As can be seen from the SFPRs in this example, the paths are
symmetric: the hops in SFP5 appear in the reverse order in SFP6. symmetric: the hops in SFP5 appear in the reverse order in SFP6.
8.6. Example Correlated Asymmetrical Bidirectional SFPs 8.6. Example Correlated Asymmetrical Bidirectional SFPs
SFP7: RD = 198.51.100.1,107, SPI = 21, SFP7: RD = 198.51.100.1:107, SPI = 21,
Assoc-Type = 1, Assoc-RD = 198.51.100.1,108, Assoc-SPI = 22, Assoc-Type = 1, Assoc-RD = 198.51.100.1:108, Assoc-SPI = 22,
[SI = 255, SFT = 41, RD = 192.0.2.1,1], [SI = 255, SFT = 41, RD = 192.0.2.1:1],
[SI = 250, SFT = 43, RD = 192.0.2.2,2] [SI = 250, SFT = 43, RD = 192.0.2.2:2]
SFP8: RD = 198.51.100.1,108, SPI = 22, SFP8: RD = 198.51.100.1:108, SPI = 22,
Assoc-Type = 1, Assoc-RD = 198.51.100.1,107, Assoc-SPI = 21, Assoc-Type = 1, Assoc-RD = 198.51.100.1:107, Assoc-SPI = 21,
[SI = 254, SFT = 44, RD = 192.0.2.4,6], [SI = 254, SFT = 44, RD = 192.0.2.4:6],
[SI = 249, SFT = 41, RD = 192.0.2.1,1] [SI = 249, SFT = 41, RD = 192.0.2.1:1]
Asymmetric bidirectional SFPs can also be created. This example Asymmetric bidirectional SFPs can also be created. This example
shows a pair of SFPs with distinct SPIs (21 and 22) that are shows a pair of SFPs with distinct SPIs (21 and 22) that are
correlated in the same way as in the example in Section 8.5. correlated in the same way as in the example in Section 8.5.
However, unlike in that example, the SFPs are different in each However, unlike in that example, the SFPs are different in each
direction. Both paths include a hop of SF type 41, but SFP7 includes direction. Both paths include a hop of SF type 41, but SFP7 includes
a hop of SF type 43 supported at SFF2 while SFP8 includes a hop of SF a hop of SF type 43 supported at SFF2 while SFP8 includes a hop of SF
type 44 supported at SFF4. type 44 supported at SFF4.
8.7. Example Looping in an SFP 8.7. Example Looping in an SFP
SFP9: RD = 198.51.100.1,109, SPI = 23, SFP9: RD = 198.51.100.1:109: SPI = 23,
[SI = 255, SFT = 41, RD = 192.0.2.1,1], [SI = 255, SFT = 41, RD = 192.0.2.1:1],
[SI = 250, SFT = 44, RD = 192.0.2.4,5], [SI = 250, SFT = 44, RD = 192.0.2.4:5],
[SI = 245, SFT = 1, RD = {SPI=23, SI=255, Rsv=0}], [SI = 245, SFT = 1, RD = {SPI=23, SI=255, Rsv=0}],
[SI = 245, SFT = 42, RD = 192.0.2.3,7] [SI = 245, SFT = 42, RD = 192.0.2.3:7]
Looping and jumping are described in Section 6. This example shows Looping and jumping are described in Section 6. This example shows
an SFP that contains an explicit loop-back instruction that is an SFP that contains an explicit loop-back instruction that is
presented as a choice within an SFP hop. presented as a choice within an SFP hop.
The first two hops in the path (SI = 255 and SI = 250) are normal. The first two hops in the path (SI = 255 and SI = 250) are normal.
That is, the packets will be delivered to SFF1 and SFF4 in turn for That is, the packets will be delivered to SFF1 and SFF4 in turn for
execution of SFs of type 41 and 44 respectively. execution of SFs of type 41 and 44 respectively.
The third hop (SI = 245) presents SFF4 with a choice of next hop. It The third hop (SI = 245) presents SFF4 with a choice of next hop. It
skipping to change at page 41, line 16 skipping to change at page 41, line 16
SFF4 must make a choice between these two next hops. Either the SFF4 must make a choice between these two next hops. Either the
packets will be forwarded to SFF3 with the NSH SI decreased to 245 or packets will be forwarded to SFF3 with the NSH SI decreased to 245 or
looped back to SFF1 with the NSH SI reset to 255. This choice will looped back to SFF1 with the NSH SI reset to 255. This choice will
be made according to local policy, information passed back by the be made according to local policy, information passed back by the
local SFI, and details in the packets' metadata that are used to local SFI, and details in the packets' metadata that are used to
prevent infinite looping. prevent infinite looping.
8.8. Example Branching in an SFP 8.8. Example Branching in an SFP
SFP10: RD = 198.51.100.1,110, SPI = 24, SFP10: RD = 198.51.100.1:110, SPI = 24,
[SI = 254, SFT = 42, RD = 192.0.2.3,7], [SI = 254, SFT = 42, RD = 192.0.2.3:7],
[SI = 249, SFT = 43, RD = 192.0.2.2,2] [SI = 249, SFT = 43, RD = 192.0.2.2:2]
SFP11: RD = 198.51.100.1,111, SPI = 25, SFP11: RD = 198.51.100.1:111, SPI = 25,
[SI = 255, SFT = 41, RD = 192.0.2.1,1], [SI = 255, SFT = 41, RD = 192.0.2.1:1],
[SI = 250, SFT = 1, RD = {SPI=24, SI=254, Rsv=0}] [SI = 250, SFT = 1, RD = {SPI=24, SI=254, Rsv=0}]
Branching follows a similar procedure to that for looping (and Branching follows a similar procedure to that for looping (and
jumping) as shown in Section 8.7 however there are two SFPs involved. jumping) as shown in Section 8.7 however there are two SFPs involved.
SFP10 shows a normal path with packets forwarded to SFF3 and SFF2 for SFP10 shows a normal path with packets forwarded to SFF3 and SFF2 for
execution of service functions of type 42 and 43 respectively. execution of service functions of type 42 and 43 respectively.
SFP11 starts as normal (SFF1 for an SF of type 41), but then SFF1 SFP11 starts as normal (SFF1 for an SF of type 41), but then SFF1
processes the next hop in the path and finds a "Change Sequence" processes the next hop in the path and finds a "Change Sequence"
skipping to change at page 41, line 44 skipping to change at page 41, line 44
so SFF1 knows that it must set the SPI/SI in the NSH to 24/254 and so SFF1 knows that it must set the SPI/SI in the NSH to 24/254 and
send the packets to the appropriate SFF as advertised in the SFPR for send the packets to the appropriate SFF as advertised in the SFPR for
SFP10 (that is, SFF3). SFP10 (that is, SFF3).
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.2.
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 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 |
skipping to change at page 42, line 28 skipping to change at page 42, line 28
---------- | 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 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
of which SFI to use to provide function of SFT 42 as follows. The of which SFI to use to provide function of SFT 42 as follows. The
load-balancing choice between the three available SFIs is assumed to load-balancing choice between the three available SFIs is assumed to
be within the capabilities of the SFF and if the SFs are stateful it be within the capabilities of the SFF and if the SFs are stateful it
is assumed that the SFF knows this and arranges load balancing in a is assumed that the SFF knows this and arranges load balancing in a
stable, flow-dependent way. stable, flow-dependent way.
SFP12: RD = 198.51.100.1,112, SPI = 26, SFP12: RD = 198.51.100.1:112, SPI = 26,
Assoc-Type = 1, Assoc-RD = 198.51.100.1,113, Assoc-SPI = 27, Assoc-Type = 1, Assoc-RD = 198.51.100.1:113, Assoc-SPI = 27,
[SI = 255, SFT = 41, RD = 192.0.2.1,11], [SI = 255, SFT = 41, RD = 192.0.2.1:11],
[SI = 254, SFT = 42, {RD = 192.0.2.2,11, [SI = 254, SFT = 42, {RD = 192.0.2.2:11,
192.0.2.2,12, 192.0.2.2:12,
192.0.2.2,13 }], 192.0.2.2:13 }],
[SI = 253, SFT = 43, RD = 192.0.2.3,11] [SI = 253, SFT = 43, RD = 192.0.2.3:11]
The reverse SFP in this case may also be created as shown below using The reverse SFP in this case may also be created as shown below using
association with the forward SFP and giving the load-balancing choice association with the forward SFP and giving the load-balancing choice
to SFF2. This is safe, even in the case that the SFs of type 42 are to SFF2. This is safe, even in the case that the SFs of type 42 are
stateful because SFF2 is doing the load balancing in both directions stateful because SFF2 is doing the load balancing in both directions
and can apply the same algorithm to ensure that packets associated and can apply the same algorithm to ensure that packets associated
with the same flow use the same SFI regardless of the direction of with the same flow use the same SFI regardless of the direction of
travel. travel.
SFP13: RD = 198.51.100.1,113, SPI = 27, How an SFF knows that an attached SFI is stateful is is out of scope
Assoc-Type = 1, Assoc-RD = 198.51.100.1,112, Assoc-SPI = 26, of this document. It is assumed that this will form part of the
[SI = 255, SFT = 43, RD = 192.0.2.3,11], process by which SFIs are registered as local to SFFs. Section 7.2
[SI = 254, SFT = 42, {RD = 192.0.2.2,11, provides additional observations about the coordination of the use of
192.0.2.2,12, stateful SFIs in the case of bidirecitonal SFPs.
192.0.2.2,13 }],
[SI = 253, SFT = 41, RD = 192.0.2.1,11] In general, the problems of load balancing and the selection of the
same SFIs in both directions of a bidirectional SPF can be addressed
by using sufficiently precisely specified SFPs (specifying the exact
SFIs to use) and suitable programming of the Classifiers at each end
of the SFPs to make sure that the matching pair of SFPs are used.
SFP13: RD = 198.51.100.1:113, SPI = 27,
Assoc-Type = 1, Assoc-RD = 198.51.100.1:112, Assoc-SPI = 26,
[SI = 255, SFT = 43, RD = 192.0.2.3:11],
[SI = 254, SFT = 42, {RD = 192.0.2.2:11,
192.0.2.2:12,
192.0.2.2:13 }],
[SI = 253, SFT = 41, RD = 192.0.2.1:11]
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 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,
[SI = 255, SFT = 41, RD = 192.0.2.1,11], [SI = 255, SFT = 41, RD = 192.0.2.1:11],
[SI = 254, SFT = 42, RD = 192.0.2.2,11], [SI = 254, SFT = 42, RD = 192.0.2.2:11],
[SI = 253, SFT = 43, RD = 192.0.2.3,11] [SI = 253, SFT = 43, RD = 192.0.2.3:11]
SFP15: RD = 198.51.100.1,115, SPI = 29, SFP15: RD = 198.51.100.1:115, SPI = 29,
Assoc-Type = 1, Assoc-RD = 198.51.100.1,118, Assoc-SPI = 32, Assoc-Type = 1, Assoc-RD = 198.51.100.1:118, Assoc-SPI = 32,
[SI = 255, SFT = 41, RD = 192.0.2.1,11], [SI = 255, SFT = 41, RD = 192.0.2.1:11],
[SI = 254, SFT = 42, RD = 192.0.2.2,12], [SI = 254, SFT = 42, RD = 192.0.2.2:12],
[SI = 253, SFT = 43, RD = 192.0.2.3,11] [SI = 253, SFT = 43, RD = 192.0.2.3:11]
SFP16: RD = 198.51.100.1,116, SPI = 30, SFP16: RD = 198.51.100.1:116, SPI = 30,
Assoc-Type = 1, Assoc-RD = 198.51.100.1,119, Assoc-SPI = 33, Assoc-Type = 1, Assoc-RD = 198.51.100.1:119, Assoc-SPI = 33,
[SI = 255, SFT = 41, RD = 192.0.2.1,11], [SI = 255, SFT = 41, RD = 192.0.2.1:11],
[SI = 254, SFT = 42, RD = 192.0.2.2,13], [SI = 254, SFT = 42, RD = 192.0.2.2:13],
[SI = 253, SFT = 43, RD = 192.0.2.3,11] [SI = 253, SFT = 43, RD = 192.0.2.3:11]
SFP17: RD = 198.51.100.1,117, SPI = 31, SFP17: RD = 198.51.100.1:117, SPI = 31,
Assoc-Type = 1, Assoc-RD = 198.51.100.1,114, Assoc-SPI = 28, Assoc-Type = 1, Assoc-RD = 198.51.100.1:114, Assoc-SPI = 28,
[SI = 255, SFT = 43, RD = 192.0.2.3,11], [SI = 255, SFT = 43, RD = 192.0.2.3:11],
[SI = 254, SFT = 42, RD = 192.0.2.2,11], [SI = 254, SFT = 42, RD = 192.0.2.2:11],
[SI = 253, SFT = 41, RD = 192.0.2.1,11] [SI = 253, SFT = 41, RD = 192.0.2.1:11]
SFP18: RD = 198.51.100.1,118, SPI = 32, SFP18: RD = 198.51.100.1:118, SPI = 32,
Assoc-Type = 1, Assoc-RD = 198.51.100.1,115, Assoc-SPI = 29, Assoc-Type = 1, Assoc-RD = 198.51.100.1:115, Assoc-SPI = 29,
[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,12], [SI = 254, SFT = 42, RD = 192.0.2.2:12],
[SI = 253, SFT = 41, RD = 192.0.2.1,11] [SI = 253, SFT = 41, RD = 192.0.2.1:11]
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 each 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 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.
skipping to change at page 45, line 38 skipping to change at page 46, line 5
| |
------ ------
| SFIc | | SFIc |
|SFT=42| |SFT=42|
------ ------
Figure 13: 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
their corresponding associated reverse SFPs. Each bidirectional pair their corresponding associated reverse SFPs. Each bidirectional pair
of SFPs uses a different SFF and SFI for middle hop (for an SF of of SFPs uses a different SFF and SFI for middle hop (for an SF of
type 42). The controller can instruct the Classifier how to place type 42). The controller can instruct the Classifier how to place
traffic on the three bidirectional SFPs, or can treat them as a group traffic on the three bidirectional SFPs, or can treat them as a group
leaving the Classifier responsible for balancing the load. leaving the Classifier responsible for balancing the load.
SFP20: RD = 198.51.100.1,120, SPI = 34, SFP20: RD = 198.51.100.1:120, SPI = 34,
Assoc-Type = 1, Assoc-RD = 198.51.100.1,123, Assoc-SPI = 37, Assoc-Type = 1, Assoc-RD = 198.51.100.1:123, Assoc-SPI = 37,
[SI = 255, SFT = 41, RD = 192.0.2.1,11], [SI = 255, SFT = 41, RD = 192.0.2.1:11],
[SI = 254, SFT = 42, RD = 192.0.2.5,11], [SI = 254, SFT = 42, RD = 192.0.2.5:11],
[SI = 253, SFT = 43, RD = 192.0.2.3,11] [SI = 253, SFT = 43, RD = 192.0.2.3:11]
SFP21: RD = 198.51.100.1,121, SPI = 35, SFP21: RD = 198.51.100.1:121, SPI = 35,
Assoc-Type = 1, Assoc-RD = 198.51.100.1,124, Assoc-SPI = 38, Assoc-Type = 1, Assoc-RD = 198.51.100.1:124, Assoc-SPI = 38,
[SI = 255, SFT = 41, RD = 192.0.2.1,11], [SI = 255, SFT = 41, RD = 192.0.2.1:11],
[SI = 254, SFT = 42, RD = 192.0.2.6,11], [SI = 254, SFT = 42, RD = 192.0.2.6:11],
[SI = 253, SFT = 43, RD = 192.0.2.3,11] [SI = 253, SFT = 43, RD = 192.0.2.3:11]
SFP22: RD = 198.51.100.1,122, SPI = 36, SFP22: RD = 198.51.100.1:122, SPI = 36,
Assoc-Type = 1, Assoc-RD = 198.51.100.1,125, Assoc-SPI = 39, Assoc-Type = 1, Assoc-RD = 198.51.100.1:125, Assoc-SPI = 39,
[SI = 255, SFT = 41, RD = 192.0.2.1,11], [SI = 255, SFT = 41, RD = 192.0.2.1:11],
[SI = 254, SFT = 42, RD = 192.0.2.7,11], [SI = 254, SFT = 42, RD = 192.0.2.7:11],
[SI = 253, SFT = 43, RD = 192.0.2.3,11] [SI = 253, SFT = 43, RD = 192.0.2.3:11]
SFP23: RD = 198.51.100.1,123, SPI = 37, SFP23: RD = 198.51.100.1:123, SPI = 37,
Assoc-Type = 1, Assoc-RD = 198.51.100.1,120, Assoc-SPI = 34, Assoc-Type = 1, Assoc-RD = 198.51.100.1:120, Assoc-SPI = 34,
[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.5,11], [SI = 254, SFT = 42, RD = 192.0.2.5:11],
[SI = 253, SFT = 41, RD = 192.0.2.1,11] [SI = 253, SFT = 41, RD = 192.0.2.1:11]
SFP24: RD = 198.51.100.1,124, SPI = 38, SFP24: RD = 198.51.100.1:124, SPI = 38,
Assoc-Type = 1, Assoc-RD = 198.51.100.1,121, Assoc-SPI = 35, Assoc-Type = 1, Assoc-RD = 198.51.100.1:121, Assoc-SPI = 35,
[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.6,11], [SI = 254, SFT = 42, RD = 192.0.2.6:11],
[SI = 253, SFT = 41, RD = 192.0.2.1,11] [SI = 253, SFT = 41, RD = 192.0.2.1:11]
SFP25: RD = 198.51.100.1,125, SPI = 39, SFP25: RD = 198.51.100.1:125, SPI = 39,
Assoc-Type = 1, Assoc-RD = 198.51.100.1,122, Assoc-SPI = 36, Assoc-Type = 1, Assoc-RD = 198.51.100.1:122, Assoc-SPI = 36,
[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.7,11], [SI = 254, SFT = 42, RD = 192.0.2.7:11],
[SI = 253, SFT = 41, RD = 192.0.2.1,11] [SI = 253, SFT = 41, RD = 192.0.2.1:11]
8.9.4. Parallel SFPs Downstream of the Choice 8.9.4. Parallel SFPs Downstream of the Choice
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
skipping to change at page 47, line 42 skipping to change at page 48, line 42
| |
------ ------
| SFIc | | SFIc |
|SFT=43| |SFT=43|
------ ------
Figure 14: 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
SFF2 is the point at which a load balancing choice must be made. So SFF2 is the point at which a load balancing choice must be made. So
"tail-end" SFPs are constructed as follows. Each takes in a "tail-end" SFPs are constructed as follows. Each takes in a
different SFF that provides access to an SF of type 43. different SFF that provides access to an SF of type 43.
SFP26: RD = 198.51.100.1,126, SPI = 40, SFP26: RD = 198.51.100.1:126, SPI = 40,
Assoc-Type = 1, Assoc-RD = 198.51.100.1,130, Assoc-SPI = 44, Assoc-Type = 1, Assoc-RD = 198.51.100.1:130, Assoc-SPI = 44,
[SI = 255, SFT = 43, RD = 192.0.2.5,11], [SI = 255, SFT = 43, RD = 192.0.2.5:11],
[SI = 254, SFT = 44, RD = 192.0.2.3,11] [SI = 254, SFT = 44, RD = 192.0.2.3:11]
SFP27: RD = 198.51.100.1,127, SPI = 41, SFP27: RD = 198.51.100.1:127, SPI = 41,
Assoc-Type = 1, Assoc-RD = 198.51.100.1,131, Assoc-SPI = 45, Assoc-Type = 1, Assoc-RD = 198.51.100.1:131, Assoc-SPI = 45,
[SI = 255, SFT = 43, RD = 192.0.2.6,11], [SI = 255, SFT = 43, RD = 192.0.2.6:11],
[SI = 254, SFT = 44, RD = 192.0.2.3,11] [SI = 254, SFT = 44, RD = 192.0.2.3:11]
SFP28: RD = 198.51.100.1,128, SPI = 42, SFP28: RD = 198.51.100.1:128, SPI = 42,
Assoc-Type = 1, Assoc-RD = 198.51.100.1,132, Assoc-SPI = 46, Assoc-Type = 1, Assoc-RD = 198.51.100.1:132, Assoc-SPI = 46,
[SI = 255, SFT = 43, RD = 192.0.2.7,11], [SI = 255, SFT = 43, RD = 192.0.2.7:11],
[SI = 254, SFT = 44, RD = 192.0.2.3,11] [SI = 254, SFT = 44, RD = 192.0.2.3:11]
Now an end-to-end SFP with load balancing choice can be constructed Now an end-to-end SFP with load balancing choice can be constructed
as follows. The choice made by SFF2 is expressed in terms of as follows. The choice made by SFF2 is expressed in terms of
entering one of the three "tail end" SFPs. entering one of the three "tail end" SFPs.
SFP29: RD = 198.51.100.1,129, SPI = 43, SFP29: RD = 198.51.100.1:129, SPI = 43,
[SI = 255, SFT = 41, RD = 192.0.2.1,11], [SI = 255, SFT = 41, RD = 192.0.2.1:11],
[SI = 254, SFT = 42, RD = 192.0.2.2,11], [SI = 254, SFT = 42, RD = 192.0.2.2:11],
[SI = 253, {SFT = 1, RD = {SPI=40, SI=255, Rsv=0}, [SI = 253, {SFT = 1, RD = {SPI=40, SI=255, Rsv=0},
RD = {SPI=41, SI=255, Rsv=0}, RD = {SPI=41, SI=255, Rsv=0},
RD = {SPI=42, SI=255, Rsv=0} } ] RD = {SPI=42, SI=255, Rsv=0} } ]
Now, despite the load balancing choice being made other than at the Now, despite the load balancing choice being made other than at the
initial classifier, it is possible for the reverse SFPs to be well- initial classifier, it is possible for the reverse SFPs to be well-
constructed without any ambiguity. The three reverse paths appear as constructed without any ambiguity. The three reverse paths appear as
follows. follows.
SFP30: RD = 198.51.100.1,130, SPI = 44, SFP30: RD = 198.51.100.1:130, SPI = 44,
Assoc-Type = 1, Assoc-RD = 198.51.100.1,126, Assoc-SPI = 40, Assoc-Type = 1, Assoc-RD = 198.51.100.1:126, Assoc-SPI = 40,
[SI = 255, SFT = 44, RD = 192.0.2.4,11], [SI = 255, SFT = 44, RD = 192.0.2.4:11],
[SI = 254, SFT = 43, RD = 192.0.2.5,11], [SI = 254, SFT = 43, RD = 192.0.2.5:11],
[SI = 253, SFT = 42, RD = 192.0.2.2,11], [SI = 253, SFT = 42, RD = 192.0.2.2:11],
[SI = 252, SFT = 41, RD = 192.0.2.1,11] [SI = 252, SFT = 41, RD = 192.0.2.1:11]
SFP31: RD = 198.51.100.1,131, SPI = 45, SFP31: RD = 198.51.100.1:131, SPI = 45,
Assoc-Type = 1, Assoc-RD = 198.51.100.1,127, Assoc-SPI = 41, Assoc-Type = 1, Assoc-RD = 198.51.100.1:127, Assoc-SPI = 41,
[SI = 255, SFT = 44, RD = 192.0.2.4,11], [SI = 255, SFT = 44, RD = 192.0.2.4:11],
[SI = 254, SFT = 43, RD = 192.0.2.6,11], [SI = 254, SFT = 43, RD = 192.0.2.6:11],
[SI = 253, SFT = 42, RD = 192.0.2.2,11], [SI = 253, SFT = 42, RD = 192.0.2.2:11],
[SI = 252, SFT = 41, RD = 192.0.2.1,11] [SI = 252, SFT = 41, RD = 192.0.2.1:11]
SFP32: RD = 198.51.100.1,132, SPI = 46, SFP32: RD = 198.51.100.1:132, SPI = 46,
Assoc-Type = 1, Assoc-RD = 198.51.100.1,128, Assoc-SPI = 42, Assoc-Type = 1, Assoc-RD = 198.51.100.1:128, Assoc-SPI = 42,
[SI = 255, SFT = 44, RD = 192.0.2.4,11], [SI = 255, SFT = 44, RD = 192.0.2.4:11],
[SI = 254, SFT = 43, RD = 192.0.2.7,11], [SI = 254, SFT = 43, RD = 192.0.2.7:11],
[SI = 253, SFT = 42, RD = 192.0.2.2,11], [SI = 253, SFT = 42, RD = 192.0.2.2:11],
[SI = 252, SFT = 41, RD = 192.0.2.1,11] [SI = 252, SFT = 41, RD = 192.0.2.1:11]
9. Security Considerations 9. Security Considerations
This document inherits all the security considerations discussed in This document inherits all the security considerations discussed in
the documents that specify BGP, the documents that specify BGP the documents that specify BGP, the documents that specify BGP
Multiprotocol Extensions, and the documents that define the Multiprotocol Extensions, and the documents that define the
attributes that are carried by BGP UPDATEs of the SFC AFI/SAFI. For attributes that are carried by BGP UPDATEs of the SFC AFI/SAFI. For
more information look in [RFC4271], [RFC4760], and more information look in [RFC4271], [RFC4760], and
[I-D.ietf-idr-tunnel-encaps]. [I-D.ietf-idr-tunnel-encaps].
skipping to change at page 49, line 48 skipping to change at page 50, line 48
are instantiated in software can be subverted. However, this are instantiated in software can be subverted. However, this
specification does not change the existence of Service Function specification does not change the existence of Service Function
Chaining and security issues specific to Service Function Chaining Chaining and security issues specific to Service Function Chaining
are covered in [RFC7665] and [RFC8300]. are covered in [RFC7665] and [RFC8300].
This document defines a control plane for Service Function Chaining. This document defines a control plane for Service Function Chaining.
Clearly, this provides an attack vector for a Service Function Clearly, this provides an attack vector for a Service Function
Chaining system as an attack on this control plane could be used to Chaining system as an attack on this control plane could be used to
make the system misbehave. Thus, the security of the BGP system is make the system misbehave. Thus, the security of the BGP system is
critically important to the security of the whole Service Function critically important to the security of the whole Service Function
Chaining system. Chaining system. The control plane mechanisms are very similar to
those used for BGP/MPLS IP VPNs as described in [RFC4364], and so the
security considerations in that document (Section 23) provide good
guidance for securing SFC systems reliant on this specification.
Section 19 of [RFC7432] also provides useful guidance on the use of
BGP in a similar environment.
Note that a component of an SFC system that uses the procedures
described in this document also requires communications between a
controller and the SFC network elements. This communication covers
instructing the Classifiers using BGP mechanisms (see Section 7.4)
which is covered by BGP security. But it also covers other
mechanisms for programming the Classifier and instructing the SFFs
and SFs (for example, to bind SFs to an SFF, and to cause the
estblishment of tunnels between SFFs). This document does not cover
these latter mechanisms and so their security is out of scope, but it
should be noted that these communications provide an attack vector on
the SFC system and so attention must be paid to ensuring that they
are secure.
10. IANA Considerations 10. IANA Considerations
10.1. New BGP AF/SAFI 10.1. New BGP AF/SAFI
IANA maintains a registry of "Address Family Numbers". IANA is IANA maintains a registry of "Address Family Numbers". IANA is
requested to assign a new Address Family Number from the "Standards requested to assign a new Address Family Number from the "Standards
Action" range called "BGP SFC" (TBD1 in this document) with this Action" range called "BGP SFC" (TBD1 in this document) with this
document as a reference. document as a reference.
skipping to change at page 53, line 43 skipping to change at page 55, line 13
Email: ar977m@att.com Email: ar977m@att.com
12. Acknowledgements 12. Acknowledgements
Thanks to Tony Przygienda, Jeff Haas, and Andy Malis for helpful Thanks to Tony Przygienda, Jeff Haas, and Andy Malis for helpful
comments, and to Joel Halpern for discussions that improved this comments, and to Joel Halpern for discussions that improved this
document. Yuanlong Jiang provided a useful review and caught some document. Yuanlong Jiang provided a useful review and caught some
important issues. Stephane Litkowski did an exceptionally good and important issues. Stephane Litkowski did an exceptionally good and
detailed document shepherd review. detailed document shepherd review.
Andy Malis contributed text that formed the basis of Section 7.8. Andy Malis contributed text that formed the basis of Section 7.7.
13. References 13. References
13.1. Normative References 13.1. Normative References
[I-D.ietf-idr-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-11 Encapsulation Attribute", draft-ietf-idr-tunnel-encaps-11
(work in progress), February 2019. (work in progress), February 2019.
[I-D.ietf-mpls-sfc] [I-D.ietf-mpls-sfc]
Farrel, A., Bryant, S., and J. Drake, "An MPLS-Based Farrel, A., Bryant, S., and J. Drake, "An MPLS-Based
Forwarding Plane for Service Function Chaining", draft- Forwarding Plane for Service Function Chaining", draft-
skipping to change at page 54, line 46 skipping to change at page 56, line 10
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
"Multiprotocol Extensions for BGP-4", RFC 4760, "Multiprotocol Extensions for BGP-4", RFC 4760,
DOI 10.17487/RFC4760, January 2007, DOI 10.17487/RFC4760, January 2007,
<https://www.rfc-editor.org/info/rfc4760>. <https://www.rfc-editor.org/info/rfc4760>.
[RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J.,
and D. McPherson, "Dissemination of Flow Specification and D. McPherson, "Dissemination of Flow Specification
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>.
[RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A.,
Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based
Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February
2015, <https://www.rfc-editor.org/info/rfc7432>.
[RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function
Chaining (SFC) Architecture", RFC 7665, Chaining (SFC) Architecture", RFC 7665,
DOI 10.17487/RFC7665, October 2015, DOI 10.17487/RFC7665, October 2015,
<https://www.rfc-editor.org/info/rfc7665>. <https://www.rfc-editor.org/info/rfc7665>.
[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>.
skipping to change at page 55, line 21 skipping to change at page 56, line 36
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
[RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and
L. Yong, "The Use of Entropy Labels in MPLS Forwarding",
RFC 6790, DOI 10.17487/RFC6790, November 2012,
<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>.
[RFC7510] Xu, X., Sheth, N., Yong, L., Callon, R., and D. Black,
"Encapsulating MPLS in UDP", RFC 7510,
DOI 10.17487/RFC7510, April 2015,
<https://www.rfc-editor.org/info/rfc7510>.
Authors' Addresses Authors' Addresses
Adrian Farrel Adrian Farrel
Old Dog Consulting Old Dog Consulting
Email: adrian@olddog.co.uk Email: adrian@olddog.co.uk
John Drake John Drake
Juniper Networks Juniper Networks
 End of changes. 91 change blocks. 
308 lines changed or deleted 324 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/