diff options
Diffstat (limited to 'doc/rfc/rfc9491.txt')
| -rw-r--r-- | doc/rfc/rfc9491.txt | 781 |
1 files changed, 781 insertions, 0 deletions
diff --git a/doc/rfc/rfc9491.txt b/doc/rfc/rfc9491.txt new file mode 100644 index 0000000..babdb3b --- /dev/null +++ b/doc/rfc/rfc9491.txt @@ -0,0 +1,781 @@ + + + + +Internet Engineering Task Force (IETF) J. Guichard, Ed. +Request for Comments: 9491 Futurewei Technologies +Category: Standards Track J. Tantsura, Ed. +ISSN: 2070-1721 Nvidia + November 2023 + + +Integration of the Network Service Header (NSH) and Segment Routing for + Service Function Chaining (SFC) + +Abstract + + This document describes the integration of the Network Service Header + (NSH) and Segment Routing (SR), as well as encapsulation details, to + efficiently support Service Function Chaining (SFC) while maintaining + separation of the service and transport planes as originally intended + by the SFC architecture. + + Combining these technologies allows SR to be used for steering + packets between Service Function Forwarders (SFFs) along a given + Service Function Path (SFP), whereas the NSH is responsible for + maintaining the integrity of the service plane, the SFC instance + context, and any associated metadata. + + This integration demonstrates that the NSH and SR can work + cooperatively and provide a network operator with the flexibility to + use whichever transport technology makes sense in specific areas of + their network infrastructure while still maintaining an end-to-end + service plane using the NSH. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc9491. + +Copyright Notice + + Copyright (c) 2023 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 Revised BSD License text as described in Section 4.e of the + Trust Legal Provisions and are provided without warranty as described + in the Revised BSD License. + +Table of Contents + + 1. Introduction + 1.1. SFC Overview and Rationale + 1.2. Requirements Language + 2. SFC within Segment Routing Networks + 3. NSH-Based SFC with SR-MPLS or the SRv6 Transport Tunnel + 4. SR-Based SFC with the Integrated NSH Service Plane + 5. Packet Processing for SR-Based SFC + 5.1. SR-Based SFC (SR-MPLS) Packet Processing + 5.2. SR-Based SFC (SRv6) Packet Processing + 6. Encapsulation + 6.1. NSH Using SR-MPLS Transport + 6.2. NSH Using SRv6 Transport + 7. Security Considerations + 8. Backwards Compatibility + 9. Caching Considerations + 10. MTU Considerations + 11. IANA Considerations + 11.1. Protocol Number for the NSH + 11.2. SRv6 Endpoint Behavior for the NSH + 12. References + 12.1. Normative References + 12.2. Informative References + Contributors + Authors' Addresses + +1. Introduction + + +1.1. SFC Overview and Rationale + + The dynamic enforcement of a service-derived and adequate forwarding + policy for packets entering a network that supports advanced Service + Functions (SFs) has become a key challenge for network operators. + For instance, cascading SFs at the Third Generation Partnership + Project (3GPP) Gi interface (N6 interface in 5G architecture) has + shown limitations such as 1) redundant classification features that + must be supported by many SFs to execute their function; 2) some SFs + that receive traffic that they are not supposed to process (e.g., TCP + proxies receiving UDP traffic), which inevitably affects their + dimensioning and performance; and 3) an increased design complexity + related to the properly ordered invocation of several SFs. + + In order to solve those problems and to decouple the service's + topology from the underlying physical network while allowing for + simplified service delivery, SFC techniques have been introduced + [RFC7665]. + + SFC techniques are meant to rationalize the service delivery logic + and reduce the resulting complexity while optimizing service + activation time cycles for operators that need more agile service + delivery procedures to better accommodate ever-demanding customer + requirements. SFC allows network operators to dynamically create + service planes that can be used by specific traffic flows. Each + service plane is realized by invoking and chaining the relevant + service functions in the right sequence. [RFC7498] provides an + overview of the overall SFC problem space, and [RFC7665] specifies an + SFC data plane architecture. The SFC architecture does not make + assumptions on how advanced features (e.g., load balancing, loose or + strict service paths) could be enabled within a domain. Various + deployment options are made available to operators with the SFC + architecture; this approach is fundamental to accommodate various and + heterogeneous deployment contexts. + + Many approaches can be considered for encoding the information + required for SFC purposes (e.g., communicate a service chain pointer, + encode a list of loose/explicit paths, or disseminate a service chain + identifier together with a set of context information). Likewise, + many approaches can also be considered for the channel to be used to + carry SFC-specific information (e.g., define a new header, reuse + existing packet header fields, or define an IPv6 extension header). + Among all these approaches, the IETF created a transport-independent + SFC encapsulation scheme: NSH [RFC8300]. This design is pragmatic, + as it does not require replicating the same specification effort as a + function of underlying transport encapsulation. Moreover, this + design approach encourages consistent SFC-based service delivery in + networks enabling distinct transport protocols in various network + segments or even between SFFs vs. SF-SFF hops. + +1.2. Requirements Language + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in + BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all + capitals, as shown here. + +2. SFC within Segment Routing Networks + + [RFC8300] specifies how to encapsulate the NSH directly within a + link-layer header. In this document, IANA has assigned IP protocol + number 145 for the NSH so that it can also be encapsulated directly + within an IP header. The procedures that follow make use of this + property. + + As described in [RFC8402], SR leverages the source-routing technique. + Concretely, a node steers a packet through an SR policy instantiated + as an ordered list of instructions called segments. While initially + designed for policy-based source routing, SR also finds its + application in supporting SFC [SERVICE-PROGRAMMING]. + + The two SR data plane encapsulations, namely SR-MPLS [RFC8660] and + Segment Routing over IPv6 (SRv6) [RFC8754], can encode an SF as a + segment so that a service function chain can be specified as a + segment list. Nevertheless, and as discussed in [RFC7498], traffic + steering is only a subset of the issues that motivated the design of + the SFC architecture. Further considerations, such as simplifying + classification at intermediate SFs and allowing for coordinated + behaviors among SFs by means of supplying context information (a.k.a. + metadata), should be considered when designing an SFC data plane + solution. + + While each scheme (i.e., NSH-based SFC and SR-based SFC) can work + independently, this document describes how the two can be used + together in concert and to complement each other through two + representative application scenarios. Both application scenarios may + be supported using either SR-MPLS or SRv6: + + NSH-based SFC with the SR-based transport plane: + In this scenario, SR-MPLS or SRv6 provides the transport + encapsulation between SFFs, while the NSH is used to convey and + trigger SFC policies. + + SR-based SFC with the integrated NSH service plane: + In this scenario, each service hop of the service function chain + is represented as a segment of the SR segment list. SR is thus + responsible for steering traffic through the necessary SFFs as + part of the segment routing path, while the NSH is responsible for + maintaining the service plane and holding the SFC instance context + (including associated metadata). + + Of course, it is possible to combine both of these two scenarios to + support specific deployment requirements and use cases. + + A classifier MUST use one NSH Service Path Identifier (SPI) for each + SR policy so that different traffic flows can use the same NSH + Service Function Path (SFP) and different SR policies can coexist on + the same SFP without conflict during SFF processing. + +3. NSH-Based SFC with SR-MPLS or the SRv6 Transport Tunnel + + Because of the transport-independent nature of NSH-based service + function chains, it is expected that the NSH has broad applicability + across different network domains (e.g., access, core). By way of + illustration, the various SFs involved in a service function chain + may be available in a single data center or spread throughout + multiple locations (e.g., data centers, different Points of Presence + (POPs)), depending upon the network operator preference and/or + availability of service resources. Regardless of where the SFs are + deployed, it is necessary to provide traffic steering through a set + of SFFs, and when NSH and SR are integrated, this is provided by SR- + MPLS or SRv6. + + The following three figures provide an example of an SFC-established + flow F that has SF instances located in different data centers, DC1 + and DC2. For the purpose of illustration, let the SFC's NSH SPI be + 100 and the initial Service Index (SI) be 255. + + Referring to Figure 1, packets of flow F in DC1 are classified into + an NSH-based service function chain, encapsulated after + classification as <Inner Pkt><NSH: SPI 100, SI 255><Outer-transport>, + and forwarded to SFF1 (which is the first SFF hop for this service + function chain). + + After removing the outer transport encapsulation, SFF1 uses the SPI + and SI carried within the NSH encapsulation to determine that it + should forward the packet to SF1. SF1 applies its service, + decrements the SI by 1, and returns the packet to SFF1. Therefore, + SFF1 has <SPI 100, SI 254> when the packet comes back from SF1. SFF1 + does a lookup on <SPI 100, SI 254>, which results in <next-hop: + DC1-GW1> and forwards the packet to DC1-GW1. + + +--------------------------- DC1 ----------------------------+ + | +-----+ | + | | SF1 | | + | +--+--+ | + | | | + | | | + | +------------+ | +------------+ | + | | N(100,255) | | | N(100,254) | | + | +------------+ | +------------+ | + | | F:Inner Pkt| | | F:Inner Pkt| | + | +------------+ ^ | | +------------+ | + | (2) | | | (3) | + | | | v | + | (1) | (4) | + |+------------+ ----> +--+---+ ----> +---------+ | + || | NSH | | NSH | | | + || Classifier +------------+ SFF1 +--------------+ DC1-GW1 + | + || | | | | | | + |+------------+ +------+ +---------+ | + | | + | +------------+ +------------+ | + | | N(100,255) | | N(100,254) | | + | +------------+ +------------+ | + | | F:Inner Pkt| | F:Inner Pkt| | + | +------------+ +------------+ | + | | + +------------------------------------------------------------+ + + Figure 1: SR for Inter-DC SFC - Part 1 + + Referring now to Figure 2, DC1-GW1 performs a lookup using the + information conveyed in the NSH, which results in <next-hop: DC2-GW1, + encapsulation: SR>. The SR encapsulation, which may be SR-MPLS or + SRv6, has the SR segment list to forward the packet across the inter- + DC network to DC2. + + +----------- Inter DC ----------------+ + (4) | (5) | + +------+ ----> | +---------+ ----> +---------+ | + | | NSH | | | SR | | | + + SFF1 +----------|-+ DC1-GW1 +-------------+ DC2-GW1 + | + | | | | | | | | + +------+ | +---------+ +---------+ | + | | + | +------------+ | + | | S(DC2-GW1) | | + | +------------+ | + | | N(100,254) | | + | +------------+ | + | | F:Inner Pkt| | + | +------------+ | + +-------------------------------------+ + + Figure 2: SR for Inter-DC SFC - Part 2 + + When the packet arrives at DC2, as shown in Figure 3, the SR + encapsulation is removed, and DC2-GW1 performs a lookup on the NSH, + which results in next hop: SFF2. When SFF2 receives the packet, it + performs a lookup on <NSH: SPI 100, SI 254> and determines to forward + the packet to SF2. SF2 applies its service, decrements the SI by 1, + and returns the packet to SFF2. Therefore, SFF2 has <NSH: SPI 100, + SI 253> when the packet comes back from SF2. SFF2 does a lookup on + <NSH: SPI 100, SI 253>, which results in the end of the service + function chain. + + +------------------------ DC2 ----------------------+ + | +-----+ | + | | SF2 | | + | +--+--+ | + | | | + | | | + | +------------+ | +------------+ | + | | N(100,254) | | | N(100,253) | | + | +------------+ | +------------+ | + | | F:Inner Pkt| | | F:Inner Pkt| | + | +------------+ ^ | | +------------+ | + | (7) | | | (8) | + | | | v | + (5) | (6) | (9) | ++---------+ ---> | +----------+ ----> +--+---+ ----> | +| | SR | | | NSH | | IP | ++ DC1-GW1 +--------|-+ DC2-GW1 +------------+ SFF2 | | +| | | | | | | | ++---------+ | +----------+ +------+ | + | | + | +------------+ +------------+ | + | | N(100,254) | | F:Inner Pkt| | + | +------------+ +------------+ | + | | F:Inner Pkt| | + | +------------+ | + +---------------------------------------------------+ + + Figure 3: SR for Inter-DC SFC - Part 3 + + The benefits of this scheme are listed hereafter: + + * The network operator is able to take advantage of the transport- + independent nature of the NSH encapsulation while the service is + provisioned end-to-end. + + * The network operator is able to take advantage of the traffic- + steering (traffic-engineering) capability of SR where appropriate. + + * Clear responsibility division and scope between the NSH and SR. + + Note that this scenario is applicable to any case where multiple + segments of a service function chain are distributed across multiple + domains or where traffic-engineered paths are necessary between SFFs + (strict forwarding paths, for example). Further, note that the above + example can also be implemented using end-to-end segment routing + between SFF1 and SFF2. (As such, DC-GW1 and DC-GW2 are forwarding + the packets based on segment routing instructions and are not looking + at the NSH header for forwarding.) + +4. SR-Based SFC with the Integrated NSH Service Plane + + In this scenario, we assume that the SFs are NSH-aware; therefore, it + should not be necessary to implement an SFC proxy to achieve SFC. + The operation relies upon SR-MPLS or SRv6 to perform SFF-SFF + transport and the NSH to provide the service plane between SFs, + thereby maintaining SFC context (e.g., the service plane path + referenced by the SPI) and any associated metadata. + + When a service function chain is established, a packet associated + with that chain will first carry an NSH that will be used to maintain + the end-to-end service plane through use of the SFC context. The SFC + context is used by an SFF to determine the SR segment list for + forwarding the packet to the next-hop SFFs. The packet is then + encapsulated using the SR header and forwarded in the SR domain + following normal SR operations. + + When a packet has to be forwarded to an SF attached to an SFF, the + SFF performs a lookup on the segment identifier (SID) associated with + the SF. In the case of SR-MPLS, this will be a Prefix-SID [RFC8402]. + In the case of SRv6, the behavior described within this document is + assigned the name END.NSH, and Section 11.2 describes the allocation + of the code point by IANA. The result of this lookup allows the SFF + to retrieve the next-hop context between the SFF and SF (e.g., the + destination Media Access Control (MAC) address in case Ethernet + encapsulation is used between the SFF and SF). In addition, the SFF + strips the SR information from the packet, updates the SR + information, and saves it to a cache indexed by the NSH Service Path + Identifier (SPI) and the Service Index (SI) decremented by 1. This + saved SR information is used to encapsulate and forward the packet(s) + coming back from the SF. + + The behavior of remembering the SR segment list occurs at the end of + the regularly defined logic. The behavior of reattaching the segment + list occurs before the SR process of forwarding the packet to the + next entry in the segment list. Both behaviors are further detailed + in Section 5. + + When the SF receives the packet, it processes it as usual. When the + SF is co-resident with a classifier, the already-processed packet may + be reclassified. The SF sends the packet back to the SFF. Once the + SFF receives this packet, it extracts the SR information using the + NSH SPI and SI as the index into the cache. The SFF then pushes the + retrieved SR header on top of the NSH header and forwards the packet + to the next segment in the segment list. The lookup in the SFF cache + might fail if reclassification at the SF changed the NSH SPI and/or + SI to values that do not exist in the SFF cache. In such a case, the + SFF must generate an error and drop the packet. + + Figure 4 illustrates an example of this scenario. + + +-----+ +-----+ + | SF1 | | SF2 | + +--+--+ +--+--+ + | | + | | + +-----------+ | +-----------+ +-----------+ | +-----------+ + |N(100,255) | | |N(100,254) | |N(100,254) | | |N(100,253) | + +-----------+ | +-----------+ +-----------+ | +-----------+ + |F:Inner Pkt| | |F:Inner Pkt| |F:Inner Pkt| | |F:Inner Pkt| + +-----------+ | +-----------+ +-----------+ | +-----------+ + (2) ^ | (3) | (5) ^ | (6) | + | | | | | | + | | | | | | + (1) | | v (4) | | v (7) ++------------+ ---> +-+----+ ----> +---+--+ --> +| | NSHoverSR | | NSHoverSR | | IP +| Classifier +-----------+ SFF1 +---------------------+ SFF2 | +| | | | | | ++------------+ +------+ +------+ + + +------------+ +------------+ +------------+ + | S(SF1) | | S(SF2) | | F:Inner Pkt| + +------------+ +------------+ +------------+ + | S(SFF2) | | N(100,254) | + +------------+ +------------+ + | S(SF2) | | F:Inner Pkt| + +------------+ +------------+ + | N(100,255) | + +------------+ + | F:Inner Pkt| + +------------+ + + Figure 4: NSH over SR for SFC + + The benefits of this scheme include the following: + + * It is economically sound for SF vendors to only support one + unified SFC solution. The SF is unaware of the SR. + + * It simplifies the SFF (i.e., the SR router) by nullifying the + needs for reclassification and SR proxy. + + * SR is also used for forwarding purposes, including between SFFs. + + * It takes advantage of SR to eliminate the NSH forwarding state in + SFFs. This applies each time strict or loose SFPs are in use. + + * It requires no interworking, as would be the case if SR-MPLS-based + SFC and NSH-based SFC were deployed as independent mechanisms in + different parts of the network. + +5. Packet Processing for SR-Based SFC + + This section describes the End.NSH behavior (SRv6), Prefix-SID + behavior (SR-MPLS), and NSH processing logic. + +5.1. SR-Based SFC (SR-MPLS) Packet Processing + + When an SFF receives a packet destined to S and S is a local Prefix- + SID associated with an SF, the SFF strips the SR segment list (label + stack) from the packet, updates the SR information, and saves it to a + cache indexed by the NSH Service Path Identifier (SPI) and the + Service Index (SI) decremented by 1. This saved SR information is + used to re-encapsulate and forward the packet(s) coming back from the + SF. + +5.2. SR-Based SFC (SRv6) Packet Processing + + This section describes the End.NSH behavior and NSH processing logic + for SRv6. The pseudocode is shown below. + + When N receives a packet destined to S and S is a local End.NSH SID, + the processing is the same as that specified by [RFC8754], + Section 4.3.1.1, up through line S15. + + After S15, if S is a local End.NSH SID, then: + + S15.1. Remove and store IPv6 and SRH headers in local cache + indexed by <NSH: service-path-id, service-index -1> + S15.2. Submit the packet to the NSH FIB lookup and transmit + to the destination associated with <NSH: + service-path-id, service-index> + + | Note: The End.NSH behavior interrupts the normal SRH packet + | processing, as described in [RFC8754], Section 4.3.1.1, which + | does not continue to S16 at this time. + + When a packet is returned to the SFF from the SF, reattach the cached + IPv6 and SRH headers based on the <NSH: service-path-id, service- + index> from the NSH header. Then, resume processing from [RFC8754], + Section 4.3.1.1 with line S16. + +6. Encapsulation + + +6.1. NSH Using SR-MPLS Transport + + SR-MPLS instantiates segment identifiers (SIDs) as MPLS labels; + therefore, the segment routing header is a stack of MPLS labels. + + When carrying an NSH within an SR-MPLS transport, the full + encapsulation headers are as illustrated in Figure 5. + + +------------------+ + ~ SR-MPLS Labels ~ + +------------------+ + | NSH Base Hdr | + +------------------+ + | Service Path Hdr | + +------------------+ + ~ Metadata ~ + +------------------+ + + Figure 5: NSH Using SR-MPLS Transport + + As described in [RFC8402], "[t]he IGP signaling extension for IGP- + Prefix segment includes a flag to indicate whether directly connected + neighbors of the node on which the prefix is attached should perform + the NEXT operation or the CONTINUE operation when processing the + SID." When an NSH is carried beneath SR-MPLS, it is necessary to + terminate the NSH-based SFC at the tail-end node of the SR-MPLS label + stack. This can be achieved using either the NEXT or CONTINUE + operation. + + If the NEXT operation is to be used, then at the end of the SR-MPLS + path, it is necessary to provide an indication to the tail end that + the NSH follows the SR-MPLS label stack as described by [RFC8596]. + + If the CONTINUE operation is to be used, this is the equivalent of + MPLS Ultimate Hop Popping (UHP); therefore, it is necessary to ensure + that the penultimate hop node does not pop the top label of the SR- + MPLS label stack and thereby expose the NSH to the wrong SFF. This + is realized by setting the No Penultimate Hop Popping (No-PHP) flag + in Prefix-SID Sub-TLV [RFC8667] [RFC8665]. It is RECOMMENDED that a + specific Prefix-SID be allocated at each node for use by the SFC + application for this purpose. + +6.2. NSH Using SRv6 Transport + + When carrying a NSH within an SRv6 transport, the full encapsulation + is as illustrated in Figure 6. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Next Header | Hdr Ext Len | Routing Type | Segments Left | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Last Entry | Flags | Tag | S + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ e + | | g + | Segment List[0] (128-bit IPv6 address) | m + | | e + | | n + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ t + | | + | | R + ~ ... ~ o + | | u + | | t + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ i + | | n + | Segment List[n] (128-bit IPv6 address) | g + | | + | | S + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ R + // // H + // Optional Type Length Value objects (variable) // + // // + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |Ver|O|U| TTL | Length |U|U|U|U|MD Type| Next Protocol | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ N + | Service Path Identifier | Service Index | S + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ H + | | + ~ Variable-Length Context Headers (opt.) ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 6: NSH Using SRv6 Transport + + Encapsulation of the NSH following SRv6 is indicated by the IP + protocol number for the NSH in the Next Header of the SRH. + +7. Security Considerations + + Generic SFC-related security considerations are discussed in + [RFC7665]. + + NSH-specific security considerations are discussed in [RFC8300]. + + Generic security considerations related to segment routing are + discussed in Section 7 of [RFC8754] and Section 5 of [RFC8663]. + +8. Backwards Compatibility + + For SRv6/IPv6, if a processing node does not recognize the NSH, it + should follow the procedures described in Section 4 of [RFC8200]. + For SR-MPLS, if a processing node does not recognize the NSH, it + should follow the procedures laid out in Section 3.18 of [RFC3031]. + +9. Caching Considerations + + The cache mechanism must remove cached entries at an appropriate time + determined by the implementation. Further, an implementation MAY + allow network operators to set the said time value. In the case + where a packet arriving from an SF does not have a matching cached + entry, the SFF SHOULD log this event and MUST drop the packet. + +10. MTU Considerations + + Aligned with Section 5 of [RFC8300] and Section 5.3 of [RFC8754], it + is RECOMMENDED for network operators to increase the underlying MTU + so that SR/NSH traffic is forwarded within an SR domain without + fragmentation. + +11. IANA Considerations + +11.1. Protocol Number for the NSH + + IANA has assigned protocol number 145 for the NSH [RFC8300] in the + "Assigned Internet Protocol Numbers" registry + <https://www.iana.org/assignments/protocol-numbers/>. + + +=========+=========+================+================+===========+ + | Decimal | Keyword | Protocol | IPv6 Extension | Reference | + | | | | Header | | + +=========+=========+================+================+===========+ + | 145 | NSH | Network | N | RFC 9491 | + | | | Service Header | | | + +---------+---------+----------------+----------------+-----------+ + + Table 1: Assigned Internet Protocol Numbers Registry + +11.2. SRv6 Endpoint Behavior for the NSH + + IANA has allocated the following value in the "SRv6 Endpoint + Behaviors" subregistry under the "Segment Routing" registry: + + +=======+========+===================+===========+============+ + | Value | Hex | Endpoint Behavior | Reference | Change | + | | | | | Controller | + +=======+========+===================+===========+============+ + | 84 | 0x0054 | End.NSH - NSH | RFC 9491 | IETF | + | | | Segment | | | + +-------+--------+-------------------+-----------+------------+ + + Table 2: SRv6 Endpoint Behaviors Subregistry + +12. References + +12.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, + <https://www.rfc-editor.org/info/rfc2119>. + + [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol + Label Switching Architecture", RFC 3031, + DOI 10.17487/RFC3031, January 2001, + <https://www.rfc-editor.org/info/rfc3031>. + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, <https://www.rfc-editor.org/info/rfc8174>. + + [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 + (IPv6) Specification", STD 86, RFC 8200, + DOI 10.17487/RFC8200, July 2017, + <https://www.rfc-editor.org/info/rfc8200>. + + [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., + "Network Service Header (NSH)", RFC 8300, + DOI 10.17487/RFC8300, January 2018, + <https://www.rfc-editor.org/info/rfc8300>. + + [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, <https://www.rfc-editor.org/info/rfc8402>. + + [RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., + Decraene, B., Litkowski, S., and R. Shakir, "Segment + Routing with the MPLS Data Plane", RFC 8660, + DOI 10.17487/RFC8660, December 2019, + <https://www.rfc-editor.org/info/rfc8660>. + + [RFC8663] Xu, X., Bryant, S., Farrel, A., Hassan, S., Henderickx, + W., and Z. Li, "MPLS Segment Routing over IP", RFC 8663, + DOI 10.17487/RFC8663, December 2019, + <https://www.rfc-editor.org/info/rfc8663>. + + [RFC8665] Psenak, P., Ed., Previdi, S., Ed., Filsfils, C., Gredler, + H., Shakir, R., Henderickx, W., and J. Tantsura, "OSPF + Extensions for Segment Routing", RFC 8665, + DOI 10.17487/RFC8665, December 2019, + <https://www.rfc-editor.org/info/rfc8665>. + + [RFC8667] Previdi, S., Ed., Ginsberg, L., Ed., Filsfils, C., + Bashandy, A., Gredler, H., and B. Decraene, "IS-IS + Extensions for Segment Routing", RFC 8667, + DOI 10.17487/RFC8667, December 2019, + <https://www.rfc-editor.org/info/rfc8667>. + + [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., + Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header + (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, + <https://www.rfc-editor.org/info/rfc8754>. + +12.2. Informative References + + [RFC7498] Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for + Service Function Chaining", RFC 7498, + DOI 10.17487/RFC7498, April 2015, + <https://www.rfc-editor.org/info/rfc7498>. + + [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function + Chaining (SFC) Architecture", RFC 7665, + DOI 10.17487/RFC7665, October 2015, + <https://www.rfc-editor.org/info/rfc7665>. + + [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>. + + [SERVICE-PROGRAMMING] + Clad, F., Ed., Xu, X., Ed., Filsfils, C., Bernier, D., Li, + C., Decraene, B., Ma, S., Yadlapalli, C., Henderickx, W., + and S. Salsano, "Service Programming with Segment + Routing", Work in Progress, Internet-Draft, draft-ietf- + spring-sr-service-programming-08, 21 August 2023, + <https://datatracker.ietf.org/doc/html/draft-ietf-spring- + sr-service-programming-08>. + +Contributors + + The following coauthors provided valuable inputs and text + contributions to this document. + + Mohamed Boucadair + Orange + Email: mohamed.boucadair@orange.com + + + Joel Halpern + Ericsson + Email: joel.halpern@ericsson.com + + + Syed Hassan + Cisco System, inc. + Email: shassan@cisco.com + + + Wim Henderickx + Nokia + Email: wim.henderickx@nokia.com + + + Haoyu Song + Futurewei Technologies + Email: haoyu.song@futurewei.com + + +Authors' Addresses + + James N Guichard (editor) + Futurewei Technologies + 2330 Central Expressway + Santa Clara, CA + United States of America + Email: james.n.guichard@futurewei.com + + + Jeff Tantsura (editor) + Nvidia + United States of America + Email: jefftant.ietf@gmail.com |