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/ |