draft-ietf-bess-nsh-bgp-control-plane-11.txt   draft-ietf-bess-nsh-bgp-control-plane-12.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: December 1, 2019 E. Rosen Expires: February 21, 2020 E. Rosen
Juniper Networks Juniper Networks
J. Uttaro J. Uttaro
AT&T AT&T
L. Jalil L. Jalil
Verizon Verizon
May 30, 2019 August 20, 2019
BGP Control Plane for NSH SFC BGP Control Plane for NSH SFC
draft-ietf-bess-nsh-bgp-control-plane-11 draft-ietf-bess-nsh-bgp-control-plane-12
Abstract Abstract
This document describes the use of BGP as a control plane for This document describes the use of BGP as a control plane for
networks that support Service Function Chaining (SFC). The document networks that support Service Function Chaining (SFC). The document
introduces a new BGP address family called the SFC AFI/SAFI with two introduces a new BGP address family called the SFC AFI/SAFI with two
route types. One route type is originated by a node to advertise route types. One route type is originated by a node to advertise
that it hosts a particular instance of a specified service function. that it hosts a particular instance of a specified service function.
This route type also provides "instructions" on how to send a packet This route type also provides "instructions" on how to send a packet
to the hosting node in a way that indicates that the service function to the hosting node in a way that indicates that the service function
skipping to change at page 1, line 49 skipping to change at page 1, line 49
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 1, 2019. This Internet-Draft will expire on February 21, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 42 skipping to change at page 2, line 42
3.2. Service Function Path Route (SFPR) . . . . . . . . . . . 14 3.2. Service Function Path Route (SFPR) . . . . . . . . . . . 14
3.2.1. The SFP Attribute . . . . . . . . . . . . . . . . . . 15 3.2.1. The SFP Attribute . . . . . . . . . . . . . . . . . . 15
3.2.2. General Rules For The SFP Attribute . . . . . . . . . 21 3.2.2. General Rules For The SFP Attribute . . . . . . . . . 21
4. Mode of Operation . . . . . . . . . . . . . . . . . . . . . . 22 4. Mode of Operation . . . . . . . . . . . . . . . . . . . . . . 22
4.1. Route Targets . . . . . . . . . . . . . . . . . . . . . . 22 4.1. Route Targets . . . . . . . . . . . . . . . . . . . . . . 22
4.2. Service Function Instance Routes . . . . . . . . . . . . 22 4.2. Service Function Instance Routes . . . . . . . . . . . . 22
4.3. Service Function Path Routes . . . . . . . . . . . . . . 22 4.3. Service Function Path Routes . . . . . . . . . . . . . . 22
4.4. Classifier Operation . . . . . . . . . . . . . . . . . . 24 4.4. Classifier Operation . . . . . . . . . . . . . . . . . . 24
4.5. Service Function Forwarder Operation . . . . . . . . . . 25 4.5. Service Function Forwarder Operation . . . . . . . . . . 25
4.5.1. Processing With 'Gaps' in the SI Sequence . . . . . . 26 4.5.1. Processing With 'Gaps' in the SI Sequence . . . . . . 26
5. Selection in Service Function Paths . . . . . . . . . . . . . 27 5. Selection within Service Function Paths . . . . . . . . . . . 27
6. Looping, Jumping, and Branching . . . . . . . . . . . . . . . 29 6. Looping, Jumping, and Branching . . . . . . . . . . . . . . . 29
6.1. Protocol Control of Looping, Jumping, and Branching . . . 29 6.1. Protocol Control of Looping, Jumping, and Branching . . . 29
6.2. Implications for Forwarding State . . . . . . . . . . . . 30 6.2. Implications for Forwarding State . . . . . . . . . . . . 30
7. Advanced Topics . . . . . . . . . . . . . . . . . . . . . . . 30 7. Advanced Topics . . . . . . . . . . . . . . . . . . . . . . . 31
7.1. Correlating Service Function Path Instances . . . . . . . 30 7.1. Correlating Service Function Path Instances . . . . . . . 31
7.2. Considerations for Stateful Service Functions . . . . . . 31 7.2. Considerations for Stateful Service Functions . . . . . . 32
7.3. VPN Considerations and Private Service Functions . . . . 32 7.3. VPN Considerations and Private Service Functions . . . . 33
7.4. Flow Spec for SFC Classifiers . . . . . . . . . . . . . . 33 7.4. Flow Spec for SFC Classifiers . . . . . . . . . . . . . . 33
7.5. Choice of Data Plane SPI/SI Representation . . . . . . . 34 7.5. Choice of Data Plane SPI/SI Representation . . . . . . . 34
7.5.1. MPLS Representation of the SPI/SI . . . . . . . . . . 35 7.5.1. MPLS Representation of the SPI/SI . . . . . . . . . . 36
7.6. MPLS Label Swapping/Stacking Operation . . . . . . . . . 35 7.6. MPLS Label Swapping/Stacking Operation . . . . . . . . . 36
7.7. Support for MPLS-Encapsulated NSH Packets . . . . . . . . 36 7.7. Support for MPLS-Encapsulated NSH Packets . . . . . . . . 36
8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 36 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 37
8.1. Example Explicit SFP With No Choices . . . . . . . . . . 38 8.1. Example Explicit SFP With No Choices . . . . . . . . . . 38
8.2. Example SFP With Choice of SFIs . . . . . . . . . . . . . 38 8.2. Example SFP With Choice of SFIs . . . . . . . . . . . . . 39
8.3. Example SFP With Open Choice of SFIs . . . . . . . . . . 39 8.3. Example SFP With Open Choice of SFIs . . . . . . . . . . 40
8.4. Example SFP With Choice of SFTs . . . . . . . . . . . . . 39 8.4. Example SFP With Choice of SFTs . . . . . . . . . . . . . 40
8.5. Example Correlated Bidirectional SFPs . . . . . . . . . . 40 8.5. Example Correlated Bidirectional SFPs . . . . . . . . . . 41
8.6. Example Correlated Asymmetrical Bidirectional SFPs . . . 41 8.6. Example Correlated Asymmetrical Bidirectional SFPs . . . 41
8.7. Example Looping in an SFP . . . . . . . . . . . . . . . . 41 8.7. Example Looping in an SFP . . . . . . . . . . . . . . . . 42
8.8. Example Branching in an SFP . . . . . . . . . . . . . . . 42 8.8. Example Branching in an SFP . . . . . . . . . . . . . . . 43
8.9. Examples of SFPs with Stateful Service Functions . . . . 43 8.9. Examples of SFPs with Stateful Service Functions . . . . 43
8.9.1. Forward and Reverse Choice Made at the SFF . . . . . 43 8.9.1. Forward and Reverse Choice Made at the SFF . . . . . 44
8.9.2. Parallel End-to-End SFPs with Shared SFF . . . . . . 44 8.9.2. Parallel End-to-End SFPs with Shared SFF . . . . . . 45
8.9.3. Parallel End-to-End SFPs with Separate SFFs . . . . . 46 8.9.3. Parallel End-to-End SFPs with Separate SFFs . . . . . 47
8.9.4. Parallel SFPs Downstream of the Choice . . . . . . . 48 8.9.4. Parallel SFPs Downstream of the Choice . . . . . . . 49
9. Security Considerations . . . . . . . . . . . . . . . . . . . 51 9. Security Considerations . . . . . . . . . . . . . . . . . . . 52
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 52 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 53
10.1. New BGP AF/SAFI . . . . . . . . . . . . . . . . . . . . 52 10.1. New BGP AF/SAFI . . . . . . . . . . . . . . . . . . . . 53
10.2. New BGP Path Attribute . . . . . . . . . . . . . . . . . 52 10.2. New BGP Path Attribute . . . . . . . . . . . . . . . . . 53
10.3. New SFP Attribute TLVs Type Registry . . . . . . . . . . 52 10.3. New SFP Attribute TLVs Type Registry . . . . . . . . . . 53
10.4. New SFP Association Type Registry . . . . . . . . . . . 53 10.4. New SFP Association Type Registry . . . . . . . . . . . 54
10.5. New Service Function Type Registry . . . . . . . . . . . 54 10.5. New Service Function Type Registry . . . . . . . . . . . 55
10.6. New Generic Transitive Experimental Use Extended 10.6. New Generic Transitive Experimental Use Extended
Community Sub-Types . . . . . . . . . . . . . . . . . . 55 Community Sub-Types . . . . . . . . . . . . . . . . . . 56
10.7. New BGP Transitive Extended Community Types . . . . . . 55 10.7. New BGP Transitive Extended Community Types . . . . . . 56
10.8. SPI/SI Representation . . . . . . . . . . . . . . . . . 55 10.8. SPI/SI Representation . . . . . . . . . . . . . . . . . 56
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 55 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 56
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 56 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 57
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 56 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 57
13.1. Normative References . . . . . . . . . . . . . . . . . . 56 13.1. Normative References . . . . . . . . . . . . . . . . . . 57
13.2. Informative References . . . . . . . . . . . . . . . . . 57 13.2. Informative References . . . . . . . . . . . . . . . . . 58
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 58 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 59
1. Introduction 1. Introduction
As described in [RFC7498], the delivery of end-to-end services can As described in [RFC7498], the delivery of end-to-end services can
require a packet to pass through a series of Service Functions (SFs) require a packet to pass through a series of Service Functions (SFs)
(e.g., WAN and application accelerators, Deep Packet Inspection (DPI) (e.g., WAN and application accelerators, Deep Packet Inspection (DPI)
engines, firewalls, TCP optimizers, and server load balancers) in a engines, firewalls, TCP optimizers, and server load balancers) in a
specified order: this is termed "Service Function Chaining" (SFC). specified order: this is termed "Service Function Chaining" (SFC).
There are a number of issues associated with deploying and There are a number of issues associated with deploying and
maintaining service function chaining in production networks, which maintaining service function chaining in production networks, which
skipping to change at page 14, line 11 skipping to change at page 14, line 11
network byte order, and is a globally unique value. This means that network byte order, and is a globally unique value. This means that
pool identifiers need to be centrally managed, which is consistent pool identifiers need to be centrally managed, which is consistent
with the assignment of SFIs to pools. with the assignment of SFIs to pools.
3.1.2. MPLS Mixed Swapping/Stacking Extended Community 3.1.2. MPLS Mixed Swapping/Stacking Extended Community
This document defines a new transitive extended community of type This document defines a new transitive extended community of type
TBD7 with Sub-Type 0x00 called the MPLS Mixed Swapping/Stacking TBD7 with Sub-Type 0x00 called the MPLS Mixed Swapping/Stacking
Labels. The community is encoded as shown in Figure 5. It contains Labels. The community is encoded as shown in Figure 5. It contains
a pair of MPLS labels: an SFC Context Label and an SF Label as a pair of MPLS labels: an SFC Context Label and an SF Label as
described in [I-D.ietf-mpls-sfc]. Each label is 20 bits encoded in a described in [RFC8595]. Each label is 20 bits encoded in a 3-octet
3-octet (24 bit) field with 4 trailing bits that MUST be set to zero. (24 bit) field with 4 trailing bits that MUST be set to zero.
+--------------------------------------------+ +--------------------------------------------+
| Type = TBD7 (1 octet) | | Type = TBD7 (1 octet) |
+--------------------------------------------| +--------------------------------------------|
| Sub-Type = 0x00 (1 octet) | | Sub-Type = 0x00 (1 octet) |
+--------------------------------------------| +--------------------------------------------|
| SFC Context Label (3 octets) | | SFC Context Label (3 octets) |
+--------------------------------------------| +--------------------------------------------|
| SF Label (3 octets) | | SF Label (3 octets) |
+--------------------------------------------+ +--------------------------------------------+
skipping to change at page 17, line 23 skipping to change at page 17, line 23
3.: Unknown TLVs SHOULD be ignored, and message processing SHOULD 3.: Unknown TLVs SHOULD be ignored, and message processing SHOULD
continue. continue.
4.: Treated as a malformed message and the "treat-as-withdraw" 4.: Treated as a malformed message and the "treat-as-withdraw"
approach used as per [RFC7606] approach used as per [RFC7606]
5., 8.: The absence of an RD with which to correlate is nothing 5., 8.: The absence of an RD with which to correlate is nothing
more than a soft error. The receiver SHOULD store the more than a soft error. The receiver SHOULD store the
information from the SFP attribute until a corresponding information from the SFP attribute until a corresponding
advertisement is received. An implementation MAY time-out such advertisement is received.
stored SFP attributes to avoid becoming over-loaded. The time-
out value should be configurable and measured in minutes; a
default value of 30 minutes is suggested. Whenever an
implementation removes a stored SFP attribute, it SHOULD
generate a notification to the network operator.
3.2.1.1. The Association TLV 3.2.1.1. The Association TLV
The Association TLV is an optional TLV in the SFP attribute. It MAY The Association TLV is an optional TLV in the SFP attribute. It MAY
be present multiple times. Each occurrence provides an association be present multiple times. Each occurrence provides an association
with another SFP as advertised in another SFPR. The format of the with another SFP as advertised in another SFPR. The format of the
Association TLV is shown in Figure 7 Association TLV is shown in Figure 7
+--------------------------------------------+ +--------------------------------------------+
| Type = 1 (1 octet) | | Type = 1 (1 octet) |
skipping to change at page 27, line 14 skipping to change at page 27, line 14
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 [RFC8300]. 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 [RFC8300]. described in [RFC8300].
5. Selection in Service Function Paths 5. Selection within Service Function Paths
As described in Section 2 the SPI/SI in the NSH passed back from an As described in Section 2 the SPI/SI in the NSH passed back from an
SFI to the SFF may leave the SFF with a choice of next hop SFTs, and SFI to the SFF may leave the SFF with a choice of next hop SFTs, and
a choice of SFIs for each SFT. That is, the SPI indicates an SFPR, a choice of SFIs for each SFT. That is, the SPI indicates an SFPR,
and the SI indicates an entry in that SFPR. Each entry in an SFPR is and the SI indicates an entry in that SFPR. Each entry in an SFPR is
a set of one or more SFT/SFIR-RD pairs. The SFF MUST choose one of a set of one or more SFT/SFIR-RD pairs. The SFF MUST choose one of
these, identify the SFF that supports the chosen SFI, and send the these, identify the SFF that supports the chosen SFI, and send the
packet to that next hop SFF. packet to that next hop SFF.
The choice be may offered for load balancing across multiple SFIs, or The choice be may offered for load balancing across multiple SFIs, or
skipping to change at page 29, line 5 skipping to change at page 28, line 51
Each of the relevant SFIRs identifies a single SFI, and contains a Each of the relevant SFIRs identifies a single SFI, and contains a
Tunnel Encapsulation attribute that specifies how to send a packet to Tunnel Encapsulation attribute that specifies how to send a packet to
that SFI. For a particular packet, the SFF chooses a particular SFI that SFI. For a particular packet, the SFF chooses a particular SFI
from the set of relevant SFIRs. This choice is made according to from the set of relevant SFIRs. This choice is made according to
local policy. local policy.
A typical policy might be to figure out the set of SFIs that are A typical policy might be to figure out the set of SFIs that are
closest, and to load balance among them. But this is not the only closest, and to load balance among them. But this is not the only
possible policy. possible policy.
Thus, at any point in time when an SFF selects its next hop, it
chooses from the intersection of the set of next hop RDs contained in
the SFPR and the RDs contained in its local set of SFIRs. If the
intersection is null, the SFPR is unusable. Similarly, when this
condition obtains the originator of the SFPR should either withdraw
the SFPR or re-advertise it with a new set of RDs for the affected
hop.
6. Looping, Jumping, and Branching 6. Looping, Jumping, and Branching
As described in Section 2 an SFI or an SFF may cause a packet to As described in Section 2 an SFI or an SFF may cause a packet to
"loop back" to a previous SF on a path in order that a sequence of "loop back" to a previous SF on a path in order that a sequence of
functions may be re-executed. This is simply achieved by replacing functions may be re-executed. This is simply achieved by replacing
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
skipping to change at page 34, line 36 skipping to change at page 34, line 50
target of the overlay or VPN network for which it is intended. target of the overlay or VPN network for which it is intended.
7.5. Choice of Data Plane SPI/SI Representation 7.5. Choice of Data Plane SPI/SI Representation
This document ties together the control and data planes of an SFC This document ties together the control and data planes of an SFC
overlay network through the use of the SPI/SI which is nominally overlay network through the use of the SPI/SI which is nominally
carried in the NSH of a given packet. However, in order to handle carried in the NSH of a given packet. However, in order to handle
situations in which the NSH is not ubiquitously deployed, it is also situations in which the NSH is not ubiquitously deployed, it is also
possible to use alternative data plane representations of the SPI/SI possible to use alternative data plane representations of the SPI/SI
by carrying the identical semantics in other protocol fields such as by carrying the identical semantics in other protocol fields such as
MPLS labels [I-D.ietf-mpls-sfc]. MPLS labels [RFC8595].
This document defines a new sub-TLV for the Tunnel Encapsulation This document defines a new sub-TLV for the Tunnel Encapsulation
attribute, the SPI/SI Representation sub-TLV of type TBD5. This sub- attribute, the SPI/SI Representation sub-TLV of type TBD5. This sub-
TLV MAY be present in each Tunnel TLV contained in a Tunnel TLV MAY be present in each Tunnel TLV contained in a Tunnel
Encapsulation attribute when the attribute is carried by an SFIR. Encapsulation attribute when the attribute is carried by an SFIR.
The value field of this sub-TLV is a two octet field of flags, each The value field of this sub-TLV is a two octet field of flags, each
of which describes how the originating SFF expects to see the SPI/SI of which describes how the originating SFF expects to see the SPI/SI
represented in the data plane for packets carried in the tunnels represented in the data plane for packets carried in the tunnels
described by the Tunnel TLV. described by the Tunnel TLV.
skipping to change at page 35, line 40 skipping to change at page 36, line 10
NSH itself). It is a requirement that both ends of a tunnel over the NSH itself). It is a requirement that both ends of a tunnel over the
underlay network know that the tunnel is used for SFC and know what underlay network know that the tunnel is used for SFC and know what
form of NSH representation is used. The signaling mechanism form of NSH representation is used. The signaling mechanism
described here allows coordination of this information. described here allows coordination of this information.
7.5.1. MPLS Representation of the SPI/SI 7.5.1. MPLS Representation of the SPI/SI
If bit 1 is set in the in the SPI/SI Representation sub-TLV then If bit 1 is set in the in the SPI/SI Representation sub-TLV then
labels in the MPLS label stack are used to indicate SFC forwarding labels in the MPLS label stack are used to indicate SFC forwarding
and processing instructions to achieve the semantics of a logical and processing instructions to achieve the semantics of a logical
NSH. The label stack is encoded as shown in [I-D.ietf-mpls-sfc]. NSH. The label stack is encoded as shown in [RFC8595].
7.6. MPLS Label Swapping/Stacking Operation 7.6. MPLS Label Swapping/Stacking Operation
When a classifier constructs an MPLS label stack for an SFP it starts When a classifier constructs an MPLS label stack for an SFP it starts
with that SFP' last hop. If the last hop requires an {SPI, SI} label with that SFP' last hop. If the last hop requires an {SPI, SI} label
pair for label swapping, it pushes the SI (set to the SI value of the pair for label swapping, it pushes the SI (set to the SI value of the
last hop) and the SFP's SPI onto the MPLS label stack. If the last last hop) and the SFP's SPI onto the MPLS label stack. If the last
hop requires a {context label, SFI label} label pair for label hop requires a {context label, SFI label} label pair for label
stacking it selects a specific SFIR and pushes that SFIR's SFI label stacking it selects a specific SFIR and pushes that SFIR's SFI label
and context label onto the MPLS label stack. and context label onto the MPLS label stack.
skipping to change at page 36, line 18 skipping to change at page 36, line 35
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.7. Support for MPLS-Encapsulated NSH Packets 7.7. Support for MPLS-Encapsulated NSH Packets
[I-D.ietf-mpls-sfc-encapsulation] describes how to transport SFC [RFC8596] describes how to transport SFC packets using the NSH over
packets using the NSH over an MPLS transport network. Signaling MPLS an MPLS transport network. Signaling MPLS encapsulation of SFC
encapsulation of SFC packets using the NSH is also supported by this packets using the NSH is also supported by this document by using the
document by using the "BGP Tunnel Encapsulation Attribute Sub-TLV" "BGP Tunnel Encapsulation Attribute Sub-TLV" with the codepoint 10
with the codepoint 10 (representing "MPLS Label Stack") from the "BGP (representing "MPLS Label Stack") from the "BGP Tunnel Encapsulation
Tunnel Encapsulation Attribute Sub-TLVs" registry defined in Attribute Sub-TLVs" registry defined in [I-D.ietf-idr-tunnel-encaps],
[I-D.ietf-idr-tunnel-encaps], and also using the "SFP Traversal With and also using the "SFP Traversal With MPLS Label Stack TLV" and the
MPLS Label Stack TLV" and the "SPI/SI Representation sub-TLV" with "SPI/SI Representation sub-TLV" with bit 0 set and bit 1 cleared.
bit 0 set and bit 1 cleared.
In this case the MPLS label stack constructed by the SFF to forward a In this case the MPLS label stack constructed by the SFF to forward a
packet to the next SFF on the SFP will consist of the labels needed packet to the next SFF on the SFP will consist of the labels needed
to reach that SFF, and if label stacking is used it will also include to reach that SFF, and if label stacking is used it will also include
the labels advertised in the MPLS Label Stack sub-TLV and the labels the labels advertised in the MPLS Label Stack sub-TLV and the labels
remaining in the stack needed to traverse the remainder of the SFP. remaining in the stack needed to traverse the remainder of the SFP.
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
skipping to change at page 56, line 22 skipping to change at page 57, line 22
Andy Malis contributed text that formed the basis of Section 7.7. Andy Malis contributed text that formed the basis of Section 7.7.
13. References 13. References
13.1. Normative References 13.1. Normative References
[I-D.ietf-idr-rfc5575bis] [I-D.ietf-idr-rfc5575bis]
Loibl, C., Hares, S., Raszuk, R., McPherson, D., and M. Loibl, C., Hares, S., Raszuk, R., McPherson, D., and M.
Bacher, "Dissemination of Flow Specification Rules", Bacher, "Dissemination of Flow Specification Rules",
draft-ietf-idr-rfc5575bis-15 (work in progress), May 2019. draft-ietf-idr-rfc5575bis-17 (work in progress), June
2019.
[I-D.ietf-idr-tunnel-encaps] [I-D.ietf-idr-tunnel-encaps]
Patel, K., Velde, G., Ramachandra, S., and E. Rosen, "The Patel, K., Velde, G., Ramachandra, S., and E. Rosen, "The
BGP Tunnel Encapsulation Attribute", draft-ietf-idr- BGP Tunnel Encapsulation Attribute", draft-ietf-idr-
tunnel-encaps-12 (work in progress), May 2019. tunnel-encaps-13 (work in progress), July 2019.
[I-D.ietf-mpls-sfc]
Farrel, A., Bryant, S., and J. Drake, "An MPLS-Based
Forwarding Plane for Service Function Chaining", draft-
ietf-mpls-sfc-07 (work in progress), March 2019.
[I-D.ietf-mpls-sfc-encapsulation]
Malis, A., Bryant, S., Halpern, J., and W. Henderickx,
"MPLS Transport Encapsulation For The SFC NSH", draft-
ietf-mpls-sfc-encapsulation-04 (work in progress), March
2019.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Border Gateway Protocol 4 (BGP-4)", RFC 4271, Border Gateway Protocol 4 (BGP-4)", RFC 4271,
DOI 10.17487/RFC4271, January 2006, DOI 10.17487/RFC4271, January 2006,
<https://www.rfc-editor.org/info/rfc4271>. <https://www.rfc-editor.org/info/rfc4271>.
skipping to change at page 57, line 44 skipping to change at page 58, line 34
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed.,
"Network Service Header (NSH)", RFC 8300, "Network Service Header (NSH)", RFC 8300,
DOI 10.17487/RFC8300, January 2018, DOI 10.17487/RFC8300, January 2018,
<https://www.rfc-editor.org/info/rfc8300>. <https://www.rfc-editor.org/info/rfc8300>.
[RFC8595] Farrel, A., Bryant, S., and J. Drake, "An MPLS-Based
Forwarding Plane for Service Function Chaining", RFC 8595,
DOI 10.17487/RFC8595, June 2019,
<https://www.rfc-editor.org/info/rfc8595>.
[RFC8596] Malis, A., Bryant, S., Halpern, J., and W. Henderickx,
"MPLS Transport Encapsulation for the Service Function
Chaining (SFC) Network Service Header (NSH)", RFC 8596,
DOI 10.17487/RFC8596, June 2019,
<https://www.rfc-editor.org/info/rfc8596>.
13.2. Informative References 13.2. Informative References
[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>.
Authors' Addresses Authors' Addresses
Adrian Farrel Adrian Farrel
 End of changes. 23 change blocks. 
71 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/