draft-ietf-bess-nsh-bgp-control-plane-02.txt   draft-ietf-bess-nsh-bgp-control-plane-03.txt 
BESS Working Group A. Farrel BESS Working Group A. Farrel
Internet-Draft J. Drake Internet-Draft J. Drake
Intended status: Standards Track E. Rosen Intended status: Standards Track E. Rosen
Expires: May 3, 2018 Juniper Networks Expires: September 19, 2018 Juniper Networks
J. Uttaro J. Uttaro
AT&T AT&T
L. Jalil L. Jalil
Verizon Verizon
October 30, 2017 March 18, 2018
BGP Control Plane for NSH SFC BGP Control Plane for NSH SFC
draft-ietf-bess-nsh-bgp-control-plane-02 draft-ietf-bess-nsh-bgp-control-plane-03
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.
This document adopts the SFC architecture described in RFC 7665. This document adopts the SFC architecture described in RFC 7665.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
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 May 3, 2018. This Internet-Draft will expire on September 19, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Functional Overview . . . . . . . . . . . . . . . . . . . 5 2.1. Functional Overview . . . . . . . . . . . . . . . . . . . 5
2.2. Control Plane Overview . . . . . . . . . . . . . . . . . 7 2.2. Control Plane Overview . . . . . . . . . . . . . . . . . 7
3. BGP SFC Routes . . . . . . . . . . . . . . . . . . . . . . . 9 3. BGP SFC Routes . . . . . . . . . . . . . . . . . . . . . . . 9
3.1. Service Function Instance Route (SFIR) . . . . . . . . . 10 3.1. Service Function Instance Route (SFIR) . . . . . . . . . 10
3.1.1. SFI Pool Identifier Extended Community . . . . . . . 11 3.1.1. SFI Pool Identifier Extended Community . . . . . . . 11
3.1.2. MPLS Mixed Swapping/Stacking Extended Community . . . 12 3.1.2. MPLS Mixed Swapping/Stacking Extended Community . . . 12
3.2. Service Function Path Route (SFPR) . . . . . . . . . . . 13 3.2. Service Function Path Route (SFPR) . . . . . . . . . . . 13
3.2.1. The SFP Attribute . . . . . . . . . . . . . . . . . . 13 3.2.1. The SFP Attribute . . . . . . . . . . . . . . . . . . 13
3.2.2. General Rules For The SFP Attribute . . . . . . . . . 18 3.2.2. General Rules For The SFP Attribute . . . . . . . . . 18
skipping to change at page 3, line 33 skipping to change at page 3, line 29
8.9.4. Parallel SFPs Downstream of the Choice . . . . . . . 44 8.9.4. Parallel SFPs Downstream of the Choice . . . . . . . 44
9. Security Considerations . . . . . . . . . . . . . . . . . . . 47 9. Security Considerations . . . . . . . . . . . . . . . . . . . 47
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48
10.1. New BGP AF/SAFI . . . . . . . . . . . . . . . . . . . . 48 10.1. New BGP AF/SAFI . . . . . . . . . . . . . . . . . . . . 48
10.2. New BGP Path Attribute . . . . . . . . . . . . . . . . . 48 10.2. New BGP Path Attribute . . . . . . . . . . . . . . . . . 48
10.3. New SFP Attribute TLVs Type Registry . . . . . . . . . . 48 10.3. New SFP Attribute TLVs Type Registry . . . . . . . . . . 48
10.4. New SFP Association Type Registry . . . . . . . . . . . 49 10.4. New SFP Association Type Registry . . . . . . . . . . . 49
10.5. New Service Function Type Registry . . . . . . . . . . . 49 10.5. New Service Function Type Registry . . . . . . . . . . . 49
10.6. New Generic Transitive Experimental Use Extended 10.6. New Generic Transitive Experimental Use Extended
Community Sub-Types . . . . . . . . . . . . . . . . . . 50 Community Sub-Types . . . . . . . . . . . . . . . . . . 50
10.7. SPI/SI Representation . . . . . . . . . . . . . . . . . 51 10.7. New BGP Transitive Extended Community Types . . . . . . 50
10.8. SPI/SI Representation . . . . . . . . . . . . . . . . . 51
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 51 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 51
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 51 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 51
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 51 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 51
13.1. Normative References . . . . . . . . . . . . . . . . . . 51 13.1. Normative References . . . . . . . . . . . . . . . . . . 51
13.2. Informative References . . . . . . . . . . . . . . . . . 52 13.2. Informative References . . . . . . . . . . . . . . . . . 52
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 53 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 53
1. Introduction 1. Introduction
As described in [RFC7498], the delivery of end-to-end services can As described in [RFC7498], the delivery of end-to-end services can
skipping to change at page 5, line 5 skipping to change at page 4, line 45
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.
This document adopts the SFC architecture described in [RFC7665]. This document adopts the SFC architecture described in [RFC7665].
1.1. Terminology 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
1.2. Terminology
This document uses the following terms from [RFC7665]: This document uses the following terms from [RFC7665]:
o Bidirectional Service Function Chain o Bidirectional Service Function Chain
o Classifier o Classifier
o Service Function (SF) o Service Function (SF)
o Service Function Chain (SFC) o Service Function Chain (SFC)
o Service Function Forwarder (SFF) o Service Function Forwarder (SFF)
o Service Function Instance (SFI) o Service Function Instance (SFI)
o Service Function Path (SFP) o Service Function Path (SFP)
o SFC branching o SFC branching
Additionally, this document uses the following terms from Additionally, this document uses the following terms from [RFC8300]:
[I-D.ietf-sfc-nsh]:
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)
skipping to change at page 5, line 48 skipping to change at page 5, line 47
o Service Function Overlay Network o Service Function Overlay Network
o Service Function Path Route (SFPR) o Service Function Path Route (SFPR)
o Service Function Type (SFT) o Service Function Type (SFT)
2. Overview 2. Overview
2.1. Functional Overview 2.1. Functional Overview
In [I-D.ietf-sfc-nsh] a Service Function Chain (SFC) is an ordered In [RFC8300] a Service Function Chain (SFC) is an ordered list of
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
skipping to change at page 6, line 22 skipping to change at page 6, line 21
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 Service Function, 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) [I-D.ietf-sfc-nsh] then prepends a Network Services Header (NSH) [RFC8300] containing
containing the assigned SPI/SI to that packet. Note that the the assigned SPI/SI to that packet. Note that the Classifier and the
Classifier and the node that hosts the first Service Function in a node that hosts the first Service Function in a Service Function Path
Service Function Path need not be located at the same point in the need not be located at the same point in the service function overlay
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, as described in
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
skipping to change at page 7, line 34 skipping to change at page 7, line 32
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 it MUST drop the packet and SHOULD log the event: such
logs MUST be subject to rate limits. logs MUST be 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 a new BGP AFI/SAFI (values to be assigned by IANA) for
"SFC Routes". Two SFC Route Types are defined by this document: the "SFC Routes". Two SFC Route Types are defined by this document: the
Service Function Instance Route (SFIR), and the Service Function Path Service Function Instance Route (SFIR), and the Service Function Path
Route (SFPR). As detailed in Section 3, the route type is indicated Route (SFPR). As detailed in Section 3, the route type is indicated
by a sub-field in the NLRI. 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 and the way to forward a packet to it
through the underlay network, i.e., IP address and encapsulation through the underlay network, i.e., IP address and encapsulation
information. information.
skipping to change at page 13, line 25 skipping to change at page 13, line 25
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 [I-D.ietf-sfc-nsh] and is The Service Path Identifier is defined in [RFC8300] and is the value
the value to be placed in the Service Path Identifier field of the to be placed in the Service Path Identifier field of the NSH header
NSH header of any packet sent on this Service Function Path. It is of any packet sent on this Service Function Path. It is expected
expected that one or more Controllers will originate these routes in that one or more Controllers will originate these routes in order to
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 Path attribute called the SFP attribute with value TBD3 to be
assigned by IANA. The first SFP attribute MUST be processed and assigned by IANA. The first SFP attribute MUST be processed and
subsequent instances MUST be ignored. subsequent instances MUST be ignored.
skipping to change at page 16, line 38 skipping to change at page 16, line 38
Figure 8: The Format of the Hop TLV Figure 8: The Format of the Hop TLV
The fields are as follows: The fields are as follows:
Type is set to 2 to indicate a Hop TLV. Type is set to 2 to indicate a Hop TLV.
Length indicates the length in octets of the Service Index and Hop Length indicates the length in octets of the Service Index and Hop
Details fields. Details fields.
The Service Index is defined in [I-D.ietf-sfc-nsh] and is the The Service Index is defined in [RFC8300] and is the value found
value found in the Service Index field of the NSH header that an in the Service Index field of the NSH header that an SFF will use
SFF will use to lookup to which next SFI a packet should be sent. to lookup to which next SFI a packet should be sent.
The Hop Details consist of a sequence of one or more SFT TLVs. The Hop Details consist of a sequence of one or more SFT TLVs.
3.2.1.3. The SFT TLV 3.2.1.3. The SFT TLV
There is one or more SFT TLV in each Hop TLV. There is one SFT TLV There is one or more SFT TLV in each Hop TLV. There is one SFT TLV
for each SFT supported in the specific hop of the SFP. The format of for each SFT supported in the specific hop of the SFP. The format of
the SFT TLV is shown in Figure 9. the SFT TLV is shown in Figure 9.
+--------------------------------------------+ +--------------------------------------------+
skipping to change at page 18, line 5 skipping to change at page 18, line 5
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 can be carried in the Hop TLV and is used when the data TLV that can be carried in the Hop TLV and is used when the data
representation is MPLS (see Section 7.6). It indicates to the representation is MPLS (see Section 7.6). It indicates to the
Classifier that imposes an MPLS label stack whether the current hop Classifier that imposes an MPLS label stack whether the current hop
is to use an {SPI, SI} label pair for label swapping or a {Context is to use an {SPI, SI} label pair for label swapping or a {Context
label, SF label}. See Section 7.7 for more details. label, SF label}. See Section 7.7 for more details.
3.2.1.5. SFP Traversal With MPLS Label Stack 3.2.1.5. SFP Traversal With MPLS Label Stack TLV
The MPLS Swapping/Stacking TLV (Type value 5) is a zero length sub- The SFP Traversal With MPLS Label Stack TLV (Type value 5) is a zero
TLV that can be carried in the SFP Attribute and indicates to the length sub-TLV that can be carried in the SFP Attribute and indicates
Classifier and the SFFs on the SFP that an MPLS labels stack with to the Classifier and the SFFs on the SFP that an MPLS labels stack
label swapping/stacking is to be used for packets traversing the SFP. with label swapping/stacking is to be used for packets traversing the
All of the SFF specified at each the SFP's hops must have advertised SFP. All of the SFF specified at each the SFP's hops must have
an SPI/SI Representation sub-TLV (see Section 7.6) with bit 0 set to advertised an SPI/SI Representation sub-TLV (see Section 7.6) with
0 and bit 1 set to 1 for the SFP to be considered usable. bit 0 set to 0 and bit 1 set to 1 for the SFP to be considered
usable.
3.2.2. General Rules For The SFP Attribute 3.2.2. General Rules For The SFP Attribute
It is possible for the same SFI, as described by an SFIR, to be used It is possible for the same SFI, as described by an SFIR, to be used
in multiple SFPRs. in multiple SFPRs.
When two SFPRs have the same SPI but different SFPR-RDs there can be When two SFPRs have the same SPI but different SFPR-RDs there can be
three cases: three cases:
o Two or more Controllers are originating SFPRs for the same SFP. o Two or more Controllers are originating SFPRs for the same SFP.
skipping to change at page 20, line 30 skipping to change at page 20, line 30
particular SPI and identifies one or more SFs (distinguished by particular SPI and identifies one or more SFs (distinguished by
their SFTs) and for each SF a set of SFIs that instantiate the SF. their SFTs) and for each SF a set of SFIs that instantiate the SF.
The values of the SI indicate the order in which the SFs are to be The values of the SI indicate the order in which the SFs are to be
executed in the SFP that is represented by the SPI. executed in the SFP that is represented by the SPI.
o The SI is used in the NSH to identify the entries in the SFP. o The SI is used in the NSH to identify the entries in the SFP.
Note that the SI values have meaning only relative to a specific Note that the SI values have meaning only relative to a specific
path. They have no semantic other than to indicate the order of path. They have no semantic other than to indicate the order of
Service Functions within the path and are assumed to be Service Functions within the path and are assumed to be
monotonically decreasing from the start to the end of the path monotonically decreasing from the start to the end of the path
[I-D.ietf-sfc-nsh]. [RFC8300].
o Each Service Index is associated with a set of one or more Service o Each Service Index is associated with a set of one or more Service
Function Instances that can be used to provide the indexed Service Function Instances that can be used to provide the indexed Service
Function within the path. Each member of the set comprises: Function within the path. Each member of the set comprises:
* The RD used in an SFIR advertisement of the SFI. * The RD used in an SFIR advertisement of the SFI.
* The SFT that indicates the type of function as used in the same * The SFT that indicates the type of function as used in the same
SFIR advertisement of the SFI. SFIR advertisement of the SFI.
skipping to change at page 23, line 7 skipping to change at page 23, line 7
which they are included. They do not retain state for all SFPs which they are included. They do not retain state for all SFPs
advertised. advertised.
An SFF may also install forwarding state to support looping, jumping, An SFF may also install forwarding state to support looping, jumping,
and branching. The protocol mechanism for explicit control of and branching. The protocol mechanism for explicit control of
looping, jumping, and branching is described in Section 6.1 using a looping, jumping, and branching is described in Section 6.1 using a
special value of the SFT within an entry in an SFPR. special value of the SFT within an entry in an SFPR.
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 [I-D.ietf-sfc-nsh] is to The behavior of an SF as described in [RFC8300] is to decrement the
decrement the value of the SI field in the NSH by one before value of the SI field in the NSH by one before returning a packet to
returning a packet to the local SFF for further processing. This the local SFF for further processing. This means that there is a
means that there is a good reason to assume that the SFP is composed good reason to assume that the SFP is composed of a series of SFs
of a series of SFs each indicated by an SI value one less than the each indicated by an SI value one less than the previous.
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
SPI. Consider the case where an SPI needs to be modified by the SPI. Consider the case where an SPI needs to be modified by the
insertion or removal of an SF. In the latter case this would lead to insertion or removal of an SF. In the latter case this would lead to
a "gap" in the sequence of SIs, and in the former case, this could a "gap" in the sequence of SIs, and in the former case, this could
only be achieved if a gap already existed into which the new SF with only be achieved if a gap already existed into which the new SF with
its new SI value could be inserted. Otherwise, all "downstream" SFs its new SI value could be inserted. Otherwise, all "downstream" SFs
would need to be renumbered. would need to be renumbered.
Now, of course, such renumbering could be performed, but would lead Now, of course, such renumbering could be performed, but would lead
skipping to change at page 24, line 11 skipping to change at page 24, line 7
o If the SI indicates a known entry in the SFP, the SFF MUST process o If the SI indicates a known entry in the SFP, the SFF MUST process
the packet as normal, looking up the SI and determining whether to the packet as normal, looking up the SI and determining whether to
deliver the packet to a local SFI or to forward it to another SFF. deliver the packet to a local SFI or to forward it to another SFF.
o If the SI does not match an entry in the SFP, the SFF MUST reduce o If the SI does not match an entry in the SFP, the SFF MUST reduce
the SI value to the next (smaller) value present in the SFP and the SI value to the next (smaller) value present in the SFP and
process the packet using that SI. process the packet using that SI.
o If there is no smaller SI (i.e., if the end of the SFP has been o If there is no smaller SI (i.e., if the end of the SFP has been
reached) the SFF MUST treat the SI value as invalid as described reached) the SFF MUST treat the SI value as invalid as described
in [I-D.ietf-sfc-nsh]. in [RFC8300].
SFF implementations MAY choose to only support contiguous SI values SFF implementations MAY choose to only support contiguous SI values
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 [I-D.ietf-sfc-nsh]. 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.
skipping to change at page 26, line 20 skipping to change at page 26, line 20
the SI in the NSH with a higher value instead of decreasing it as the SI in the NSH with a higher value instead of decreasing it as
would normally be the case to determine the next hop in the path. would normally be the case to determine the next hop in the path.
Section 2 also describes how an SFI or an SFF may cause a packets to Section 2 also describes how an SFI or an SFF may cause a packets to
"jump forward" to an SF on a path that is not the immediate next SF "jump forward" to an SF on a path that is not the immediate next SF
in the SFP. This is simply achieved by replacing the SI in the NSH in the SFP. This is simply achieved by replacing the SI in the NSH
with a lower value than would be achieved by decreasing it by the with a lower value than would be achieved by decreasing it by the
normal amount. normal amount.
A more complex option to move packets from one SFP to another is A more complex option to move packets from one SFP to another is
described in [I-D.ietf-sfc-nsh] and Section 2 where it is termed described in [RFC8300] and Section 2 where it is termed "branching".
"branching". This mechanism allows an SFI or SFF to make a choice of This mechanism allows an SFI or SFF to make a choice of downstream
downstream treatments for packets based on local policy and output of treatments for packets based on local policy and output of the local
the local SF. Branching is achieved by changing the SPI in the NSH SF. Branching is achieved by changing the SPI in the NSH to indicate
to indicate the new path and setting the SI to indicate the point in the new path and setting the SI to indicate the point in the path at
the path at which the packets should enter. which the packets should enter.
Note that the NSH does not include a marker to indicate whether a Note that the NSH does not include a marker to indicate whether a
specific packet has been around a loop before. Therefore, the use of specific packet has been around a loop before. Therefore, the use of
NSH metadata may be required in order to prevent infinite loops. NSH metadata may be required in order to prevent infinite loops.
6.1. Protocol Control of Looping, Jumping, and Branching 6.1. Protocol Control of Looping, Jumping, and Branching
If the SFT value in an SFT TLV in an SFPR has the Special Purpose SFT If the SFT value in an SFT TLV in an SFPR has the Special Purpose SFT
value "Change Sequence" (see Section 10) then this is an indication value "Change Sequence" (see Section 10) then this is an indication
that the SFF may make a loop, jump, or branch according to local that the SFF may make a loop, jump, or branch according to local
skipping to change at page 28, line 29 skipping to change at page 28, line 29
on the same packet when it is forwarded along the path but MAY choose 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 to generate a new entropy indicator so long as the method used is
constant for all packets. Note that preserving per packet entropy constant for all packets. Note that preserving per packet entropy
may require that the entropy indicator is passed to and returned by 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. the SFI to prevent the SFF from having to maintain per-packet state.
7.2. Correlating Service Function Path Instances 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 [I-D.ietf-sfc-nsh]) However, packets on SFPs in the data plane (per [RFC8300]) do not
do not contain a direction indicator, so each direction must use a contain a direction indicator, so each direction must use a different
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
one direction of a bidirectional pair of SFPs where the other in the one direction of a bidirectional pair of SFPs where the other in the
pair is advertised in the SFPR with RD as carried in the Associated pair is advertised in the SFPR with RD as carried in the Associated
SFPR-RD field of the Association TLV. The SPI carried in the SFPR-RD field of the Association TLV. The SPI carried in the
Associated SPI field of the Association TLV provides a cross-check Associated SPI field of the Association TLV provides a cross-check
and should match the SPI advertised in the SFPR with RD as carried in and should match the SPI advertised in the SFPR with RD as carried in
the Associated SFPR-RD field of the Association TLV. the Associated SFPR-RD field of the Association TLV.
skipping to change at page 31, line 25 skipping to change at page 31, line 25
The extended community contains the Service Path Identifier (SPI), The extended community contains the Service Path Identifier (SPI),
Service Index (SI), and Service Function Type (SFT) as defined Service Index (SI), and Service Function Type (SFT) as defined
elsewhere in this document. Thus, each action extended community elsewhere in this document. Thus, each action extended community
defines the entry point (not necessarily the first hop) into a defines the entry point (not necessarily the first hop) into a
specific service function path. This allows, for example, different specific service function path. This allows, for example, different
flows to enter the same service function path at different points. flows to enter the same service function path at different points.
Note that a given Flow Spec update according to [RFC5575] may include Note that a given Flow Spec update according to [RFC5575] may include
multiple of these action extended communities, and that if a given multiple of these action extended communities, and that if a given
action extended community does not contain an installed SFPR with the action extended community does not contain an installed SFPR with the
specified [SPI, SI, SFT] it MUST NOT be used for dispositioning the specified {SPI, SI, SFT} it MUST NOT be used for dispositioning the
packets of the specified flow. packets of the specified flow.
The normal case of packet classification for SFC will see a packet The normal case of packet classification for SFC will see a packet
enter the SFP at its first hop. In this case the SI in the extended enter the SFP at its first hop. In this case the SI in the extended
community is superfluous and the SFT may also be unnecessary. To community is superfluous and the SFT may also be unnecessary. To
allow these cases to be handled, a special meaning is assigned to a allow these cases to be handled, a special meaning is assigned to a
Service Index of zero (not a valid value) and an SFT of zero (a Service Index of zero (not a valid value) and an SFT of zero (a
reserved value in the registry - see Section 10.5). reserved value in the registry - see Section 10.5).
o If an SFC Classifiers Extended Community is received with SI = 0 o If an SFC Classifiers Extended Community is received with SI = 0
skipping to change at page 47, line 41 skipping to change at page 47, line 41
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].
Service Function Chaining provides a significant attack opportunity: Service Function Chaining provides a significant attack opportunity:
packets can be diverted from their normal paths through the network, packets can be diverted from their normal paths through the network,
can be made to execute unexpected functions, and the functions that can be made to execute unexpected functions, and the functions that
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 [I-D.ietf-sfc-nsh]. 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.
10. IANA Considerations 10. IANA Considerations
skipping to change at page 50, line 40 skipping to change at page 50, line 40
Value | Name | Reference | Date Value | Name | Reference | Date
------+-----------------------+---------------+--------------- ------+-----------------------+---------------+---------------
1 | Change Sequence | [This.I-D] | Date-to-be-set 1 | Change Sequence | [This.I-D] | Date-to-be-set
10.6. New Generic Transitive Experimental Use Extended Community Sub- 10.6. New Generic Transitive Experimental Use Extended Community Sub-
Types Types
IANA maintains a registry of "Border Gateway Protocol (BGP) IANA maintains a registry of "Border Gateway Protocol (BGP)
Parameters" with a subregistry of "Generic Transitive Experimental Parameters" with a subregistry of "Generic Transitive Experimental
Use Extended Community Sub-Type". IANA is requested to assign a new Use Extended Community Sub-Type". IANA is requested to assign a new
sub-types as follows: sub-type as follows:
"Flow Spec for SFC Classifiers" (TBD4 in this document) with this "Flow Spec for SFC Classifiers" (TBD4 in this document) with this
document as the reference. document as the reference.
10.7. New BGP Transitive Extended Community Types
IANA maintains a registry of "Border Gateway Protocol (BGP)
Parameters" with a subregistry of "BGP Transitive Extended Community
Types". IANA is requested to assign new types as follows:
"SFI Pool Identifier" (TBD6 in this document) with this document "SFI Pool Identifier" (TBD6 in this document) with this document
as the reference. as the reference.
"MPLS Label Stack Mixed Swapping/Stacking Labels" (TBD7 in this "MPLS Label Stack Mixed Swapping/Stacking Labels" (TBD7 in this
document) with this document as the reference. document) with this document as the reference.
10.7. SPI/SI Representation 10.8. SPI/SI Representation
IANA is requested to assign a codepoint from the "BGP Tunnel IANA is requested to assign a codepoint from the "BGP Tunnel
Encapsulation Attribute Sub-TLVs" registry for the "SPI/SI Encapsulation Attribute Sub-TLVs" registry for the "SPI/SI
Representation Sub-TLV" (TBD5 in this document) with this document Representation Sub-TLV" (TBD5 in this document) with this document
being the reference. being the reference.
11. Contributors 11. Contributors
Stuart Mackie Stuart Mackie
Juniper Networks Juniper Networks
skipping to change at page 51, line 40 skipping to change at page 51, line 46
Thanks to Tony Przygienda for helpful comments, and to Joel Halpern Thanks to Tony Przygienda for helpful comments, and to Joel Halpern
for discussions that improved this document. for discussions that improved this document.
13. References 13. References
13.1. Normative References 13.1. Normative References
[I-D.ietf-idr-tunnel-encaps] [I-D.ietf-idr-tunnel-encaps]
Rosen, E., Patel, K., and G. Velde, "The BGP Tunnel Rosen, E., Patel, K., and G. Velde, "The BGP Tunnel
Encapsulation Attribute", draft-ietf-idr-tunnel-encaps-07 Encapsulation Attribute", draft-ietf-idr-tunnel-encaps-09
(work in progress), July 2017. (work in progress), February 2018.
[I-D.ietf-sfc-nsh]
Quinn, P., Elzur, U., and C. Pignataro, "Network Service
Header (NSH)", draft-ietf-sfc-nsh-27 (work in progress),
October 2017.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[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 52, line 34 skipping to change at page 52, line 34
[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>.
[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
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed.,
"Network Service Header (NSH)", RFC 8300,
DOI 10.17487/RFC8300, January 2018,
<https://www.rfc-editor.org/info/rfc8300>.
13.2. Informative References 13.2. Informative References
[I-D.farrel-mpls-sfc] [I-D.farrel-mpls-sfc]
Farrel, A., Bryant, S., and J. Drake, "An MPLS-Based Farrel, A., Bryant, S., and J. Drake, "An MPLS-Based
Forwarding Plane for Service Function Chaining", draft- Forwarding Plane for Service Function Chaining", draft-
farrel-mpls-sfc-02 (work in progress), October 2017. farrel-mpls-sfc-04 (work in progress), March 2018.
[RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and
L. Yong, "The Use of Entropy Labels in MPLS Forwarding", L. Yong, "The Use of Entropy Labels in MPLS Forwarding",
RFC 6790, DOI 10.17487/RFC6790, November 2012, RFC 6790, DOI 10.17487/RFC6790, November 2012,
<https://www.rfc-editor.org/info/rfc6790>. <https://www.rfc-editor.org/info/rfc6790>.
[RFC7498] Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for [RFC7498] Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for
Service Function Chaining", RFC 7498, Service Function Chaining", RFC 7498,
DOI 10.17487/RFC7498, April 2015, DOI 10.17487/RFC7498, April 2015,
<https://www.rfc-editor.org/info/rfc7498>. <https://www.rfc-editor.org/info/rfc7498>.
 End of changes. 31 change blocks. 
70 lines changed or deleted 83 lines changed or added

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