draft-ietf-bess-nsh-bgp-control-plane-05.txt | draft-ietf-bess-nsh-bgp-control-plane-06.txt | |||
---|---|---|---|---|
BESS Working Group A. Farrel | BESS Working Group A. Farrel | |||
Internet-Draft Old Dog Consulting | Internet-Draft Old Dog Consulting | |||
Intended status: Standards Track J. Drake | Intended status: Standards Track J. Drake | |||
Expires: July 16, 2019 E. Rosen | Expires: August 29, 2019 E. Rosen | |||
Juniper Networks | Juniper Networks | |||
J. Uttaro | J. Uttaro | |||
AT&T | AT&T | |||
L. Jalil | L. Jalil | |||
Verizon | Verizon | |||
January 12, 2019 | February 25, 2019 | |||
BGP Control Plane for NSH SFC | BGP Control Plane for NSH SFC | |||
draft-ietf-bess-nsh-bgp-control-plane-05 | draft-ietf-bess-nsh-bgp-control-plane-06 | |||
Abstract | Abstract | |||
This document describes the use of BGP as a control plane for | This document describes the use of BGP as a control plane for | |||
networks that support Service Function Chaining (SFC). The document | networks that support Service Function Chaining (SFC). The document | |||
introduces a new BGP address family called the SFC AFI/SAFI with two | introduces a new BGP address family called the SFC AFI/SAFI with two | |||
route types. One route type is originated by a node to advertise | route types. One route type is originated by a node to advertise | |||
that it hosts a particular instance of a specified service function. | that it hosts a particular instance of a specified service function. | |||
This route type also provides "instructions" on how to send a packet | This route type also provides "instructions" on how to send a packet | |||
to the hosting node in a way that indicates that the service function | to the hosting node in a way that indicates that the service function | |||
skipping to change at page 1, line 48 ¶ | skipping to change at page 1, line 48 ¶ | |||
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 July 15, 2019. | This Internet-Draft will expire on Augus7 29, 2019. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2019 IETF Trust and the persons identified as the | Copyright (c) 2019 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
(https://trustee.ietf.org/license-info) in effect on the date of | (https://trustee.ietf.org/license-info) in effect on the date of | |||
publication of this document. Please review these documents | publication of this document. Please review these documents | |||
skipping to change at page 3, line 6 ¶ | skipping to change at page 3, line 6 ¶ | |||
6.2. Implications for Forwarding State . . . . . . . . . . . . 27 | 6.2. Implications for Forwarding State . . . . . . . . . . . . 27 | |||
7. Advanced Topics . . . . . . . . . . . . . . . . . . . . . . . 28 | 7. Advanced Topics . . . . . . . . . . . . . . . . . . . . . . . 28 | |||
7.1. Preserving Entropy . . . . . . . . . . . . . . . . . . . 28 | 7.1. Preserving Entropy . . . . . . . . . . . . . . . . . . . 28 | |||
7.2. Correlating Service Function Path Instances . . . . . . . 28 | 7.2. Correlating Service Function Path Instances . . . . . . . 28 | |||
7.3. Considerations for Stateful Service Functions . . . . . . 29 | 7.3. Considerations for Stateful Service Functions . . . . . . 29 | |||
7.4. VPN Considerations and Private Service Functions . . . . 30 | 7.4. VPN Considerations and Private Service Functions . . . . 30 | |||
7.5. Flow Spec for SFC Classifiers . . . . . . . . . . . . . . 30 | 7.5. Flow Spec for SFC Classifiers . . . . . . . . . . . . . . 30 | |||
7.6. Choice of Data Plane SPI/SI Representation . . . . . . . 32 | 7.6. Choice of Data Plane SPI/SI Representation . . . . . . . 32 | |||
7.6.1. MPLS Representation of the SPI/SI . . . . . . . . . . 33 | 7.6.1. MPLS Representation of the SPI/SI . . . . . . . . . . 33 | |||
7.7. MPLS Label Swapping/Stacking Operation . . . . . . . . . 33 | 7.7. MPLS Label Swapping/Stacking Operation . . . . . . . . . 33 | |||
8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 33 | 7.8. Support for MPLS-Encapsulated NSH Packets . . . . . . . . 33 | |||
8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 34 | ||||
8.1. Example Explicit SFP With No Choices . . . . . . . . . . 35 | 8.1. Example Explicit SFP With No Choices . . . . . . . . . . 35 | |||
8.2. Example SFP With Choice of SFIs . . . . . . . . . . . . . 35 | 8.2. Example SFP With Choice of SFIs . . . . . . . . . . . . . 36 | |||
8.3. Example SFP With Open Choice of SFIs . . . . . . . . . . 36 | 8.3. Example SFP With Open Choice of SFIs . . . . . . . . . . 37 | |||
8.4. Example SFP With Choice of SFTs . . . . . . . . . . . . . 37 | 8.4. Example SFP With Choice of SFTs . . . . . . . . . . . . . 37 | |||
8.5. Example Correlated Bidirectional SFPs . . . . . . . . . . 37 | 8.5. Example Correlated Bidirectional SFPs . . . . . . . . . . 38 | |||
8.6. Example Correlated Asymmetrical Bidirectional SFPs . . . 38 | 8.6. Example Correlated Asymmetrical Bidirectional SFPs . . . 38 | |||
8.7. Example Looping in an SFP . . . . . . . . . . . . . . . . 38 | 8.7. Example Looping in an SFP . . . . . . . . . . . . . . . . 39 | |||
8.8. Example Branching in an SFP . . . . . . . . . . . . . . . 39 | 8.8. Example Branching in an SFP . . . . . . . . . . . . . . . 40 | |||
8.9. Examples of SFPs with Stateful Service Functions . . . . 40 | 8.9. Examples of SFPs with Stateful Service Functions . . . . 40 | |||
8.9.1. Forward and Reverse Choice Made at the SFF . . . . . 40 | 8.9.1. Forward and Reverse Choice Made at the SFF . . . . . 41 | |||
8.9.2. Parallel End-to-End SFPs with Shared SFF . . . . . . 41 | 8.9.2. Parallel End-to-End SFPs with Shared SFF . . . . . . 42 | |||
8.9.3. Parallel End-to-End SFPs with Separate SFFs . . . . . 42 | 8.9.3. Parallel End-to-End SFPs with Separate SFFs . . . . . 43 | |||
8.9.4. Parallel SFPs Downstream of the Choice . . . . . . . 44 | 8.9.4. Parallel SFPs Downstream of the Choice . . . . . . . 45 | |||
9. Security Considerations . . . . . . . . . . . . . . . . . . . 47 | 9. Security Considerations . . . . . . . . . . . . . . . . . . . 48 | |||
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48 | 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49 | |||
10.1. New BGP AF/SAFI . . . . . . . . . . . . . . . . . . . . 48 | 10.1. New BGP AF/SAFI . . . . . . . . . . . . . . . . . . . . 49 | |||
10.2. New BGP Path Attribute . . . . . . . . . . . . . . . . . 48 | 10.2. New BGP Path Attribute . . . . . . . . . . . . . . . . . 49 | |||
10.3. New SFP Attribute TLVs Type Registry . . . . . . . . . . 48 | 10.3. New SFP Attribute TLVs Type Registry . . . . . . . . . . 49 | |||
10.4. New SFP Association Type Registry . . . . . . . . . . . 49 | 10.4. New SFP Association Type Registry . . . . . . . . . . . 50 | |||
10.5. New Service Function Type Registry . . . . . . . . . . . 49 | 10.5. New Service Function Type Registry . . . . . . . . . . . 50 | |||
10.6. New Generic Transitive Experimental Use Extended | 10.6. New Generic Transitive Experimental Use Extended | |||
Community Sub-Types . . . . . . . . . . . . . . . . . . 50 | Community Sub-Types . . . . . . . . . . . . . . . . . . 51 | |||
10.7. New BGP Transitive Extended Community Types . . . . . . 50 | 10.7. New BGP Transitive Extended Community Types . . . . . . 51 | |||
10.8. SPI/SI Representation . . . . . . . . . . . . . . . . . 51 | 10.8. SPI/SI Representation . . . . . . . . . . . . . . . . . 52 | |||
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 51 | 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 52 | |||
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 51 | 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 52 | |||
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 51 | 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 52 | |||
13.1. Normative References . . . . . . . . . . . . . . . . . . 51 | 13.1. Normative References . . . . . . . . . . . . . . . . . . 52 | |||
13.2. Informative References . . . . . . . . . . . . . . . . . 52 | 13.2. Informative References . . . . . . . . . . . . . . . . . 53 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 53 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 54 | |||
1. Introduction | 1. Introduction | |||
As described in [RFC7498], the delivery of end-to-end services can | As described in [RFC7498], the delivery of end-to-end services can | |||
require a packet to pass through a series of Service Functions (SFs) | require a packet to pass through a series of Service Functions (SFs) | |||
(e.g., classifiers, firewalls, TCP accelerators, and server load | (e.g., classifiers, firewalls, TCP accelerators, and server load | |||
balancers) in a specified order: this is termed "Service Function | balancers) in a specified order: this is termed "Service Function | |||
Chaining" (SFC). There are a number of issues associated with | Chaining" (SFC). There are a number of issues associated with | |||
deploying and maintaining service function chaining in production | deploying and maintaining service function chaining in production | |||
networks, which are described below. | networks, which are described below. | |||
skipping to change at page 11, line 26 ¶ | skipping to change at page 11, line 26 ¶ | |||
determined by provisioning. If two SFIRs are originated from | determined by provisioning. If two SFIRs are originated from | |||
different administrative domains, they must have different RDs. In | different administrative domains, they must have different RDs. In | |||
particular, SFIRs from different VPNs (for different service function | particular, SFIRs from different VPNs (for different service function | |||
overlay networks) must have different RDs, and those RDs must be | overlay networks) must have different RDs, and those RDs must be | |||
different from any non-VPN SFIRs. | different from any non-VPN SFIRs. | |||
The Service Function Type identifies a service function, e.g., | The Service Function Type identifies a service function, e.g., | |||
classifier, firewall, load balancer, etc. There may be several SFIs | classifier, firewall, load balancer, etc. There may be several SFIs | |||
that can perform a given Service Function. Each node hosting an SFI | that can perform a given Service Function. Each node hosting an SFI | |||
must originate an SFIR for each type of SF that it hosts, and it may | must originate an SFIR for each type of SF that it hosts, and it may | |||
advertize an SFIR for each instance of each type of SF. The SFIR | advertise an SFIR for each instance of each type of SF. The SFIR | |||
representing a given SFI will contain an NLRI with RD field set to an | representing a given SFI will contain an NLRI with RD field set to an | |||
RD as specified above, and with SFT field set to identify that SFI's | RD as specified above, and with SFT field set to identify that SFI's | |||
Service Function Type. The values for the SFT field are taken from a | Service Function Type. The values for the SFT field are taken from a | |||
registry administered by IANA (see Section 10). A BGP Update | registry administered by IANA (see Section 10). A BGP Update | |||
containing one or more SFIRs will also include a Tunnel Encapsulation | containing one or more SFIRs will also include a Tunnel Encapsulation | |||
attribute [I-D.ietf-idr-tunnel-encaps]. If a data packet needs to be | attribute [I-D.ietf-idr-tunnel-encaps]. If a data packet needs to be | |||
sent to an SFI identified in one of the SFIRs, it will be | sent to an SFI identified in one of the SFIRs, it will be | |||
encapsulated as specified by the Tunnel Encapsulation attribute, and | encapsulated as specified by the Tunnel Encapsulation attribute, and | |||
then transmitted through the underlay network. | then transmitted through the underlay network. | |||
skipping to change at page 12, line 37 ¶ | skipping to change at page 12, line 37 ¶ | |||
+--------------------------------------------+ | +--------------------------------------------+ | |||
| Type = 0x80 (1 octet) | | | Type = 0x80 (1 octet) | | |||
+--------------------------------------------| | +--------------------------------------------| | |||
| Sub-Type = TBD7 (1 octet) | | | Sub-Type = TBD7 (1 octet) | | |||
+--------------------------------------------| | +--------------------------------------------| | |||
| SFC Context Label (3 octets) | | | SFC Context Label (3 octets) | | |||
+--------------------------------------------| | +--------------------------------------------| | |||
| SF Label (3 octets) | | | SF Label (3 octets) | | |||
+--------------------------------------------+ | +--------------------------------------------+ | |||
Figure 5: The MPLS Mixed Swapping/Stacking Labels | Figure 5: The MPLS Mixed Swapping/Stacking Extended Community | |||
Note that it is assumed that each SFF has one or more globally unique | Note that it is assumed that each SFF has one or more globally unique | |||
SFC Context Labels and that the context label space and the SPI | SFC Context Labels and that the context label space and the SPI | |||
address space are disjoint. | address space are disjoint. | |||
If an SFF supports SFP Traversal with an MPLS Label Stack it MUST | ||||
include this extended community with the SFIRs that it advertises. | ||||
See Section 7.7 for a description of how this extended community is | See Section 7.7 for a description of how this extended community is | |||
used. | used. | |||
3.2. Service Function Path Route (SFPR) | 3.2. Service Function Path Route (SFPR) | |||
Figure 6 shows the Route Type specific NLRI of the SFPR. | Figure 6 shows the Route Type specific NLRI of the SFPR. | |||
+-----------------------------------------------+ | +-----------------------------------------------+ | |||
| Route Distinguisher (RD) (8 octets) | | | Route Distinguisher (RD) (8 octets) | | |||
+-----------------------------------------------+ | +-----------------------------------------------+ | |||
skipping to change at page 15, line 37 ¶ | skipping to change at page 15, line 37 ¶ | |||
one value is defined in this document: type 1 indicates | one value is defined in this document: type 1 indicates | |||
association of two unidirectional SFPs to form a bidirectional | association of two unidirectional SFPs to form a bidirectional | |||
SFP. An SFP attribute SHOULD NOT contain more than one | SFP. An SFP attribute SHOULD NOT contain more than one | |||
Association TLV with Association Type 1: if more than one is | Association TLV with Association Type 1: if more than one is | |||
present, the first one MUST be processed and subsequent instances | present, the first one MUST be processed and subsequent instances | |||
MUST be ignored. Note that documents that define new Association | MUST be ignored. Note that documents that define new Association | |||
Types must also define the presence rules for Association TLVs of | Types must also define the presence rules for Association TLVs of | |||
the new type. | the new type. | |||
The Associated SFPR-RD contains the RD of the associated SFP as | The Associated SFPR-RD contains the RD of the associated SFP as | |||
advertized in an SFPR. | advertised in an SFPR. | |||
The Associated SPI contains the SPI of the associated SFP as | The Associated SPI contains the SPI of the associated SFP as | |||
advertised in an SFPR. | advertised in an SFPR. | |||
Association TLVs with unknown Association Type values SHOULD be | Association TLVs with unknown Association Type values SHOULD be | |||
ignored. Association TLVs that contain an Associated SFPR-RD value | ignored. Association TLVs that contain an Associated SFPR-RD value | |||
equal to the RD of the SFPR in which they are contained SHOULD be | equal to the RD of the SFPR in which they are contained SHOULD be | |||
ignored. If the Associated SPI is not equal to the SPI advertised in | ignored. If the Associated SPI is not equal to the SPI advertised in | |||
the SFPR indicated by the Associated SFPR-RD then the Association TLV | the SFPR indicated by the Associated SFPR-RD then the Association TLV | |||
SHOULD be ignored. | SHOULD be ignored. | |||
skipping to change at page 18, line 21 ¶ | skipping to change at page 18, line 21 ¶ | |||
current hop is to use an {SFC Context Label, SF label} rather than an | current hop is to use an {SFC Context Label, SF label} rather than an | |||
{SPI, SF} label pair. See Section 7.7 for more details. | {SPI, SF} label pair. See Section 7.7 for more details. | |||
3.2.1.5. SFP Traversal With MPLS Label Stack TLV | 3.2.1.5. SFP Traversal With MPLS Label Stack TLV | |||
The SFP Traversal With MPLS Label Stack TLV (Type value 5) is a zero | The SFP Traversal With MPLS Label Stack TLV (Type value 5) is a zero | |||
length sub-TLV that can be carried in the SFP Attribute and indicates | length sub-TLV that can be carried in the SFP Attribute and indicates | |||
to the Classifier and the SFFs on the SFP that an MPLS labels stack | to the Classifier and the SFFs on the SFP that an MPLS labels stack | |||
with label swapping/stacking is to be used for packets traversing the | with label swapping/stacking is to be used for packets traversing the | |||
SFP. All of the SFF specified at each the SFP's hops must have | SFP. All of the SFF specified at each the SFP's hops must have | |||
advertised an SPI/SI Representation sub-TLV (see Section 7.6) with | advertised an MPLS Mixed Swapping/Stacking Extended Community (see | |||
bit 0 set to 0 and bit 1 set to 1 for the SFP to be considered | Section 3.1.2) for the SFP to be considered usable. | |||
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 23, line 11 ¶ | skipping to change at page 23, line 11 ¶ | |||
The installed forwarding state may change over time reacting to | The installed forwarding state may change over time reacting to | |||
changes in the underlay network and the availability of particular | changes in the underlay network and the availability of particular | |||
SFIs. | SFIs. | |||
Note that SFFs only create and store forwarding state for the SFPs on | Note that SFFs only create and store forwarding state for the SFPs on | |||
which they are included. They do not retain state for all SFPs | which they are included. They do not retain state for all SFPs | |||
advertised. | advertised. | |||
An SFF may also install forwarding state to support looping, jumping, | An SFF may also install forwarding state to support looping, jumping, | |||
and branching. The protocol mechanism for explicit control of | and branching. The protocol mechanism for explicit control of | |||
looping, jumping, and branching uses a specific resereved SFT value | looping, jumping, and branching uses a specific reserved SFT value | |||
at a given hop of an SFPR and is described in Section 6.1. | at a given hop of an SFPR and is described in Section 6.1. | |||
4.5.1. Processing With 'Gaps' in the SI Sequence | 4.5.1. Processing With 'Gaps' in the SI Sequence | |||
The behavior of an SF as described in [RFC8300] is to decrement the | The behavior of an SF as described in [RFC8300] is to decrement the | |||
value of the SI field in the NSH by one before returning a packet to | value of the SI field in the NSH by one before returning a packet to | |||
the local SFF for further processing. This means that there is a | the local SFF for further processing. This means that there is a | |||
good reason to assume that the SFP is composed of a series of SFs | good reason to assume that the SFP is composed of a series of SFs | |||
each indicated by an SI value one less than the previous. | each indicated by an SI value one less than the previous. | |||
skipping to change at page 33, line 31 ¶ | skipping to change at page 33, line 31 ¶ | |||
and processing instructions to achieve the semantics of a logical | and processing instructions to achieve the semantics of a logical | |||
NSH. The label stack is encoded as shown in [I-D.ietf-mpls-sfc]. | NSH. The label stack is encoded as shown in [I-D.ietf-mpls-sfc]. | |||
7.7. MPLS Label Swapping/Stacking Operation | 7.7. MPLS Label Swapping/Stacking Operation | |||
When a classifier constructs an MPLS label stack for an SFP it starts | When a classifier constructs an MPLS label stack for an SFP it starts | |||
with that SFP' last hop. If the last hop requires an {SPI, SI} label | with that SFP' last hop. If the last hop requires an {SPI, SI} label | |||
pair for label swapping, it pushes the SI (set to the SI value of the | pair for label swapping, it pushes the SI (set to the SI value of the | |||
last hop) and the SFP's SPI onto the MPLS label stack. If the last | last hop) and the SFP's SPI onto the MPLS label stack. If the last | |||
hop requires a {context label, SFI label} label pair for label | hop requires a {context label, SFI label} label pair for label | |||
stcking it selects a specific SFIR and pushes that SFIR's SFI label | stacking it selects a specific SFIR and pushes that SFIR's SFI label | |||
and context label onto the MPLS label stack. | and context label onto the MPLS label stack. | |||
The classifier then moves sequentially back through the SFP one hop | The classifier then moves sequentially back through the SFP one hop | |||
at a time. For each hop, if the hop requires an {SPI, SI]} and there | at a time. For each hop, if the hop requires an {SPI, SI]} and there | |||
is an {SPI, SI} at the top of the MPLS label stack, the SI is set to | is an {SPI, SI} at the top of the MPLS label stack, the SI is set to | |||
the SI value of the current hop. If there is not an {SPI, SI} at the | the SI value of the current hop. If there is not an {SPI, SI} at the | |||
top of the MPLS label stack, it pushes the SI (set to the SI value of | top of the MPLS label stack, it pushes the SI (set to the SI value of | |||
the current hop) and the SFP's SPI onto the MPLS label stack. | the current hop) and the SFP's SPI onto the MPLS label stack. | |||
If the hop requires a {context label, SFI label}, it selects a | If the hop requires a {context label, SFI label}, it selects a | |||
specific SFIR and pushes that SFIR's SFI label and context label onto | specific SFIR and pushes that SFIR's SFI label and context label onto | |||
the MPLS label stack. | the MPLS label stack. | |||
7.8. Support for MPLS-Encapsulated NSH Packets | ||||
[I-D.ietf-mpls-sfc-encapsulation] describes how to transport SFC | ||||
packets using the NSH over an MPLS transport network. Signaling MPLS | ||||
encapsulation of SFC packets using the NSH is also supported by this | ||||
document by using the "BGP Tunnel Encapsulation Attribute Sub-TLV" | ||||
with the codepoint 10 (representing "MPLS Label Stack") from the "BGP | ||||
Tunnel Encapsulation Attribute Sub-TLVs" registry defined in | ||||
[I-D.ietf-idr-tunnel-encaps], and also using the "SFP Traversal With | ||||
MPLS Label Stack TLV" and the "SPI/SI Representation sub-TLV" with | ||||
bit 0 set and bit 1 cleared. | ||||
In this case the MPLS label stack constructed by the SFF to forward a | ||||
packet to the next SFF on the SFP will consist of the labels needed | ||||
to reach that SFF, and if label stacking is used it will also include | ||||
the labels advertised in the MPLS Label Stack sub-TLV and the labels | ||||
remaining in the stack needed to traverse the remainder of the SFP. | ||||
8. Examples | 8. Examples | |||
Assume we have a service function overlay network with four SFFs | Assume we have a service function overlay network with four SFFs | |||
(SFF1, SFF3, SFF3, and SFF4). The SFFs have addresses in the | (SFF1, SFF3, SFF3, and SFF4). The SFFs have addresses in the | |||
underlay network as follows: | underlay network as follows: | |||
SFF1 192.0.2.1 | SFF1 192.0.2.1 | |||
SFF2 192.0.2.2 | SFF2 192.0.2.2 | |||
SFF3 192.0.2.3 | SFF3 192.0.2.3 | |||
SFF4 192.0.2.4 | SFF4 192.0.2.4 | |||
skipping to change at page 51, line 37 ¶ | skipping to change at page 52, line 37 ¶ | |||
Email: keyur@arrcus.com | Email: keyur@arrcus.com | |||
Avinash Lingala | Avinash Lingala | |||
AT&T | AT&T | |||
Email: ar977m@att.com | Email: ar977m@att.com | |||
12. Acknowledgements | 12. Acknowledgements | |||
Thanks to Tony Przygienda for helpful comments, and to Joel Halpern | Thanks to Tony Przygienda, Jeff Haas, and Andy Malis for helpful | |||
for discussions that improved this document. Yuanlong Jiang provided | comments, and to Joel Halpern for discussions that improved this | |||
a useful review and caught some important issues. | document. Yuanlong Jiang provided a useful review and caught some | |||
important issues. | ||||
Andy Malis contributed text that formed the basis of Section 7.8. | ||||
13. References | 13. References | |||
13.1. Normative References | 13.1. Normative References | |||
[I-D.ietf-idr-tunnel-encaps] | [I-D.ietf-idr-tunnel-encaps] | |||
Rosen, E., Patel, K., and G. Velde, "The BGP Tunnel | Rosen, E., Patel, K., and G. Velde, "The BGP Tunnel | |||
Encapsulation Attribute", draft-ietf-idr-tunnel-encaps-10 | Encapsulation Attribute", draft-ietf-idr-tunnel-encaps-11 | |||
(work in progress), August 2018. | (work in progress), February 2019. | |||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
Requirement Levels", BCP 14, RFC 2119, | Requirement Levels", BCP 14, RFC 2119, | |||
DOI 10.17487/RFC2119, March 1997, | DOI 10.17487/RFC2119, March 1997, | |||
<https://www.rfc-editor.org/info/rfc2119>. | <https://www.rfc-editor.org/info/rfc2119>. | |||
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A | [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A | |||
Border Gateway Protocol 4 (BGP-4)", RFC 4271, | Border Gateway Protocol 4 (BGP-4)", RFC 4271, | |||
DOI 10.17487/RFC4271, January 2006, | DOI 10.17487/RFC4271, January 2006, | |||
<https://www.rfc-editor.org/info/rfc4271>. | <https://www.rfc-editor.org/info/rfc4271>. | |||
skipping to change at page 52, line 48 ¶ | skipping to change at page 54, line 8 ¶ | |||
[RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., | [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., | |||
"Network Service Header (NSH)", RFC 8300, | "Network Service Header (NSH)", RFC 8300, | |||
DOI 10.17487/RFC8300, January 2018, | DOI 10.17487/RFC8300, January 2018, | |||
<https://www.rfc-editor.org/info/rfc8300>. | <https://www.rfc-editor.org/info/rfc8300>. | |||
13.2. Informative References | 13.2. Informative References | |||
[I-D.ietf-mpls-sfc] | [I-D.ietf-mpls-sfc] | |||
Farrel, A., Bryant, S., and J. Drake, "An MPLS-Based | Farrel, A., Bryant, S., and J. Drake, "An MPLS-Based | |||
Forwarding Plane for Service Function Chaining", draft- | Forwarding Plane for Service Function Chaining", draft- | |||
ietf-mpls-sfc-04 (work in progress), November 2018. | ietf-mpls-sfc-05 (work in progress), February 2019. | |||
[I-D.ietf-mpls-sfc-encapsulation] | ||||
Malis, A., Bryant, S., Halpern, J., and W. Henderickx, | ||||
"MPLS Encapsulation For The SFC NSH", draft-ietf-mpls-sfc- | ||||
encapsulation-02 (work in progress), December 2018. | ||||
[RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and | [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and | |||
L. Yong, "The Use of Entropy Labels in MPLS Forwarding", | L. Yong, "The Use of Entropy Labels in MPLS Forwarding", | |||
RFC 6790, DOI 10.17487/RFC6790, November 2012, | RFC 6790, DOI 10.17487/RFC6790, November 2012, | |||
<https://www.rfc-editor.org/info/rfc6790>. | <https://www.rfc-editor.org/info/rfc6790>. | |||
[RFC7498] Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for | [RFC7498] Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for | |||
Service Function Chaining", RFC 7498, | Service Function Chaining", RFC 7498, | |||
DOI 10.17487/RFC7498, April 2015, | DOI 10.17487/RFC7498, April 2015, | |||
<https://www.rfc-editor.org/info/rfc7498>. | <https://www.rfc-editor.org/info/rfc7498>. | |||
End of changes. 21 change blocks. | ||||
44 lines changed or deleted | 74 lines changed or added | |||
This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |