RFC 9491
Integration of the Network Service Header (NSH) and Segment Routing for Service Function Chaining (SFC)
📜 RFC 9491: Integration of the Network Service Header (NSH) and Segment Routing for Service Function Chaining (SFC) 🎀
okay bestie, this one is literally about getting two of my favourite protocol brains to work together 🧠💖 NSH (the Network Service Header) and Segment Routing (SR) are like two iconic besties who are both amazing on their own, and this doc is the story of how they tag-team a service chain without stepping on each other's toes 💅✨
Quick glance at the title block so you know what you're looking at 👀🎀
- Who wrote it: J. Guichard, Ed. (Futurewei Technologies) and J. Tantsura, Ed. (Nvidia) 🧚
- Category: Standards Track 🔥 (so this is a real, official spec, not just vibes)
- Date: November 2023 📅
- Obsoletes / Updates: nothing listed in the header, so it's a fresh start, no drama 🌸
- Status: an Internet Standards Track document, reviewed publicly and approved by the IESG 👑
Abstract ✨
okay so the big idea, no cap 💅 This document describes how the Network Service Header (NSH) and Segment Routing (SR) can be integrated, including the encapsulation details, so Service Function Chaining (SFC) works efficiently while still keeping the service plane and the transport plane separate, which is exactly what the SFC architecture was designed to do 🦋
Here's the vibe check: SR handles steering packets between Service Function Forwarders (SFFs) along a Service Function Path (SFP) 🛣️ Meanwhile NSH is the one keeping the service plane intact, plus the SFC instance context and any metadata that rides along 🎀 It's giving teamwork 🫶
The payoff is really satisfying ngl 😭 A network operator gets to pick whichever transport technology makes sense in each part of their network, and they can still have an end-to-end service plane running on NSH 👑 Iconic flexibility, periodt 💜
Status of This Memo 📋
This is an Internet Standards Track document 🌈
It's an IETF product and it represents the consensus of the IETF community. It went through public review and got the green light from the Internet Engineering Steering Group (IESG) 💅 If you want more on what Internet Standards are, check Section 2 of RFC 7841 🧚
Want the current status, any errata, or a way to send feedback? Head to 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) as they stand on the publication date. Please actually read those, bestie, because they spell out your rights and restrictions for this document 📜 Code Components pulled out of this document have to include the Revised BSD License text described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as the Revised BSD License describes 💖
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' Addresses1. Introduction ✨
1.1. SFC Overview and Rationale 🌸
Okay so picture this: the way packets get treated when they enter a network with advanced Service Functions (SFs) has become a huge challenge for operators 😭 Dynamically enforcing a service-derived, appropriate forwarding policy is the whole game now 🎮
The example they give is cascading SFs at the Third Generation Partnership Project (3GPP) Gi interface (the N6 interface in 5G architecture), and it's honestly a mess 🙈 Three big problems came up: 1) every SF needs the same classification features built in, 2) some SFs get traffic they're never supposed to touch (think TCP proxies getting UDP traffic, which hurts their sizing and performance), and 3) it gets really complicated to invoke several SFs in the right order 💀
So the fix is to decouple the service topology from the physical network, which makes service delivery way simpler ✨ That's what SFC techniques are for, and they're specified in [RFC7665] 🧚
SFC is all about rationalizing service delivery logic and cutting down complexity, while also speeding up service activation for operators who need agile delivery to keep up with demanding customers 🏃♀️💨 With SFC, operators can dynamically create service planes for specific traffic flows, and each plane is built by chaining the right service functions in the right sequence 🦋 [RFC7498] gives the big-picture overview of the SFC problem space, and [RFC7665] describes the SFC data plane architecture 📚 The SFC architecture doesn't assume anything about how advanced features (like load balancing, or loose versus strict service paths) get enabled inside a domain, so operators have lots of deployment options to fit their different contexts 🌈
There are many ways to encode the info SFC needs 🤯 You could carry a service chain pointer, encode a list of loose or explicit paths, or spread a service chain identifier along with a set of context information. Likewise, the channel that carries that SFC info has options too: a new header, existing packet header fields, or an IPv6 extension header 💅 Out of all these, the IETF made a transport-independent SFC encapsulation scheme called NSH [RFC8300] 👑 It's pragmatic, because it doesn't force anyone to redo the whole specification effort for each underlying transport encapsulation 🙌 It also makes consistent SFC-based service delivery possible even when different transport protocols run in different network segments, or between SFFs versus SF-SFF hops 🫶
1.2. Requirements Language 🎀
Here's the important bit, bestie 🔥 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], but only when they appear in all capitals, exactly as shown here 💖
2. SFC within Segment Routing Networks 🦋
So [RFC8300] explains how to encapsulate the NSH directly inside a link-layer header 🔗 In this document, IANA assigned IP protocol number 145 to the NSH, so it can also be encapsulated directly inside an IP header ✨ The procedures that come next lean on that property 💅
As [RFC8402] describes, SR uses the source-routing technique 🧭 A node steers a packet through an SR policy, which is built as an ordered list of instructions called segments 🎀 SR was first designed for policy-based source routing, but it also shows up in supporting SFC [SERVICE-PROGRAMMING] 🌸
The two SR data plane encapsulations, SR-MPLS [RFC8660] and Segment Routing over IPv6 (SRv6) [RFC8754], can both encode an SF as a segment, so a whole service function chain can be written as a segment list 🧚 But, as [RFC7498] points out, traffic steering is only one slice of the problems SFC was built to solve 🙈 Other things matter too, like simplifying classification at intermediate SFs, and letting SFs coordinate their behaviour by sharing context information (a.k.a. metadata) 💜 Those should be on your radar when you design an SFC data plane solution 👀
NSH-based SFC and SR-based SFC can each work on their own, but this document shows how they can team up and complement each other through two representative application scenarios 🫶 Both scenarios can run over either SR-MPLS or SRv6 🌈
NSH-based SFC with the SR-based transport plane: In this scenario, SR-MPLS or SRv6 handles the transport encapsulation between SFFs, while the NSH is what carries and triggers the SFC policies 🚀
SR-based SFC with the integrated NSH service plane: In this scenario, every service hop in the chain is represented as a segment in the SR segment list 🛤️ SR takes care of steering traffic through the necessary SFFs as part of the segment routing path, while the NSH keeps the service plane going and holds the SFC instance context (including any associated metadata) 🎀
And yes, you can totally combine both scenarios if a specific deployment or use case needs it 💅✨
A classifier MUST use one NSH Service Path Identifier (SPI) for each SR policy 🔥 That way, different traffic flows can share the same NSH Service Function Path (SFP), and different SR policies can coexist on that same SFP without conflicting during SFF processing 💖
🫶 that's the end of part 1, bestie! more coming in the next parts, so stay tuned 🎀✨
3. NSH-Based SFC with SR-MPLS or the SRv6 Transport Tunnel ✨
okay bestie, so NSH-based service function chains don't care what transport they ride on, which means the NSH is expected to be super useful across all kinds of network domains (access, core, the whole vibe) 💖. For example, the service functions (SFs) in a chain could all chill in one data center, or be spread out across multiple locations like data centers and different Points of Presence (POPs), depending on what the network operator prefers and what service resources are available 🌸. Wherever the SFs live, you still need traffic steering through a set of SFFs, and when NSH and SR team up, that steering is handled by SR-MPLS or SRv6 🦋.
Let's walk through an example 👑. Flow F has SF instances in two data centers, DC1 and DC2. For this example, the SFC's NSH SPI is 100 and the initial Service Index (SI) is 255 🧚.
Referring to Figure 1, packets of flow F in DC1 get classified into an NSH-based service function chain. After classification they're encapsulated as <Inner Pkt><NSH: SPI 100, SI 255><Outer-transport> and forwarded to SFF1, which is the first SFF hop for this chain 💅.
After the outer transport encapsulation is removed, SFF1 uses the SPI and SI carried in 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. So 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 1Now Figure 2 🌈. DC1-GW1 does a lookup using the information in the NSH, which results in <next-hop: DC2-GW1, encapsulation: SR>. The SR encapsulation, which may be SR-MPLS or SRv6, carries the SR segment list that forwards 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 2When the packet arrives at DC2, as shown in Figure 3, the SR encapsulation is removed, and DC2-GW1 does a lookup on the NSH, which results in next hop: SFF2. When SFF2 gets the packet, it does a lookup on <NSH: SPI 100, SI 254> and decides to forward it to SF2. SF2 applies its service, decrements the SI by 1, and returns the packet to SFF2, so 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 3Why is this scheme so iconic? Here's the tea 🫖:
- The network operator gets to take advantage of the transport-independent nature of the NSH encapsulation while the service is provisioned end-to-end. 💜
- The network operator gets to take advantage of the traffic-steering (traffic-engineering) capability of SR where appropriate. 🔥
- There's a clear division of responsibility and scope between the NSH and SR. 🫶
Note that this scenario applies 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). Also, the example above can be implemented using end-to-end segment routing between SFF1 and SFF2, no cap 🙈. (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 ✨
Okay so in this scenario, we're assuming the SFs are NSH-aware 💅 which means we don't need an SFC proxy to get SFC working. The vibe is that SR-MPLS or SRv6 handles the SFF-to-SFF transport, and the NSH provides the service plane between SFs. That way the SFC context (like the service plane path the SPI points to) and any metadata stick around the whole time 🎀
So when a service function chain gets set up, a packet on that chain shows up carrying an NSH. The NSH keeps the end-to-end service plane going through the SFC context 🦋 An SFF uses that SFC context to figure out the SR segment list for sending the packet on to the next-hop SFFs. Then the packet gets wrapped in the SR header and sent through the SR domain like normal SR stuff 🌸
When a packet needs to go to an SF attached to an SFF, the SFF looks up the segment identifier (SID) tied to that SF 👀 With SR-MPLS, that's a Prefix-SID [RFC8402]. With SRv6, the behavior in this document is called END.NSH, and Section 11.2 covers how IANA hands out the code point 🧚 The lookup gives the SFF the next-hop context between it and the SF, like the destination Media Access Control (MAC) address if Ethernet encapsulation is being used between them 💖 Also, the SFF strips the SR info off the packet, updates it, and stashes it in a cache indexed by the NSH Service Path Identifier (SPI) and the Service Index (SI) minus 1. That saved SR info is what gets used to wrap and forward the packets that come back from the SF ✨
The "remember the segment list" move happens at the very end of the regular logic, and the "reattach the segment list" move happens right before the SR process forwards the packet to the next entry in the list. Both get the full breakdown in Section 5 🫶
When the SF gets the packet, it processes it like usual. If the SF is sitting with a classifier, the already-processed packet might get reclassified 🙈 The SF then sends the packet back to the SFF. Once the SFF gets it back, it pulls the SR info out using the NSH SPI and SI as the key into the cache. Then it pushes the saved SR header on top of the NSH header and forwards the packet to the next segment in the list 💅 Heads up though: the cache lookup could fail if reclassification at the SF changed the NSH SPI and/or SI into values that aren't in the SFF cache. In that case, the SFF must generate an error and drop the packet 💀
Figure 4 shows what this looks like 👇
+-----+ +-----+
| 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 SFCSo why's this scheme so good? Let me count the ways 🍓
- It's 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 🎀
Here we cover the End.NSH behavior (SRv6), the Prefix-SID behavior (SR-MPLS), and the NSH processing logic 💖
5.1. SR-Based SFC (SR-MPLS) Packet Processing 🌸
When an SFF gets a packet destined to S, and S is a local Prefix-SID tied to an SF, the SFF strips the SR segment list (label stack) off the packet, updates the SR info, and saves it in a cache indexed by the NSH Service Path Identifier (SPI) and the Service Index (SI) minus 1. That saved SR info is then used to re-encapsulate and forward the packets 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 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 comes back 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, so the segment routing header is a stack of MPLS labels 🍓
When an NSH is carried within an SR-MPLS transport, the full encapsulation headers look like Figure 5 ✨
+------------------+
~ SR-MPLS Labels ~
+------------------+
| NSH Base Hdr |
+------------------+
| Service Path Hdr |
+------------------+
~ Metadata ~
+------------------+
Figure 5: NSH Using SR-MPLS TransportAs 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." 🤓 So when an NSH rides beneath SR-MPLS, the NSH-based SFC has to end at the tail-end node of the SR-MPLS label stack 😭 That can be done with either the NEXT or CONTINUE operation.
If the NEXT operation is used, then at the end of the SR-MPLS path, the tail end has to be given an indication that the NSH follows the SR-MPLS label stack, as described by [RFC8596] 🫶
If the CONTINUE operation is used, that's the equivalent of MPLS Ultimate Hop Popping (UHP). So it's necessary to make sure the penultimate hop node doesn't pop the top label of the SR-MPLS label stack, because that would expose the NSH to the wrong SFF 🙈 This is handled by setting the No Penultimate Hop Popping (No-PHP) flag in the 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 🦋
okay bestie, so when the NSH rides inside an SRv6 transport, the whole encapsulation looks like 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 Transportthe way the NSH gets wrapped up after SRv6 is signalled by the IP protocol number for the NSH, and that number goes in the Next Header of the SRH. main character energy 🌸
7. Security Considerations 🔒
the generic SFC security stuff lives in [RFC7665] 🧚
the NSH-specific security considerations are in [RFC8300] 💜
and the generic segment routing security considerations are in Section 7 of [RFC8754] and Section 5 of [RFC8663]. read them, bestie, this part is serious 😭
8. Backwards Compatibility 🎀
for SRv6/IPv6, if a processing node doesn't recognise the NSH, it should follow the procedures in Section 4 of [RFC8200] 🫶
for SR-MPLS, if a processing node doesn't recognise 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 that the implementation decides on, okay? ⏰ Further, an implementation MAY allow network operators to set that time value, so operators get a say 👑
and here's the important bit 🚨: if a packet shows up from an SF and there's no matching cached entry, the SFF SHOULD log the event and MUST drop the packet. no matching entry, no packet, periodt 💀
10. MTU Considerations 🦋
aligned with Section 5 of [RFC8300] and Section 5.3 of [RFC8754], it is RECOMMENDED for network operators to bump up the underlying MTU so SR/NSH traffic gets forwarded inside an SR domain without fragmentation. no fragmenting drama, please 🙏✨
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.comAuthors' 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📦 where this page comes from
- ietf: rfc9491 2023-11
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms