--- 1/draft-ietf-mpls-sfc-05.txt 2019-03-07 09:14:02.138431781 -0800 +++ 2/draft-ietf-mpls-sfc-06.txt 2019-03-07 09:14:02.198433246 -0800 @@ -1,109 +1,93 @@ MPLS Working Group A. Farrel Internet-Draft Old Dog Consulting Intended status: Standards Track S. Bryant -Expires: August 16, 2019 Huawei +Expires: September 8, 2019 Huawei J. Drake Juniper Networks - February 12, 2019 + March 7, 2019 An MPLS-Based Forwarding Plane for Service Function Chaining - draft-ietf-mpls-sfc-05 + draft-ietf-mpls-sfc-06 Abstract - Service Function Chaining (SFC) is the process of directing packets - through a network so that they can be acted on by an ordered set of - abstract service functions before being delivered to the intended - destination. An architecture for SFC is defined in RFC7665. - - The Network Service Header (NSH) can be inserted into packets to - steer them along a specific path to realize a Service Function Chain. - - Multiprotocol Label Switching (MPLS) is a widely deployed forwarding - technology that uses labels placed in a packet in a label stack to - identify the forwarding actions to be taken at each hop through a - network. Actions may include swapping or popping the labels as well, - as using the labels to determine the next hop for forwarding the - packet. Labels may also be used to establish the context under which - the packet is forwarded. - - This document describes how Service Function Chaining can be achieved - in an MPLS network by means of a logical representation of the NSH in - an MPLS label stack. That is, the NSH is not used, but the fields of - the NSH are mapped to fields in the MPLS label stack. It does not - deprecate or replace the NSH, but acknowledges that there may be a - need for an interim deployment of SFC functionality in brownfield - networks. + This document describes how Service Function Chaining (SFC) can be + achieved in an MPLS network by means of a logical representation of + the Network Service Header (NSH) in an MPLS label stack. That is, + the NSH is not used, but the fields of the NSH are mapped to fields + in the MPLS label stack. It does not deprecate or replace the NSH, + but acknowledges that there may be a need for an interim deployment + of SFC functionality in brownfield networks. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on August 16, 2019. + This Internet-Draft will expire on September 8, 2019. Copyright Notice Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 3. Choice of Data Plane SPI/SI Representation . . . . . . . . . 4 - 4. Use Case Scenarios . . . . . . . . . . . . . . . . . . . . . 5 + 4. Use Case Scenarios . . . . . . . . . . . . . . . . . . . . . 4 4.1. Label Swapping for Logical NSH . . . . . . . . . . . . . 5 4.2. Hierarchical Encapsulation . . . . . . . . . . . . . . . 5 - 4.3. Fine Control of Service Function Instances . . . . . . . 6 - 4.4. Micro Chains and Label Stacking . . . . . . . . . . . . . 6 + 4.3. Fine Control of Service Function Instances . . . . . . . 5 + 4.4. Micro Chains and Label Stacking . . . . . . . . . . . . . 5 4.5. SFC and Segment Routing . . . . . . . . . . . . . . . . . 6 5. Basic Unit of Representation . . . . . . . . . . . . . . . . 6 - 6. MPLS Label Swapping . . . . . . . . . . . . . . . . . . . . . 8 + 6. MPLS Label Swapping . . . . . . . . . . . . . . . . . . . . . 7 7. MPLS Label Stacking . . . . . . . . . . . . . . . . . . . . . 10 - 8. Mixed Mode Forwarding . . . . . . . . . . . . . . . . . . . . 12 + 8. Mixed Mode Forwarding . . . . . . . . . . . . . . . . . . . . 11 9. A Note on Service Function Capabilities and SFC Proxies . . . 13 10. Control Plane Considerations . . . . . . . . . . . . . . . . 13 11. Use of the Entropy Label . . . . . . . . . . . . . . . . . . 14 - 12. Metadata . . . . . . . . . . . . . . . . . . . . . . . . . . 15 + 12. Metadata . . . . . . . . . . . . . . . . . . . . . . . . . . 14 12.1. Indicating Metadata in User Data Packets . . . . . . . . 15 12.2. Inband Programming of Metadata . . . . . . . . . . . . . 17 13. Worked Examples . . . . . . . . . . . . . . . . . . . . . . . 20 14. Implementation Notes . . . . . . . . . . . . . . . . . . . . 24 15. Security Considerations . . . . . . . . . . . . . . . . . . . 25 - 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 - 17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 + 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 + 17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27 18. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 27 - 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 - 19.1. Normative References . . . . . . . . . . . . . . . . . . 27 + 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 + 19.1. Normative References . . . . . . . . . . . . . . . . . . 28 19.2. Informative References . . . . . . . . . . . . . . . . . 28 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 1. Introduction Service Function Chaining (SFC) is the process of directing packets through a network so that they can be acted on by an ordered set of abstract service functions before being delivered to the intended destination. An architecture for SFC is defined in [RFC7665]. @@ -140,26 +125,28 @@ This document describes how Service Function Chaining can be achieved in an MPLS network by means of a logical representation of the NSH in an MPLS label stack. This approach is applicable to all forms of MPLS forwarding (where labels are looked up at each hop, and swapped or popped [RFC3031]). It does not deprecate or replace the NSH, but acknowledges that there may be a need for an interim deployment of SFC functionality in brownfield networks. The mechanisms described in this document are a compromise between the full function that can be achieved using the NSH, and the benefits of reusing the existing - MPLS forwarding paradigms. + MPLS forwarding paradigms (the approach defined here does not include + the O-bit defined in [RFC8300] and has some limitations to the use of + metadata as described in Section 12. Section 4 provides a short overview of several use case scenarios that help to explain the relationship between the MPLS label operations (swapping, popping, stacking) and the MPLS encoding of the - logical NSH described in this document). + logical NSH described in this document. It is assumed that the reader is fully familiar with the terms and concepts introduced in [RFC7665] and [RFC8300]. Note that one of the features of the SFC architecture described in [RFC7665] is the "SFC proxy" that exists to include legacy SFs that are not able to process NSH-encapsulated packets. This issue is equally applicable to the use of MPLS-encapsulated packets that encode a logical representation of an NSH. It is discussed further in Section 9. @@ -230,21 +217,21 @@ encoding of the logical NSH, and label stacking as defined in [RFC3031] and described in Section 7. In this model, swapping is used per Section 4.1 to navigate one chain, and when the end of the chain is reached, the final label is popped revealing the label for another chain. Thus, the primary mode is swapping, but stacking is used to enable the ingress classifier to control concatenation of service function chains. 4.3. Fine Control of Service Function Instances - It may be that a service function chain (as described in Section 4.1 + It may be that a service function chain (as described in Section 4.1) allows some leeway in the choice of service function instances along the chain. However, it may be that a service classifier wishes to constrain the choice and this can be achieved using chain concatenation so that the first chain ends at the point of choice, the next label in the stack indicates the specific service function instance to be executed, and the next label in the stack starts a new chain. Thus, a mixture of label swapping and stacking is used. 4.4. Micro Chains and Label Stacking @@ -260,28 +247,24 @@ as described Section 4.5, and the discussion in that section applies to this section as well. 4.5. SFC and Segment Routing Segment Routing (SR) in an MPLS network (known as MPLS-SR) uses a stack of MPLS labels to encode information about the path and network functions that a packet should traverse. MPLS-SR is achieved by applying control plane and management plane techniques to program the MPLS forwarding plane, and by imposing labels on packets at the - entrance to the MPLS-SR network. - - The application of SR to SFC was considered in early versions of the - SR architecture [RFC8402] and the MPLS-SR specification - [I-D.ietf-spring-segment-routing-mpls], but has since been moved out - of those documents. An implementation proposal for achieving SFC - using MPLS-SR can be found in [I-D.xuclad-spring-sr-service-chaining] - and is not discussed further in this document. + entrance to the MPLS-SR network. An implementation proposal for + achieving SFC using MPLS-SR can be found in + [I-D.xuclad-spring-sr-service-programming] and is not discussed + further in this document. 5. Basic Unit of Representation When an MPLS label stack is used to carry a logical NSH, a basic unit of representation is used. This unit comprises two MPLS labels as shown below. The unit may be present one or more times in the label stack as explained in subsequent sections. In order to convey the same information as is present in the NSH, two MPLS label stack entries are used. One carries a label to provide @@ -300,28 +283,28 @@ Figure 1: The Basic Unit of MPLS Label Stack for SFC The fields of these two label stack entries are encoded as follows: Label: The Label fields contain the values of the SFC Context Label and the SF Label encoded as 20 bit integers. The precise semantics of these label fields are dependent on whether the label stack entries are used for MPLS label swapping (see Section 6) or MPLS label stacking (see Section 7). - TC: The TC bits have no meaning. They SHOULD be set to zero in both - label stack entries when a packet is sent and MUST be ignored on - receipt. + TC: The TC bits have no meaning in this case. They SHOULD be set to + zero in both label stack entries when a packet is sent and MUST be + ignored on receipt. S: The bottom of stack bit has its usual meaning in MPLS. It MUST be - clear in the SFC Context label stack entry and MAY be set in the - SF label stack entry depending on whether the label is the bottom - of stack. + clear in the SFC Context label stack entry. In the SF label stack + entry it MUST be clear in all cases except when the label is the + bottom of stack, when it MUST be set. TTL: The TTL field in the SFC Context label stack entry SHOULD be set to 1. The TTL in SF label stack entry (called the SF TTL) is set according to its use for MPLS label swapping (see Section 6) or MPLS label stacking (see Section 7 and is used to mitigate packet loops. The sections that follow show how this basic unit of MPLS label stack may be used for SFC in the MPLS label swapping case and in the MPLS label stacking. For simplicity, these sections do not describe the @@ -391,57 +374,57 @@ Figure 2: The MPLS SFC Label Stack The following processing rules apply to the Label fields: o When a classifier inserts a packet onto an SFP it sets the SPI Label to indicate the identity of the SFP, and sets the SI Label to indicate the first SF in the path. o When a component of the SFC system processes a packet it uses the - SPI Label to identify the SFP and the SI Label to determine to - which SFF or instance of an SF (an SFI) to deliver the packet. - Under normal circumstances (with the exception of branching and - reclassification - see [I-D.ietf-bess-nsh-bgp-control-plane]) the + SPI Label to identify the SFP and the SI Label to determine which + SFF or instance of an SF (an SFI) to deliver the packet to. Under + normal circumstances (with the exception of branching and re- + classification - see [I-D.ietf-bess-nsh-bgp-control-plane]) the SPI Label value is preserved on all packets. The SI Label value - is modified by SFFs and through reclassification to indicate the + is modified by SFFs and through re-classification to indicate the next hop along the SFP. The following processing rules apply to the TTL field of the SF label stack entry, and are derived from section 2.2 of [RFC8300]: o When a classifier places a packet onto an SFP it MUST set the TTL to a value between 1 and 255. It SHOULD set this according to the expected length of the SFP (i.e., the number of SFs on the SFP), but it MAY set it to a larger value according to local configuration. The maximum TTL value supported in an NSH is 63, and so the practical limit here may also be 63. o When an SFF receives a packet from any component of the SFC system (classifier, SFI, or another SFF) it MUST discard any packets with TTL set to zero. It SHOULD log such occurrences, but MUST apply rate limiting to any such logs. o An SFF MUST decrement the TTL by one each time it performs a - forwarding lookup. + lookup to forward a packet to the next SFF. o If an SFF decrements the TTL to zero it MUST NOT send the packet, and MUST discard the packet. It SHOULD log such occurrences, but MUST apply rate limiting to any such logs. o SFIs MUST ignore the TTL, but MUST mirror it back to the SFF unmodified along with the SI (which may have been changed by local - reclassification). + re-classification). o If a classifier along the SFP makes any change to the intended path of the packet including for looping, jumping, or branching - (see [I-D.ietf-bess-nsh-bgp-control-plane] it MUST NOT change the + (see [I-D.ietf-bess-nsh-bgp-control-plane]) it MUST NOT change the SI TTL of the packet. In particular, each component of the SFC system MUST NOT increase the SI TTL value otherwise loops may go undetected. 7. MPLS Label Stacking This section describes how the basic unit of MPLS label stack for SFC introduced in Section 5 is used when MPLS label stacking is used to carry information about the SFP and SFs to be executed. The use case scenarios for this approach is introduced in Section 4. @@ -458,23 +441,24 @@ fields of these label stack entries provided in Section 5 the following meanings are applied: SFC Context Label: The Label field of the SFC Context label stack entry contains a label that delivers SFC context. This label may be used to indicate the SPI encoded as a 20 bit integer using the semantics of the SPI is exactly as defined in [RFC8300] and noting that in this case a system using MPLS representation of the logical NSH MUST NOT assign SPI values greater than 2^20 - 1 or less than 16. This label may also be used to convey other SFC - context-speific semantics such as indicating how to interpret the + context-specific semantics such as indicating how to interpret the SF Label or how to forward the packet to the node that offers the - SF. + SF if so configured and coordinated with the controller that + programs the labels for the SFP. SF Label: The Label field of the SF label stack entry contains a value that identifies the next SFI to be actioned for the packet. This label may be scoped globally or within the context of the preceding SFC Context Label and comes from the range 16 ... 2^20 - 1. TC: The TC fields are as described in Section 5. S: The S bits are as described in Section 5. @@ -540,47 +524,49 @@ combination of both techniques. It is also worth noting that a classifier may be content to use an SFP as installed in the network by a control plane or management plane and so would use label swapping, but that there may be a point in the SFP where a choice of SFIs can be made (perhaps for load balancing) and where, in this instance, the classifier wishes to exert control over that choice by use of a specific entry on the label stack as described in Section 4.3. When an SFF receives a packet containing an MPLS label stack, it - checks whether it is processing an {SFP, SI} label pair for label - swapping or a {context label, SFI index} label pair for label - stacking. It then selects the appropriate SFI to which to send the - packet. When it receives the packet back from the SFI, it has four - cases to consider. + checks from the context of the incoming interface, and from the SFP + indicated by the top label whether it is processing an {SPI, SI} + label pair for label swapping or a {context label, SFI index} label + pair for label stacking. It then selects the appropriate SFI to + which to send the packet. When it receives the packet back from the + SFI, it has four cases to consider. - o If the current hop requires an {SFP, SI} and the next hop requires - an {SFP, SI}, it selects an instance of the SF to be executed at - the next hop, sets the SI label to the SI value of the next hop, - and tunnels the packet to the SFF for that SFI. + o If the current hop requires an {SPI, SI} and the next hop requires + an {SPI, SI}, it sets the SPI label according to the SFP to be + traversed, selects an instance of the SF to be executed at the + next hop, sets the SI label to the SI value of the next hop, and + tunnels the packet to the SFF for that SFI. - o If the current hop requires an {SFP, SI} and the next hop requires - a {context label, SFI label}, it pops the {SFP, SI} from the top + o If the current hop requires an {SPI, SI} and the next hop requires + a {context label, SFI label}, it pops the {SPI, SI} from the top of the MPLS label stack and tunnels the packet to the SFF indicated by the context label. o If the current hop requires a {context label, SFI label}, it pops the {context label, SFI label} from the top of the MPLS label stack. - * If the new top of the MPLS label stack contains an {SFP, SI} + * If the new top of the MPLS label stack contains an {SPI, SI} label pair, it selects an SFI to use at the next hop, and tunnels the packet to SFF for that SFI. - * If the top of the MPLS label stack contains a {context label, - SFI label}, it tunnels the packet to the SFF indicated by the - context label. + * If the new top of the MPLS label stack contains a {context + label, SFI label}, it tunnels the packet to the SFF indicated + by the context label. 9. A Note on Service Function Capabilities and SFC Proxies The concept of an "SFC proxy" is introduced in [RFC7665]. An SFC proxy is logically located between an SFF and an SFI that is not "SFC-aware". Such SFIs are not capable of handling the SFC encapsulation (whether that be NSH or MPLS) and need the encapsulation stripped from the packets they are to process. In many cases, legacy SFIs that were once deployed as "bumps in the wire" fit into this category until they have been upgraded to be SFC-aware. @@ -589,21 +575,21 @@ encapsulation so that the SFF is able to process as though it was communication with an SFC-aware SFI, and so that the SFI is unaware of the SFC encapsulation. In this regard, the job of an SFC proxy is no different when NSH encapsulation is used and when MPLS encapsulation is used as described in this document, although (of course) it is different encapsulation bytes that must be removed and reimposed. It should be noted that the SFC proxy is a logical function. It could be implemented as a separate physical component on the path - from the SFF to SFI, but it could be coresident with the SFF or it + from the SFF to SFI, but it could be co-resident with the SFF or it could be a component of the SFI. This is purely an implementation choice. Note also that the delivery of metadata (see Section 12) requires specific processing if an SFC proxy is in use. This is also no different when NSH or the MPLS encoding defined in this document is in use, and how it is handled will depend on how (or if) each non- SFC-aware SFI can receive metadata. 10. Control Plane Considerations @@ -697,33 +683,31 @@ +----------------+ | MLI | +----------------+ | Metadata Label | --------------- Figure 4: The MPLS SFC Metadata Label The Metadata Label value is an index into a table of metadata that is programmed into the network using in-band or out-of-band mechanisms. - Out-of-band mechanisms potentially include management plane and control plane solutions (such as [I-D.ietf-bess-nsh-bgp-control-plane]), but are out of scope for this document. The in-band mechanism is described in Section 12.2 The SFC Metadata Label (as a set of three labels as indicated in Figure 4) may be present zero, one, or more times in an MPLS SFC packet. For MPLS label swapping, the SFC Metadata Labels are placed immediately after the basic unit of MPLS label stack for SFC as shown - in Figure 5. For MPLS label stacking, the SFC Metadata Labels can be - present zero, one, or more times and are placed at the bottom of the - label stack as shown in Figure 6. + in Figure 5. For MPLS label stacking, the SFC Metadata Labels are + placed at the bottom of the label stack as shown in Figure 6. ---------------- ~ Tunnel Labels ~ +----------------+ ~ Optional ~ ~ Entropy Label ~ +----------------+ | SPI Label | +----------------+ | SI Label | @@ -1103,79 +1087,101 @@ Of course, an actual implementation might make considerable optimizations on this approach, but this section should provide hints about how MPLS-based SFC might be achieved with relatively small modifications to deployed MPLS devices. 15. Security Considerations Discussion of the security properties of SFC networks can be found in [RFC7665]. Further security discussion for the NSH and its use is present in [RFC8300]. Those documents provide analysis and present a - set of requirements and recommendations for security, but they do not - describe any mechanisms for securing NSH systems. + set of requirements and recommendations for security and the + normative security requirements from those documents apply to this + specification. However, it should be noted that those documents do + not describe any mechanisms for securing NSH systems. It is fundamental to the SFC design that the classifier is a trusted resource which determines the processing that the packet will be subject to, including for example the firewall. It is also fundamental to the MPLS design that packets are routed through the network using the path specified by the node imposing the labels, and that labels are swapped or popped correctly. Where an SF is not - encapsulation aware the encapsulation may be stripped by an SFC proxy + encapsulation-aware the encapsulation may be stripped by an SFC proxy such that packet may exist as a native packet (perhaps IP) on the path between SFC proxy and SF, however this is an intrinsic part of the SFC design which needs to define how a packet is protected in that environment. SFC components are configured and enabled through a management system or a control plane. This document does not make any assumptions about what mechanisms are used. Deployments should, however, be aware that vulnerabilities in the management plane or control plane of an SFC system imply vulnerabilities in the whole SFC system. Thus, control plane solutions (such as [I-D.ietf-bess-nsh-bgp-control-plane]) and management plane mechanisms must include security measures that can be enable by operators to protect their SFC systems. An analysis of the security of MPLS systems is provided in [RFC5920]. That document notes the MPLS forwarding plane has no built-in security mechanisms. Some proposals to add encryption to the MPLS forwarding plane have been suggested ([I-D.ietf-mpls-opportunistic-encrypt]), but no mechanisms have been - agreed at the time of publication of this document. That means that - procedures described in this document rely on three basic principles: + agreed at the time of publication of this document. Additionally, + MPLS does not provide any cryptographic integrity protection on the + MPLS headers. That means that procedures described in this document + rely on three basic principles: o The MPLS network is often considered to be a closed network such that insertion, modification, or inspection of packets by an - outside party is not possible. This is particularly pertinent in - the SFC context because [RFC7665] notes that "The architecture - described herein is assumed to be applicable to a single network - administrative domain." + outside party is not possible. MPLS networks are operated with + closed boundaries so that MPLS encapsulated packets are not + admitted to the network, and MPLS headers are stripped before + packets are forwarded from the network. This is particularly + pertinent in the SFC context because [RFC7665] notes that "The + architecture described herein is assumed to be applicable to a + single network administrative domain." Furthermore, [RFC8300] + states that packets originating outside the SFC-enabled domain + MUST be dropped if they contain an NSH and packets exiting the + SFC-enabled domain MUST be dropped if they contain an NSH. These + constraints apply equally to the use of MPLS to encode a logical + representation of the NSH. o The underlying transport mechanisms (such as Ethernet) between adjacent MPLS nodes may offer security mechanisms that can be used to defend packets "on the wire". o The SFC-capable devices participating in an SFC system are - responsible for verifying and protecting packets and their + responsible for verifying and protecting payload packets and their contents as well as providing other security capabilities that might be required in the particular system. Additionally, where a tunnel is used to link two non-MPLS domains, the tunnel design needs to specify how the tunnel is secured. - Thus, the security vulnerabilities are addressed (or should be - addressed) in all the underlying technologies used by this design. - No known new security vulnerabilities are introduced by this design, - but if issues are discovered in the future it is expected that they - will be addressed through modifications to control/management - components of any solution, or through changes to the underlying - technology. + Thus, this design relies on the component underlying technologies to + address the potential security vulnerabilities, and documents the + necessary protections (or risk of their absence) above. It does not + include any native security mechanisms in-band with the MPLS encoding + of the NSH functionality. + + Note that configuration elements of this system (such as the + programming of the table of metadata, see Section 12) must also be + adequately secured although such mechanisms are not in scope for this + protocol specification. + + No known new security vulnerabilities over the SFC architecture + [RFC7665] and the NSH specification [RFC8300] are introduced by this + design, but if issues are discovered in the future it is expected + that they will be addressed through modifications to control/ + management components of any solution, or through changes to the + underlying technology. 16. IANA Considerations This document requests IANA to make allocations from the "Extended Special-Purpose MPLS Label Values" subregistry of the "Special- Purpose Multiprotocol Label Switching (MPLS) Label Values" registry as follows: Value | Description | -------+-----------------------------------+-------------- @@ -1189,47 +1195,54 @@ The authors are grateful to all those who contributed to the discussions that led to this work: Loa Andersson, Andrew G. Malis, Alexander Vainshtein, Joel M. Halpern, Tony Przygienda, Stuart Mackie, Keyur Patel, and Jim Guichard. Loa Andersson provided helpful review comments. Thanks to Loa Andersson, Lizhong Jin, Matthew Bocci, Joel Halpern, and Mach Chen for reviews of this text. Thanks to Russ Mundy for his Security Directorate review and to S Moonesamy for useful - discussions. + discussions. Thanks also to Benjamin Kaduk, Alissa Cooper, Eric + Rescorla, Mirja Kuehlewind, Alvaro Retana, and Martin Vigoureux for + comprehensive reviews during IESG evaluation. The authors would like to be able to thank the authors of - [I-D.xuclad-spring-sr-service-chaining] and [RFC8402] whose original - work on service chaining and the identification of services using - SIDs, and conversation with whom helped clarify the application of - MPLS-SR to SFC. + [I-D.xuclad-spring-sr-service-programming] and [RFC8402] whose + original work on service chaining and the identification of services + using SIDs, and conversation with whom helped clarify the application + of MPLS-SR to SFC. Particular thanks to Loa Andersson for conversations and advice about working group process. 18. Contributors The following people contributed text to this document: Andrew Malis Email: agmalis@gmail.com 19. References 19.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . + [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and + L. Yong, "The Use of Entropy Labels in MPLS Forwarding", + RFC 6790, DOI 10.17487/RFC6790, November 2012, + . + [RFC7274] Kompella, K., Andersson, L., and A. Farrel, "Allocating and Retiring Special-Purpose MPLS Labels", RFC 7274, DOI 10.17487/RFC7274, June 2014, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., @@ -1240,58 +1253,47 @@ [RFC8393] Farrel, A. and J. Drake, "Operating the Network Service Header (NSH) with Next Protocol "None"", RFC 8393, DOI 10.17487/RFC8393, May 2018, . 19.2. Informative References [I-D.ietf-bess-nsh-bgp-control-plane] Farrel, A., Drake, J., Rosen, E., Uttaro, J., and L. Jalil, "BGP Control Plane for NSH SFC", draft-ietf-bess- - nsh-bgp-control-plane-05 (work in progress), January 2019. + nsh-bgp-control-plane-09 (work in progress), March 2019. [I-D.ietf-mpls-opportunistic-encrypt] Farrel, A. and S. Farrell, "Opportunistic Security in MPLS Networks", draft-ietf-mpls-opportunistic-encrypt-03 (work in progress), March 2017. - [I-D.ietf-spring-segment-routing-mpls] - Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., - Litkowski, S., and R. Shakir, "Segment Routing with MPLS - data plane", draft-ietf-spring-segment-routing-mpls-18 - (work in progress), December 2018. - - [I-D.xuclad-spring-sr-service-chaining] + [I-D.xuclad-spring-sr-service-programming] Clad, F., Xu, X., Filsfils, C., daniel.bernier@bell.ca, d., Li, C., Decraene, B., Ma, S., Yadlapalli, C., - Henderickx, W., and S. Salsano, "Segment Routing for - Service Chaining", draft-xuclad-spring-sr-service- - chaining-01 (work in progress), March 2018. + Henderickx, W., and S. Salsano, "Service Programming with + Segment Routing", draft-xuclad-spring-sr-service- + programming-01 (work in progress), October 2018. [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, DOI 10.17487/RFC3031, January 2001, . [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 2006, . [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, . - [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and - L. Yong, "The Use of Entropy Labels in MPLS Forwarding", - RFC 6790, DOI 10.17487/RFC6790, November 2012, - . - [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function Chaining (SFC) Architecture", RFC 7665, DOI 10.17487/RFC7665, October 2015, . [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, July 2018, .