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/