draft-ietf-bess-nsh-bgp-control-plane-07.txt   draft-ietf-bess-nsh-bgp-control-plane-08.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: August 30, 2019 E. Rosen Expires: September 2, 2019 E. Rosen
Juniper Networks Juniper Networks
J. Uttaro J. Uttaro
AT&T AT&T
L. Jalil L. Jalil
Verizon Verizon
February 26, 2019 March 1, 2019
BGP Control Plane for NSH SFC BGP Control Plane for NSH SFC
draft-ietf-bess-nsh-bgp-control-plane-07 draft-ietf-bess-nsh-bgp-control-plane-08
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
has to be applied to the packet. The other route type is used by a has to be applied to the packet. The other route type is used by a
Controller to advertise the paths of "chains" of service functions, Controller to advertise the paths of "chains" of service functions,
and to give a unique designator to each such path so that they can be and to give a unique designator to each such path so that they can be
used in conjunction with the Network Service Header. used in conjunction with the Network Service Header defined in RFC
8300.
This document adopts the SFC architecture described in RFC 7665. This document adopts the SFC architecture described in RFC 7665.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 August 30, 2019. This Internet-Draft will expire on September 2, 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 25 skipping to change at page 2, line 25
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Functional Overview . . . . . . . . . . . . . . . . . . . 5 2.1. Overview of Service Function Chaining . . . . . . . . . . 6
2.2. Control Plane Overview . . . . . . . . . . . . . . . . . 7 2.2. Control Plane Overview . . . . . . . . . . . . . . . . . 7
3. BGP SFC Routes . . . . . . . . . . . . . . . . . . . . . . . 9 3. BGP SFC Routes . . . . . . . . . . . . . . . . . . . . . . . 10
3.1. Service Function Instance Route (SFIR) . . . . . . . . . 10 3.1. Service Function Instance Route (SFIR) . . . . . . . . . 11
3.1.1. SFI Pool Identifier Extended Community . . . . . . . 11 3.1.1. SFI Pool Identifier Extended Community . . . . . . . 12
3.1.2. MPLS Mixed Swapping/Stacking Extended Community . . . 12 3.1.2. MPLS Mixed Swapping/Stacking Extended Community . . . 13
3.2. Service Function Path Route (SFPR) . . . . . . . . . . . 13 3.2. Service Function Path Route (SFPR) . . . . . . . . . . . 13
3.2.1. The SFP Attribute . . . . . . . . . . . . . . . . . . 13 3.2.1. The SFP Attribute . . . . . . . . . . . . . . . . . . 14
3.2.2. General Rules For The SFP Attribute . . . . . . . . . 18 3.2.2. General Rules For The SFP Attribute . . . . . . . . . 19
4. Mode of Operation . . . . . . . . . . . . . . . . . . . . . . 19 4. Mode of Operation . . . . . . . . . . . . . . . . . . . . . . 20
4.1. Route Targets . . . . . . . . . . . . . . . . . . . . . . 19 4.1. Route Targets . . . . . . . . . . . . . . . . . . . . . . 20
4.2. Service Function Instance Routes . . . . . . . . . . . . 19 4.2. Service Function Instance Routes . . . . . . . . . . . . 20
4.3. Service Function Path Routes . . . . . . . . . . . . . . 20 4.3. Service Function Path Routes . . . . . . . . . . . . . . 21
4.4. Classifier Operation . . . . . . . . . . . . . . . . . . 22 4.4. Classifier Operation . . . . . . . . . . . . . . . . . . 23
4.5. Service Function Forwarder Operation . . . . . . . . . . 22 4.5. Service Function Forwarder Operation . . . . . . . . . . 23
4.5.1. Processing With 'Gaps' in the SI Sequence . . . . . . 23 4.5.1. Processing With 'Gaps' in the SI Sequence . . . . . . 24
5. Selection in Service Function Paths . . . . . . . . . . . . . 24 5. Selection in Service Function Paths . . . . . . . . . . . . . 25
6. Looping, Jumping, and Branching . . . . . . . . . . . . . . . 26 6. Looping, Jumping, and Branching . . . . . . . . . . . . . . . 27
6.1. Protocol Control of Looping, Jumping, and Branching . . . 26 6.1. Protocol Control of Looping, Jumping, and Branching . . . 27
6.2. Implications for Forwarding State . . . . . . . . . . . . 27 6.2. Implications for Forwarding State . . . . . . . . . . . . 28
7. Advanced Topics . . . . . . . . . . . . . . . . . . . . . . . 28 7. Advanced Topics . . . . . . . . . . . . . . . . . . . . . . . 29
7.1. Preserving Entropy . . . . . . . . . . . . . . . . . . . 28 7.1. Preserving Entropy . . . . . . . . . . . . . . . . . . . 29
7.2. Correlating Service Function Path Instances . . . . . . . 28 7.2. Correlating Service Function Path Instances . . . . . . . 29
7.3. Considerations for Stateful Service Functions . . . . . . 29 7.3. Considerations for Stateful Service Functions . . . . . . 30
7.4. VPN Considerations and Private Service Functions . . . . 30 7.4. VPN Considerations and Private Service Functions . . . . 31
7.5. Flow Spec for SFC Classifiers . . . . . . . . . . . . . . 30 7.5. Flow Spec for SFC Classifiers . . . . . . . . . . . . . . 31
7.6. Choice of Data Plane SPI/SI Representation . . . . . . . 32 7.6. Choice of Data Plane SPI/SI Representation . . . . . . . 33
7.6.1. MPLS Representation of the SPI/SI . . . . . . . . . . 33 7.6.1. MPLS Representation of the SPI/SI . . . . . . . . . . 34
7.7. MPLS Label Swapping/Stacking Operation . . . . . . . . . 33 7.7. MPLS Label Swapping/Stacking Operation . . . . . . . . . 34
7.8. Support for MPLS-Encapsulated NSH Packets . . . . . . . . 33 7.8. Support for MPLS-Encapsulated NSH Packets . . . . . . . . 34
8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 34 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 35
8.1. Example Explicit SFP With No Choices . . . . . . . . . . 35 8.1. Example Explicit SFP With No Choices . . . . . . . . . . 36
8.2. Example SFP With Choice of SFIs . . . . . . . . . . . . . 36 8.2. Example SFP With Choice of SFIs . . . . . . . . . . . . . 37
8.3. Example SFP With Open Choice of SFIs . . . . . . . . . . 37 8.3. Example SFP With Open Choice of SFIs . . . . . . . . . . 38
8.4. Example SFP With Choice of SFTs . . . . . . . . . . . . . 37 8.4. Example SFP With Choice of SFTs . . . . . . . . . . . . . 38
8.5. Example Correlated Bidirectional SFPs . . . . . . . . . . 38 8.5. Example Correlated Bidirectional SFPs . . . . . . . . . . 39
8.6. Example Correlated Asymmetrical Bidirectional SFPs . . . 38 8.6. Example Correlated Asymmetrical Bidirectional SFPs . . . 39
8.7. Example Looping in an SFP . . . . . . . . . . . . . . . . 39 8.7. Example Looping in an SFP . . . . . . . . . . . . . . . . 40
8.8. Example Branching in an SFP . . . . . . . . . . . . . . . 40 8.8. Example Branching in an SFP . . . . . . . . . . . . . . . 41
8.9. Examples of SFPs with Stateful Service Functions . . . . 40 8.9. Examples of SFPs with Stateful Service Functions . . . . 41
8.9.1. Forward and Reverse Choice Made at the SFF . . . . . 41 8.9.1. Forward and Reverse Choice Made at the SFF . . . . . 42
8.9.2. Parallel End-to-End SFPs with Shared SFF . . . . . . 42 8.9.2. Parallel End-to-End SFPs with Shared SFF . . . . . . 43
8.9.3. Parallel End-to-End SFPs with Separate SFFs . . . . . 43 8.9.3. Parallel End-to-End SFPs with Separate SFFs . . . . . 44
8.9.4. Parallel SFPs Downstream of the Choice . . . . . . . 45 8.9.4. Parallel SFPs Downstream of the Choice . . . . . . . 46
9. Security Considerations . . . . . . . . . . . . . . . . . . . 48 9. Security Considerations . . . . . . . . . . . . . . . . . . . 49
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50
10.1. New BGP AF/SAFI . . . . . . . . . . . . . . . . . . . . 49 10.1. New BGP AF/SAFI . . . . . . . . . . . . . . . . . . . . 50
10.2. New BGP Path Attribute . . . . . . . . . . . . . . . . . 49 10.2. New BGP Path Attribute . . . . . . . . . . . . . . . . . 50
10.3. New SFP Attribute TLVs Type Registry . . . . . . . . . . 49 10.3. New SFP Attribute TLVs Type Registry . . . . . . . . . . 50
10.4. New SFP Association Type Registry . . . . . . . . . . . 50 10.4. New SFP Association Type Registry . . . . . . . . . . . 51
10.5. New Service Function Type Registry . . . . . . . . . . . 50 10.5. New Service Function Type Registry . . . . . . . . . . . 51
10.6. New Generic Transitive Experimental Use Extended 10.6. New Generic Transitive Experimental Use Extended
Community Sub-Types . . . . . . . . . . . . . . . . . . 51 Community Sub-Types . . . . . . . . . . . . . . . . . . 52
10.7. New BGP Transitive Extended Community Types . . . . . . 51 10.7. New BGP Transitive Extended Community Types . . . . . . 52
10.8. SPI/SI Representation . . . . . . . . . . . . . . . . . 52 10.8. SPI/SI Representation . . . . . . . . . . . . . . . . . 53
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 52 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 53
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 52 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 53
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 52 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 53
13.1. Normative References . . . . . . . . . . . . . . . . . . 52 13.1. Normative References . . . . . . . . . . . . . . . . . . 54
13.2. Informative References . . . . . . . . . . . . . . . . . 53 13.2. Informative References . . . . . . . . . . . . . . . . . 55
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 54 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 55
1. Introduction 1. Introduction
As described in [RFC7498], the delivery of end-to-end services can As described in [RFC7498], the delivery of end-to-end services can
require a packet to pass through a series of Service Functions (SFs) require a packet to pass through a series of Service Functions (SFs)
(e.g., classifiers, firewalls, TCP accelerators, and server load (e.g., WAN and application accelerators, Deep Packet Inspection (DPI)
balancers) in a specified order: this is termed "Service Function engines, firewalls, TCP optimizers, and server load balancers) in a
Chaining" (SFC). There are a number of issues associated with specified order: this is termed "Service Function Chaining" (SFC).
deploying and maintaining service function chaining in production There are a number of issues associated with deploying and
networks, which are described below. maintaining service function chaining in production networks, which
are described below.
Conventionally, if a packet needs to travel through a particular Historically, if a packet needed to travel through a particular
service chain, the nodes hosting the service functions of that chain service chain, the nodes hosting the service functions of that chain
are placed in the network topology in such a way that the packet were placed in the network topology in such a way that the packet
cannot reach its ultimate destination without first passing through could not reach its ultimate destination without first passing
all the service functions in the proper order. This need to place through all the service functions in the proper order. This need to
the service functions at particular topological locations limits the place the service functions at particular topological locations
ability to adapt a service function chain to changes in network limited the ability to adapt a service function chain to changes in
topology (e.g., link or node failures), network utilization, or network topology (e.g., link or node failures), network utilization,
offered service load. These topological restrictions on where the or offered service load. These topological restrictions on where the
service functions can be placed raise the following issues: service functions can be placed raised the following issues:
1. The process of configuring or modifying a service function chain 1. The process of configuring or modifying a service function chain
is operationally complex and may require changes to the network is operationally complex and may require changes to the network
topology. topology.
2. Alternate or redundant service functions may need to be co- 2. Alternate or redundant service functions may need to be co-
located with the primary service functions. located with the primary service functions.
3. When there is more than one path between source and destination, 3. When there is more than one path between source and destination,
forwarding may be asymmetric and it may be difficult to support forwarding may be asymmetric and it may be difficult to support
skipping to change at page 4, line 42 skipping to change at page 4, line 43
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
has to be applied to the packet. The other route type is used by a has to be applied to the packet. The other route type is used by a
Controller to advertise the paths of "chains" of service functions, Controller to advertise the paths of "chains" of service functions,
and to give a unique designator to each such path so that they can be and to give a unique designator to each such path so that they can be
used in conjunction with the Network Service Header. used in conjunction with the Network Service Header [RFC8300].
This document adopts the SFC architecture described in [RFC7665]. This document adopts the SFC architecture described in [RFC7665].
1.1. Requirements Language 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
skipping to change at page 5, line 37 skipping to change at page 5, line 37
Additionally, this document uses the following terms from [RFC8300]: Additionally, this document uses the following terms from [RFC8300]:
o Network Service Header (NSH) o Network Service Header (NSH)
o Service Index (SI) o Service Index (SI)
o Service Path Identifier (SPI) o Service Path Identifier (SPI)
This document introduces the following terms: This document introduces the following terms:
o Service Function Instance Route (SFIR) o Service Function Instance Route (SFIR). A new BGP Route Type
advertised by the node that hosts an SFI to describe the SFI and
to announce the way to forward a packet to the node through the
underlay network.
o Service Function Overlay Network o Service Function Overlay Network. The logical network comprised
of Classifiers, SFFs, and SFIs that are connected by paths or
tunnels through underlay transport networks.
o Service Function Path Route (SFPR) o Service Function Path Route (SFPR). A new BGP Route Type
originated by Controllers to advertise the details of each SFP.
o Service Function Type (SFT) o Service Function Type (SFT). An indication of the function and
features of an SFI.
2. Overview 2. Overview
2.1. Functional Overview 2.1. Overview of Service Function Chaining
In [RFC8300] a Service Function Chain (SFC) is an ordered list of In [RFC8300] a Service Function Chain (SFC) is an ordered list of
Service Functions (SFs). A Service Function Path (SFP) is an Service Functions (SFs). A Service Function Path (SFP) is an
indication of which instances of SFs are acceptable to be traversed indication of which instances of SFs are acceptable to be traversed
in an instantiation of an SFC in a service function overlay network. in an instantiation of an SFC in a service function overlay network.
The Service Path Identifier (SPI) is a 24-bit number that identifies The Service Path Identifier (SPI) is a 24-bit number that identifies
a specific SFP, and a Service Index (SI) is an 8-bit number that a specific SFP, and a Service Index (SI) is an 8-bit number that
identifies a specific point in that path. In the context of a identifies a specific point in that path. In the context of a
particular SFP (identified by an SPI), an SI represents a particular particular SFP (identified by an SPI), an SI represents a particular
Service Function, and indicates the order of that SF in the SFP. Service Function, and indicates the order of that SF in the SFP.
In fact, each SI is mapped to one or more SFs that are implemented by In fact, each SI is mapped to one or more SFs that are implemented by
one or more Service Function Instances (SFIs) that support those one or more Service Function Instances (SFIs) that support those
specified SFs. Thus an SI may represent a choice of SFIs of one or specified SFs. Thus an SI may represent a choice of SFIs of one or
more Service Function Types. By deploying multiple SFIs for a single more Service Function Types. By deploying multiple SFIs for a single
SF, one can provide load balancing and redundancy. SF, one can provide load balancing and redundancy.
A special Service Function, called a Classifier, is located at each A special functional element, called a Classifier, is located at each
ingress point to a service function overlay network. It assigns the ingress point to a service function overlay network. It assigns the
packets of a given packet flow to a specific Service Function Path. packets of a given packet flow to a specific Service Function Path.
This may be done by comparing specific fields in a packet's header This may be done by comparing specific fields in a packet's header
with local policy, which may be customer/network/service specific. with local policy, which may be customer/network/service specific.
The classifier picks an SFP and sets the SPI accordingly, it then The classifier picks an SFP and sets the SPI accordingly, it then
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
skipping to change at page 6, line 44 skipping to change at page 6, line 52
Section 7.1, that the node prepending the NSH also provide some form Section 7.1, that the node prepending the NSH also provide some form
of entropy indicator that can be used in the underlay network. of entropy indicator that can be used in the underlay network.
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 20 skipping to change at page 7, line 26
Section 6). Section 6).
o The SPI and the SI may point to an SF on a different SFP: known as o The SPI and the SI may point to an SF on a different SFP: known as
"branching" (see also Section 6). "branching" (see also Section 6).
Such modifications are limited to within the same service function Such modifications are limited to within the same service function
overlay network. That is, an SPI is known within the scope of overlay network. That is, an SPI is known within the scope of
service function overlay network. Furthermore, the new SI value is service function overlay network. Furthermore, the new SI value is
interpreted in the context of the SFP identified by the SPI. interpreted in the context of the SFP identified by the SPI.
An unknown or invalid SPI SHALL be treated as an error and the SFF As described in [RFC8300], an unknown or invalid SPI is treated as an
MUST drop the packet. Such errors SHOULD be logged, and such logs error and the SFF drops the packet. Such errors should be logged,
MUST be subject to rate limits. and such logs are subject to rate limits.
An SFF receiving an SI that is unknown in the context of the SPI MAY 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 it MUST drop the packet and SHOULD log the event: such this function, the SFF drops the packet and should log the event:
logs MUST be 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.
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 a new BGP AFI/SAFI (values to be assigned by IANA) for introduces the Service Function Type (SFT) that is the category of SF
"SFC Routes". Two SFC Route Types are defined by this document: the that is supported by an SFF (such as "firewall"). An IANA registry
Service Function Instance Route (SFIR), and the Service Function Path of Service Function Types is introduced in Section 10. An SFF may
Route (SFPR). As detailed in Section 3, the route type is indicated support SFs of multiple different SFTs, and may support multiple SFIs
by a sub-field in the NLRI. of each SF.
This document also introduces a new BGP AFI/SAFI (values to be
assigned by IANA) for "SFC Routes". Two SFC Route Types are defined
by this document: the Service Function Instance Route (SFIR), and the
Service Function Path Route (SFPR). As detailed in Section 3, the
route type is indicated by a sub-field in the NLRI.
o The SFIR is advertised by the node hosting the service function o The SFIR is advertised by the node hosting the service function
instance. The SFIR describes a particular instance of a instance. The SFIR describes a particular instance of a
particular Service Function and the way to forward a packet to it particular Service Function (i.e., an SFI) and the way to forward
through the underlay network, i.e., IP address and encapsulation a packet to it through the underlay network, i.e., IP address and
information. encapsulation information.
o The SFPRs are originated by Controllers. One SFPR is originated o The SFPRs are originated by Controllers. One SFPR is originated
for each Service Function Path. The SFPR specifies: for each Service Function Path. The SFPR specifies:
A. the SPI of the path A. the SPI of the path
B. the sequence of SFTs and/or SFIs of which the path consists B. the sequence of SFTs and/or SFIs of which the path consists
C. for each such SFT or SFI, the SI that represents it in the C. for each such SFT or SFI, the SI that represents it in the
identified path. identified path.
This approach assumes that there is an underlay network that provides This approach assumes that there is an underlay network that provides
connectivity between SFFs and Controllers, and that the SFFs are connectivity between SFFs and Controllers, and that the SFFs are
grouped to form one or more service function overlay networks through grouped to form one or more service function overlay networks through
which SFPs are built. We assume BGP connectivity between the which SFPs are built. We assume BGP connectivity between the
Controllers and all SFFs within each service function overlay Controllers and all SFFs within each service function overlay
skipping to change at page 8, line 16 skipping to change at page 8, line 30
C. for each such SFT or SFI, the SI that represents it in the C. for each such SFT or SFI, the SI that represents it in the
identified path. identified path.
This approach assumes that there is an underlay network that provides This approach assumes that there is an underlay network that provides
connectivity between SFFs and Controllers, and that the SFFs are connectivity between SFFs and Controllers, and that the SFFs are
grouped to form one or more service function overlay networks through grouped to form one or more service function overlay networks through
which SFPs are built. We assume BGP connectivity between the which SFPs are built. We assume BGP connectivity between the
Controllers and all SFFs within each service function overlay Controllers and all SFFs within each service function overlay
network. network.
In addition, we also introduce the Service Function Type (SFT) that
is the category of SF that is supported by an SFF (such as
"firewall"). An IANA registry of Service Function Types is
introduced in Section 10. An SFF may support SFs of multiple
different SFTs, and may support multiple SFIs of each SF.
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 portal in the underlay network through Thus the SFF can be seen as a gateway 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
four SFFs (SFF-1 through SFF-4) connected by tunnels across the
underlay network. Packets arrive at a Classifier and are channelled
along SFPs to destinations reachable through SFF-4.
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
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
the same type as SFb (SFTx).
This figure demonstrates how load balancing can be achieved. Suppose
an SFC needs to include SFa, an SF of type SFTx, and SFd. A number
of SFPs can be constructed using any instance of SFb or using SFd.
Packets Packets
| | | | | |
| | | | | |
| | | | | |
------------ ------------
| | | |
| Classifier | | Classifier |
| | | |
------------ ------------
| |
| |
------- ------- ------- --------- -------
| | Tunnel | | | | Tunnel | | | |
| SFF |=============| SFF |=========== ......... | SFF-1 |===============| SFF-2 |=========| SFF-4 |
| | | | # : SFT : | | | | | |
| | -+---+- # : ----- : | | -+-----+- | |
| | / \ # : | SFI | : | | ,,,,,,,,,,,,,,/,, \ | |
| | ....../.......\...... # : --+-- : | | ' .........../. ' ..\...... | |
| | : / \ : # ....|.... | | ' : SFb / : ' : \ SFc : | |
| | : -+--- ---+- : # | | | ' : ---+- : ' : --+-- : | |
| | : | SFI | | SFI | : # ---+--- | | ' : -| SFI | : ' : | SFI | : | |
| | : ----- ----- : ====| |--- | | ' : -| ----- : ' : ----- : | |
| | : : | SFF |--- Dests | | ' : | ----- : ' ......... | |
| | : ----- : ====| |--- | | ' : ----- : ' | |
| | : | SFI | : # ------- | | ' ............. ' | |--- Dests
| | : --+-- : # | | ' ' | |--- Dests
| | : SFT | : # | | ' ' | |
| | ..........|.......... # | | ' ......... ' | |
| | | # | | ' : ----- : ' | |
| | | # | | ' : | SFI | : ' | |
| | ---+--- # | | ' : --+-- : ' | |
| | | | # | | ' :SFd | : ' | |
| |=============| SFF |=========== | | ' ....|.... ' | |
------- | | | | ' | ' | |
------- | | ' SFTx | ' | |
| | ',,,,,,,,|,,,,,,,,' | |
| | | | |
| | | | |
| | ---+--- | |
| | | | | |
| |======| SFF-3 |====================| |
---+--- | | ---+---
| ------- |
....|.... ....|....
: | SFa: : | SFe:
: --+-- : : --+-- :
: | SFI | : : | SFI | :
: ----- : : ----- :
......... .........
Figure 1: The SFC Architecture Reference Model Figure 1: The SFC Architecture Reference Model
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.
skipping to change at page 10, line 41 skipping to change at page 11, line 14
The detailed encoding and procedures for these Route Types are The detailed encoding and procedures for these Route Types are
described in subsequent sections. described in subsequent sections.
The SFC NLRI is carried in BGP [RFC4271] using BGP Multiprotocol The SFC NLRI is carried in BGP [RFC4271] using BGP Multiprotocol
Extensions [RFC4760] with an Address Family Identifier (AFI) of TBD1 Extensions [RFC4760] with an Address Family Identifier (AFI) of TBD1
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.
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) |
+--------------------------------------------+ +--------------------------------------------+
Figure 3: SFIR Route Type specific NLRI Figure 3: SFIR Route Type specific NLRI
Per [RFC4364] the RD field comprises a two byte Type field and a six Per [RFC4364] the RD field comprises a two byte Type field and a six
byte Value field. 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, e.g., The Service Function Type identifies a service function type, e.g.,
classifier, firewall, load balancer, etc. There may be several SFIs classifier, firewall, load balancer, etc. There may be several SFIs
that can perform a given Service Function. Each node hosting an SFI that can perform a given Service Function. Each node hosting an SFI
must originate an SFIR for each type of SF that it hosts, and it may MUST originate an SFIR for each type of SF that it hosts, and it may
advertise an SFIR for each instance of each type of SF. The SFIR advertise an SFIR for each instance of each type of SF. The minimal
representing a given SFI will contain an NLRI with RD field set to an advertisement allows construction of valid SFPs and leaves the
RD as specified above, and with SFT field set to identify that SFI's selection of SFIs to the local SFF; the detailed advertisement may
Service Function Type. The values for the SFT field are taken from a have scaling concerns, but allows a Controller that constructs an SFP
registry administered by IANA (see Section 10). A BGP Update to make an explicit choice of SFI.
containing one or more SFIRs will also include a Tunnel Encapsulation
attribute [I-D.ietf-idr-tunnel-encaps]. If a data packet needs to be The SFIR representing a given SFI will contain an NLRI with RD field
sent to an SFI identified in one of the SFIRs, it will be set to an RD as specified above, and with SFT field set to identify
encapsulated as specified by the Tunnel Encapsulation attribute, and that SFI's Service Function Type. The values for the SFT field are
then transmitted through the underlay network. taken from a registry administered by IANA (see Section 10). A BGP
Update containing one or more SFIRs MUST also include a Tunnel
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
will be encapsulated as specified by the Tunnel Encapsulation
attribute, and then transmitted through the underlay network.
Note that the Tunnel Encapsulation attribute MUST contain sufficient
information to allow the advertising SFF to identify the overlay or
VPN network which a received packet is transiting. This is because
the [SPI, SI] in a received packet is specific to a particular
overlay or VPN network.
3.1.1. SFI Pool Identifier Extended Community 3.1.1. SFI Pool Identifier Extended Community
This document defines a new transitive extended community of type This document defines a new transitive extended community of type
TBD6 with Sub-Type 0x00 called the SFI Pool Identifier extended TBD6 with Sub-Type 0x00 called the SFI Pool Identifier extended
community. It can be included in SFIR advertisements, and is used to community. It MAY be included in SFIR advertisements, and is used to
indicate the identity of a pool of SFIRs to which an SFIR belongs. indicate the identity of a pool of SFIRs to which an SFIR belongs.
Since an SFIR may be a member of multiple pools, multiple of these Since an SFIR may be a member of multiple pools, multiple of these
extended communities may be present on a single SFIR advertisement. extended communities may be present on a single SFIR advertisement.
SFIR pools allow SFIRs to be grouped for any purpose. Possible uses SFIR pools allow SFIRs to be grouped for any purpose. Possible uses
include control plane scalability and stability. include control plane scalability and stability. A pool identifier
may be included in an SFPR to indicate a set of SFIs that are
acceptable at a specific point on an SFP (see Section 3.2.1.3 and
Section 4.3).
The SFI Pool Identifier extended community is encoded in 8 octets as The SFI Pool Identifier extended community is encoded in 8 octets as
shown in Figure 4. shown in Figure 4.
+--------------------------------------------+ +--------------------------------------------+
| Type = 0x80 (1 octet) | | Type = TBD6 (1 octet) |
+--------------------------------------------+ +--------------------------------------------+
| Sub-Type = TBD6 (1 octet) | | Sub-Type = 0x00 (1 octet) |
+--------------------------------------------+ +--------------------------------------------+
| SFI Pool Identifier Value (6 octets) | | SFI Pool Identifier Value (6 octets) |
+--------------------------------------------+ +--------------------------------------------+
Figure 4: The SFI Pool Identifier Extended Community Figure 4: The SFI Pool Identifier Extended Community
The SFI Pool Identifier Value is encoded in a 6 octet field in The SFI Pool Identifier Value is encoded in a 6 octet field in
network byte order, and is a globally unique value. network byte order, and is a globally unique value. This means that
pool identifiers need to be centrally managed, which is consistent
with the assignment of SFIs to pools.
3.1.2. MPLS Mixed Swapping/Stacking Extended Community 3.1.2. MPLS Mixed Swapping/Stacking Extended Community
This document defines a new transitive extended community of type This document defines a new transitive extended community of type
TBD7 with Sub-Type 0x00 called the MPLS Mixed Swapping/Stacking TBD7 with Sub-Type 0x00 called the MPLS Mixed Swapping/Stacking
Labels. The community is encoded as shown in Figure 5. It contains Labels. The community is encoded as shown in Figure 5. It contains
a pair of MPLS labels: an SFC Context Label and an SF Label as a pair of MPLS labels: an SFC Context Label and an SF Label as
described in [I-D.ietf-mpls-sfc]. Each label is 20 bits encoded in a described in [I-D.ietf-mpls-sfc]. Each label is 20 bits encoded in a
3-octet (24 bit) field with 4 trailing bits that MUST be set to zero. 3-octet (24 bit) field with 4 trailing bits that MUST be set to zero.
+--------------------------------------------+ +--------------------------------------------+
| Type = 0x80 (1 octet) | | Type = TBD7 (1 octet) |
+--------------------------------------------| +--------------------------------------------|
| Sub-Type = TBD7 (1 octet) | | Sub-Type = 0x00 (1 octet) |
+--------------------------------------------| +--------------------------------------------|
| SFC Context Label (3 octets) | | SFC Context Label (3 octets) |
+--------------------------------------------| +--------------------------------------------|
| SF Label (3 octets) | | SF Label (3 octets) |
+--------------------------------------------+ +--------------------------------------------+
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
skipping to change at page 13, line 18 skipping to change at page 14, line 14
+-----------------------------------------------+ +-----------------------------------------------+
| Route Distinguisher (RD) (8 octets) | | Route Distinguisher (RD) (8 octets) |
+-----------------------------------------------+ +-----------------------------------------------+
| Service Path Identifier (SPI) (3 octets) | | Service Path Identifier (SPI) (3 octets) |
+-----------------------------------------------+ +-----------------------------------------------+
Figure 6: SFPR Route Type Specific NLRI Figure 6: SFPR Route Type Specific NLRI
Per [RFC4364] the RD field comprises a two byte Type field and a six Per [RFC4364] the RD field comprises a two byte Type field and a six
byte Value field. All SFPs must be associated with different RDs. byte Value field. All SFPs MUST be associated with different RDs.
The association of an SFP with an RD is determined by provisioning. The association of an SFP with an RD is determined by provisioning.
If two SFPRs are originated from different Controllers they must have If two SFPRs are originated from different Controllers they MUST have
different RDs. Additionally, SFPRs from different VPNs (i.e., in different RDs. Additionally, SFPRs from different VPNs (i.e., in
different service function overlay networks) must have different RDs, different service function overlay networks) MUST have different RDs,
and those RDs must be different from any non-VPN SFPRs. and those RDs MUST be different from any non-VPN SFPRs.
The Service Path Identifier is defined in [RFC8300] and is the value The Service Path Identifier is defined in [RFC8300] and is the value
to be placed in the Service Path Identifier field of the NSH header to be placed in the Service Path Identifier field of the NSH header
of any packet sent on this Service Function Path. It is expected of any packet sent on this Service Function Path. It is expected
that one or more Controllers will originate these routes in order to that one or more Controllers will originate these routes in order to
configure a service function overlay network. configure a service function overlay network.
The SFP is described in a new BGP Path attribute, the SFP attribute. The SFP is described in a new BGP Path attribute, the SFP attribute.
Section 3.2.1 shows the format of that attribute. Section 3.2.1 shows the format of that attribute.
3.2.1. The SFP Attribute 3.2.1. The SFP Attribute
[RFC4271] defines the BGP Path attribute. This document introduces a [RFC4271] defines the BGP Path attribute. This document introduces a
new Path attribute called the SFP attribute with value TBD3 to be new Optional Transitive Path attribute called the SFP attribute with
assigned by IANA. The first SFP attribute MUST be processed and value TBD3 to be assigned by IANA. The first SFP attribute MUST be
subsequent instances MUST be ignored. processed and subsequent instances MUST be ignored.
The common fields of the SFP attribute are set as follows: The common fields of the SFP attribute are set as follows:
o Optional bit is set to 1 to indicate that this is an optional o Optional bit is set to 1 to indicate that this is an optional
attribute. attribute.
o The Transitive bit is set to 1 to indicate that this is a o The Transitive bit is set to 1 to indicate that this is a
transitive attribute. transitive attribute.
o The Extended Length bit is set according to the length of the SFP o The Extended Length bit is set according to the length of the SFP
skipping to change at page 14, line 23 skipping to change at page 15, line 21
o Length: A two octet field indicating the length of the data o Length: A two octet field indicating the length of the data
following the Length field counted in octets. following the Length field counted in octets.
o Value: The contents of the TLV. o Value: The contents of the TLV.
The formats of the TLVs defined in this document are shown in the The formats of the TLVs defined in this document are shown in the
following sections. The presence rules and meanings are as follows. following sections. The presence rules and meanings are as follows.
o The SFP attribute contains a sequence of zero or more Association o The SFP attribute contains a sequence of zero or more Association
TLVs. That is, the Association TLV is optional. Each Association TLVs. That is, the Association TLV is OPTIONAL. Each Association
TLV provides an association between this SFPR and another SFPR. TLV provides an association between this SFPR and another SFPR.
Each associated SFPR is indicated using the RD with which it is Each associated SFPR is indicated using the RD with which it is
advertised (we say the SFPR-RD to avoid ambiguity). advertised (we say the SFPR-RD to avoid ambiguity).
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
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) |
+--------------------------------------------| +--------------------------------------------|
skipping to change at page 16, line 15 skipping to change at page 17, line 15
Therefore, processing of an association MUST NOT be rejected simply Therefore, processing of an association MUST NOT be rejected simply
because the Associated SFPR-RD is unknown. because the Associated SFPR-RD is unknown.
Further discussion of correlation of SFPRs is provided in Further discussion of correlation of SFPRs is provided in
Section 7.2. Section 7.2.
3.2.1.2. The Hop TLV 3.2.1.2. The Hop TLV
There is one Hop TLV in the SFP attribute for each hop in the SFP. There is one Hop TLV in the SFP attribute for each hop in the SFP.
The format of the Hop TLV is shown in Figure 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) |
+--------------------------------------------| +--------------------------------------------|
| Length (2 octets) | | Length (2 octets) |
+--------------------------------------------| +--------------------------------------------|
| Service Index (1 octet) | | Service Index (1 octet) |
+--------------------------------------------| +--------------------------------------------|
| Hop Details (variable) | | Hop Details (variable) |
+--------------------------------------------+ +--------------------------------------------+
skipping to change at page 17, line 5 skipping to change at page 18, line 5
The Hop Details field consists of a sequence of one or more sub- The Hop Details field consists of a sequence of one or more sub-
TLVs. TLVs.
Each hop of the SFP may demand that a specific type of SF is Each hop of the SFP may demand that a specific type of SF is
executed, and that type is indicated in sub-TLVs of the Hop TLV. At executed, and that type is indicated in sub-TLVs of the Hop TLV. At
least one sub-TLV MUST be present. This provides a list of which least one sub-TLV MUST be present. This provides a list of which
types of SF are acceptable at a specific hop, and for each type it types of SF are acceptable at a specific hop, and for each type it
allows a degree of control to be imposed on the choice of SFIs of allows a degree of control to be imposed on the choice of SFIs of
that particular type. that particular type.
If no Hop TLV is present in an SFP Attribute, it is a malformed
attribute
3.2.1.3. The SFT TLV 3.2.1.3. The SFT TLV
The SFT TLV MAY be included in the list of sub-TLVs of the Hop TLV. The SFT TLV MAY be included in the list of sub-TLVs of the Hop TLV.
The format of the SFT TLV is shown in Figure 9. The TLV contains a The format of the SFT TLV is shown in Figure 9. The TLV contains a
list of SFIR-RD values each taken from the advertisement of an SFI. list of SFIR-RD values each taken from the advertisement of an SFI.
Together they form a list of acceptable SFIs of the indicated type. Together they form a list of acceptable SFIs of the indicated type.
+--------------------------------------------+ +--------------------------------------------+
| Type = 3 (1 octet) | | Type = 3 (1 octet) |
+--------------------------------------------| +--------------------------------------------|
skipping to change at page 18, line 20 skipping to change at page 19, line 22
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.7 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.
3.2.2. General Rules For The SFP Attribute 3.2.2. General Rules For The SFP Attribute
It is possible for the same SFI, as described by an SFIR, to be used It is possible for the same SFI, as described by an SFIR, to be used
in multiple SFPRs. in multiple SFPRs.
When two SFPRs have the same SPI but different SFPR-RDs there can be When two SFPRs have the same SPI but different SFPR-RDs there can be
three cases: three cases:
skipping to change at page 22, line 7 skipping to change at page 23, line 7
Identifier. I.e., the list of SFIR-RD values is effectively expanded Identifier. I.e., the list of SFIR-RD values is effectively expanded
to include the SFIR-RD of each SFIR advertised with each SFI Pool to include the SFIR-RD of each SFIR advertised with each SFI Pool
Identifier in the SFIR-RD list. Identifier in the SFIR-RD list.
The choice of SFI is explained further in Section 5. Note that an The choice of SFI is explained further in Section 5. Note that an
SFIR-RD value of zero has special meaning as described in that SFIR-RD value of zero has special meaning as described in that
Section. Section.
4.4. Classifier Operation 4.4. Classifier Operation
As shown in Figure 1, the Classifier is a special Service Function As shown in Figure 1, the Classifier is a component that is used to
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 The Classifier may also provide an entropy indicator as described in
Section 7.1. Section 7.1.
4.5. Service Function Forwarder Operation 4.5. Service Function Forwarder Operation
skipping to change at page 23, line 11 skipping to change at page 24, line 11
The installed forwarding state may change over time reacting to The installed forwarding state may change over time reacting to
changes in the underlay network and the availability of particular changes in the underlay network and the availability of particular
SFIs. SFIs.
Note that SFFs only create and store forwarding state for the SFPs on Note that SFFs only create and store forwarding state for the SFPs on
which they are included. They do not retain state for all SFPs which they are included. They do not retain state for all SFPs
advertised. advertised.
An SFF may also install forwarding state to support looping, jumping, An SFF may also install forwarding state to support looping, jumping,
and branching. The protocol mechanism for explicit control of and branching. The protocol mechanism for explicit control of
looping, jumping, and branching uses a specific reserved SFT value looping, jumping, and branching uses a specific reserved SFT value at
at a given hop of an SFPR and is described in Section 6.1. a given hop of an SFPR and is described in Section 6.1.
4.5.1. Processing With 'Gaps' in the SI Sequence 4.5.1. Processing With 'Gaps' in the SI Sequence
The behavior of an SF as described in [RFC8300] is to decrement the The behavior of an SF as described in [RFC8300] is to decrement the
value of the SI field in the NSH by one before returning a packet to value of the SI field in the NSH by one before returning a packet to
the local SFF for further processing. This means that there is a the local SFF for further processing. This means that there is a
good reason to assume that the SFP is composed of a series of SFs good reason to assume that the SFP is composed of a series of SFs
each indicated by an SI value one less than the previous. each indicated by an SI value one less than the previous.
However, there is an advantage to having non-successive SIs in an However, there is an advantage to having non-successive SIs in an
skipping to change at page 24, line 30 skipping to change at page 25, line 30
in an SFP. Such an implementation will not support receiving an SI in an SFP. Such an implementation will not support receiving an SI
value that is not present in the SFP and will discard the packets as value that is not present in the SFP and will discard the packets as
described in [RFC8300]. described in [RFC8300].
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 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
skipping to change at page 32, line 9 skipping to change at page 33, line 9
then there are two sub-cases: then there are two sub-cases:
* If there is a choice of SFT in the hop indicated by the value * If there is a choice of SFT in the hop indicated by the value
of the SI (including SI = 0) then SFT = 0 means there is a free of the SI (including SI = 0) then SFT = 0 means there is a free
choice according to local policy of which SFT to use). choice according to local policy of which SFT to use).
* If there is no choice of SFT in the hop indicated by the value * If there is no choice of SFT in the hop indicated by the value
of SI, then SFT = 0 means that the value of the SFT at that hop of SI, then SFT = 0 means that the value of the SFT at that hop
as indicated in the SPFR for the indicated SPI MUST be used. as indicated in the SPFR for the indicated SPI MUST be used.
Note that each FlowSpec update MUST be tagged with the route target
of the overlay or VPN network for which it is intended.
7.6. Choice of Data Plane SPI/SI Representation 7.6. Choice of Data Plane SPI/SI Representation
This document ties together the control and data planes of an SFC This document ties together the control and data planes of an SFC
overlay network through the use of the SPI/SI which is nominally overlay network through the use of the SPI/SI which is nominally
carried in the NSH of a given packet. However, in order to handle carried in the NSH of a given packet. However, in order to handle
situations in which the NSH is not ubiquitously deployed, it is also situations in which the NSH is not ubiquitously deployed, it is also
possible to use alternative data plane representations of the SPI/SI possible to use alternative data plane representations of the SPI/SI
by carrying the identical semantics in other protocol fields such as by carrying the identical semantics in other protocol fields such as
MPLS labels [I-D.ietf-mpls-sfc]. MPLS labels [I-D.ietf-mpls-sfc].
skipping to change at page 52, line 40 skipping to change at page 53, line 40
Avinash Lingala Avinash Lingala
AT&T AT&T
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. important issues. Stephane Litkowski did an exceptionally good and
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.8.
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]
Farrel, A., Bryant, S., and J. Drake, "An MPLS-Based
Forwarding Plane for Service Function Chaining", draft-
ietf-mpls-sfc-05 (work in progress), February 2019.
[I-D.ietf-mpls-sfc-encapsulation]
Malis, A., Bryant, S., Halpern, J., and W. Henderickx,
"MPLS Transport Encapsulation For The SFC NSH", draft-
ietf-mpls-sfc-encapsulation-03 (work in progress), March
2019.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Border Gateway Protocol 4 (BGP-4)", RFC 4271, Border Gateway Protocol 4 (BGP-4)", RFC 4271,
DOI 10.17487/RFC4271, January 2006, DOI 10.17487/RFC4271, January 2006,
<https://www.rfc-editor.org/info/rfc4271>. <https://www.rfc-editor.org/info/rfc4271>.
skipping to change at page 53, line 34 skipping to change at page 54, line 46
[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>.
[RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function
Chaining (SFC) Architecture", RFC 7665,
DOI 10.17487/RFC7665, October 2015,
<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>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed.,
"Network Service Header (NSH)", RFC 8300, "Network Service Header (NSH)", RFC 8300,
DOI 10.17487/RFC8300, January 2018, DOI 10.17487/RFC8300, January 2018,
<https://www.rfc-editor.org/info/rfc8300>. <https://www.rfc-editor.org/info/rfc8300>.
13.2. Informative References 13.2. Informative References
[I-D.ietf-mpls-sfc]
Farrel, A., Bryant, S., and J. Drake, "An MPLS-Based
Forwarding Plane for Service Function Chaining", draft-
ietf-mpls-sfc-05 (work in progress), February 2019.
[I-D.ietf-mpls-sfc-encapsulation]
Malis, A., Bryant, S., Halpern, J., and W. Henderickx,
"MPLS Encapsulation For The SFC NSH", draft-ietf-mpls-sfc-
encapsulation-02 (work in progress), December 2018.
[RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and
L. Yong, "The Use of Entropy Labels in MPLS Forwarding", L. Yong, "The Use of Entropy Labels in MPLS Forwarding",
RFC 6790, DOI 10.17487/RFC6790, November 2012, RFC 6790, DOI 10.17487/RFC6790, November 2012,
<https://www.rfc-editor.org/info/rfc6790>. <https://www.rfc-editor.org/info/rfc6790>.
[RFC7498] Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for [RFC7498] Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for
Service Function Chaining", RFC 7498, Service Function Chaining", RFC 7498,
DOI 10.17487/RFC7498, April 2015, DOI 10.17487/RFC7498, April 2015,
<https://www.rfc-editor.org/info/rfc7498>. <https://www.rfc-editor.org/info/rfc7498>.
[RFC7510] Xu, X., Sheth, N., Yong, L., Callon, R., and D. Black, [RFC7510] Xu, X., Sheth, N., Yong, L., Callon, R., and D. Black,
"Encapsulating MPLS in UDP", RFC 7510, "Encapsulating MPLS in UDP", RFC 7510,
DOI 10.17487/RFC7510, April 2015, DOI 10.17487/RFC7510, April 2015,
<https://www.rfc-editor.org/info/rfc7510>. <https://www.rfc-editor.org/info/rfc7510>.
[RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function
Chaining (SFC) Architecture", RFC 7665,
DOI 10.17487/RFC7665, October 2015,
<https://www.rfc-editor.org/info/rfc7665>.
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. 63 change blocks. 
187 lines changed or deleted 253 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/