| < draft-ietf-spring-nsh-sr-10.txt | draft-ietf-spring-nsh-sr-11.txt > | |||
|---|---|---|---|---|
| SPRING J. Guichard, Ed. | SPRING J. Guichard, Ed. | |||
| Internet-Draft Futurewei Technologies | Internet-Draft Futurewei Technologies | |||
| Intended status: Standards Track J. Tantsura, Ed. | Intended status: Standards Track J. Tantsura, Ed. | |||
| Expires: June 16, 2022 Microsoft | Expires: 21 October 2022 Microsoft | |||
| December 13, 2021 | April 2022 | |||
| Integration of Network Service Header (NSH) and Segment Routing for | Integration of Network Service Header (NSH) and Segment Routing for | |||
| Service Function Chaining (SFC) | Service Function Chaining (SFC) | |||
| draft-ietf-spring-nsh-sr-10 | draft-ietf-spring-nsh-sr-11 | |||
| Abstract | Abstract | |||
| This document describes the integration of the Network Service Header | This document describes the integration of the Network Service Header | |||
| (NSH) and Segment Routing (SR), as well as encapsulation details, to | (NSH) and Segment Routing (SR), as well as encapsulation details, to | |||
| support Service Function Chaining (SFC) in an efficient manner while | support Service Function Chaining (SFC) in an efficient manner while | |||
| maintaining separation of the service and transport planes as | maintaining separation of the service and transport planes as | |||
| originally intended by the SFC architecture. | originally intended by the SFC architecture. | |||
| Combining these technologies allows SR to be used for steering | Combining these technologies allows SR to be used for steering | |||
| skipping to change at page 1, line 48 ¶ | skipping to change at page 1, line 48 ¶ | |||
| Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
| Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
| working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
| Drafts is at https://datatracker.ietf.org/drafts/current/. | Drafts is at https://datatracker.ietf.org/drafts/current/. | |||
| Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
| and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
| time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
| material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
| This Internet-Draft will expire on June 16, 2022. | This Internet-Draft will expire on 3 October 2022. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2021 IETF Trust and the persons identified as the | Copyright (c) 2022 IETF Trust and the persons identified as the | |||
| document authors. All rights reserved. | document authors. All rights reserved. | |||
| This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
| Provisions Relating to IETF Documents | Provisions Relating to IETF Documents (https://trustee.ietf.org/ | |||
| (https://trustee.ietf.org/license-info) in effect on the date of | license-info) in effect on the date of publication of this document. | |||
| publication of this document. Please review these documents | Please review these documents carefully, as they describe your rights | |||
| carefully, as they describe your rights and restrictions with respect | and restrictions with respect to this document. Code Components | |||
| to this document. Code Components extracted from this document must | extracted from this document must include Revised BSD License text as | |||
| include Simplified BSD License text as described in Section 4.e of | described in Section 4.e of the Trust Legal Provisions and are | |||
| the Trust Legal Provisions and are provided without warranty as | provided without warranty as described in the Revised BSD License. | |||
| described in the Simplified BSD License. | ||||
| Table of Contents | Table of Contents | |||
| 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | |||
| 1.1. SFC Overview and Rationale . . . . . . . . . . . . . . . 3 | 1.1. SFC Overview and Rationale . . . . . . . . . . . . . . . 3 | |||
| 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 4 | 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 4 | |||
| 2. SFC within Segment Routing Networks . . . . . . . . . . . . . 4 | 2. SFC within Segment Routing Networks . . . . . . . . . . . . . 4 | |||
| 3. NSH-based SFC with SR-MPLS or SRv6 Transport Tunnel . . . . . 5 | 3. NSH-based SFC with SR-MPLS or SRv6 Transport Tunnel . . . . . 5 | |||
| 4. SR-based SFC with Integrated NSH Service Plane . . . . . . . 9 | 4. SR-based SFC with Integrated NSH Service Plane . . . . . . . 9 | |||
| 5. Packet Processing for SR-based SFC . . . . . . . . . . . . . 11 | 5. Packet Processing for SR-based SFC . . . . . . . . . . . . . 11 | |||
| skipping to change at page 4, line 40 ¶ | skipping to change at page 5, line 5 ¶ | |||
| for coordinated behaviors among SFs by means of supplying context | for coordinated behaviors among SFs by means of supplying context | |||
| information (a.k.a. metadata) should be considered when designing an | information (a.k.a. metadata) should be considered when designing an | |||
| SFC data plane solution. | SFC data plane solution. | |||
| While each scheme (i.e., NSH-based SFC and SR-based SFC) can work | While each scheme (i.e., NSH-based SFC and SR-based SFC) can work | |||
| independently, this document describes how the two can be used | independently, this document describes how the two can be used | |||
| together in concert and complement each other through two | together in concert and complement each other through two | |||
| representative application scenarios. Both application scenarios may | representative application scenarios. Both application scenarios may | |||
| be supported using either SR-MPLS or SRv6: | be supported using either SR-MPLS or SRv6: | |||
| o NSH-based SFC with SR-based transport plane: in this scenario SR- | * NSH-based SFC with SR-based transport plane: in this scenario SR- | |||
| MPLS or SRv6 provides the transport encapsulation between SFFs | MPLS or SRv6 provides the transport encapsulation between SFFs | |||
| while NSH is used to convey and trigger SFC policies. | while NSH is used to convey and trigger SFC policies. | |||
| o SR-based SFC with integrated NSH service plane: in this scenario | * SR-based SFC with integrated NSH service plane: in this scenario | |||
| each service hop of the SFC is represented as a segment of the SR | each service hop of the SFC is represented as a segment of the SR | |||
| segment-list. SR is thus responsible for steering traffic through | segment-list. SR is thus responsible for steering traffic through | |||
| the necessary SFFs as part of the segment routing path while NSH | the necessary SFFs as part of the segment routing path while NSH | |||
| is responsible for maintaining the service plane and holding the | is responsible for maintaining the service plane and holding the | |||
| SFC instance context (including associated metadata). | SFC instance context (including associated metadata). | |||
| It is of course possible to combine both of these two scenarios to | It is of course possible to combine both of these two scenarios to | |||
| support specific deployment requirements and use cases. | support specific deployment requirements and use cases. | |||
| A classifier MUST assign an NSH Service Path Identifier (SPI) per SR | A classifier MUST use an NSH Service Path Identifier (SPI) per SR | |||
| policy so that different traffic flows that use the same NSH Service | policy so that different traffic flows that use the same NSH Service | |||
| Function Path (SFP) but different SR policy can coexist on the same | Function Path (SFP) but different SR policy can coexist on the same | |||
| SFP without conflict during SFF processing. | SFP without conflict during SFF processing. | |||
| 3. NSH-based SFC with SR-MPLS or SRv6 Transport Tunnel | 3. NSH-based SFC with SR-MPLS or SRv6 Transport Tunnel | |||
| Because of the transport-independent nature of NSH-based service | Because of the transport-independent nature of NSH-based service | |||
| function chains, it is expected that the NSH has broad applicability | function chains, it is expected that the NSH has broad applicability | |||
| across different network domains (e.g., access, core). By way of | across different network domains (e.g., access, core). By way of | |||
| illustration the various SFs involved in a service function chain may | illustration the various SFs involved in a service function chain may | |||
| be available in a single data center, or spread throughout multiple | be available in a single data center, or spread throughout multiple | |||
| locations (e.g., data centers, different Points of Presense (POPs)), | locations (e.g., data centers, different Points of Presence (POPs)), | |||
| depending upon the network operator preference and/or availability of | depending upon the network operator preference and/or availability of | |||
| service resources. Regardless of where the SFs are deployed it is | service resources. Regardless of where the SFs are deployed it is | |||
| necessary to provide traffic steering through a set of SFFs, and when | 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. | NSH and SR are integrated, this is provided by SR-MPLS or SRv6. | |||
| The following three figures provide an example of an SFC established | The following three figures provide an example of an SFC established | |||
| flow F that has SF instances located in different data centers, DC1 | 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 | and DC2. For the purpose of illustration, let the SFC's NSH SPI be | |||
| 100 and the initial Service Index (SI) be 255. | 100 and the initial Service Index (SI) be 255. | |||
| skipping to change at page 6, line 33 ¶ | skipping to change at page 6, line 41 ¶ | |||
| |+------------+ +------+ +---------+ | | |+------------+ +------+ +---------+ | | |||
| | | | | | | |||
| | +------------+ +------------+ | | | +------------+ +------------+ | | |||
| | | N(100,255) | | N(100,254) | | | | | N(100,255) | | N(100,254) | | | |||
| | +------------+ +------------+ | | | +------------+ +------------+ | | |||
| | | F:Inner Pkt| | F:Inner Pkt| | | | | F:Inner Pkt| | F:Inner Pkt| | | |||
| | +------------+ +------------+ | | | +------------+ +------------+ | | |||
| | | | | | | |||
| +------------------------------------------------------------+ | +------------------------------------------------------------+ | |||
| Figure 1: SR for inter-DC SFC - Part 1 | Figure 1: SR for inter-DC SFC - Part 1 | |||
| Referring now to Figure 2, DC1-GW1 performs a lookup using the | Referring now to Figure 2, DC1-GW1 performs a lookup using the | |||
| information conveyed in the NSH which results in <next-hop: DC2-GW1, | information conveyed in the NSH which results in <next-hop: DC2-GW1, | |||
| encapsulation: SR>. The SR encapsulation, which may be SR-MPLS or | encapsulation: SR>. The SR encapsulation, which may be SR-MPLS or | |||
| SRv6, has the SR segment-list to forward the packet across the inter- | SRv6, has the SR segment-list to forward the packet across the inter- | |||
| DC network to DC2. | DC network to DC2. | |||
| +----------- Inter DC ----------------+ | +----------- Inter DC ----------------+ | |||
| (4) | (5) | | (4) | (5) | | |||
| +------+ ----> | +---------+ ----> +---------+ | | +------+ ----> | +---------+ ----> +---------+ | | |||
| skipping to change at page 7, line 22 ¶ | skipping to change at page 7, line 22 ¶ | |||
| | | | | | | |||
| | +------------+ | | | +------------+ | | |||
| | | S(DC2-GW1) | | | | | S(DC2-GW1) | | | |||
| | +------------+ | | | +------------+ | | |||
| | | N(100,254) | | | | | N(100,254) | | | |||
| | +------------+ | | | +------------+ | | |||
| | | F:Inner Pkt| | | | | F:Inner Pkt| | | |||
| | +------------+ | | | +------------+ | | |||
| +-------------------------------------+ | +-------------------------------------+ | |||
| Figure 2: SR for inter-DC SFC - Part 2 | Figure 2: SR for inter-DC SFC - Part 2 | |||
| When the packet arrives at DC2, as shown in Figure 3, the SR | 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 | encapsulation is removed and DC2-GW1 performs a lookup on the NSH | |||
| which results in next hop: SFF2. When SFF2 receives the packet, it | 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 | 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, | the packet to SF2. SF2 applies its service, decrements the SI by 1, | |||
| and returns the packet to SFF2. SFF2 therefore has <NSH: SPI 100, SI | and returns the packet to SFF2. SFF2 therefore has <NSH: SPI 100, SI | |||
| 253> when the packet comes back from SF2. SFF2 does a lookup on | 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 | <NSH: SPI 100, SI 253> which results in the end of the service | |||
| function chain. | function chain. | |||
| skipping to change at page 8, line 32 ¶ | skipping to change at page 8, line 32 ¶ | |||
| | | | | | | | | | | | | | | | | | | |||
| +---------+ | +----------+ +------+ | | +---------+ | +----------+ +------+ | | |||
| | | | | | | |||
| | +------------+ +------------+ | | | +------------+ +------------+ | | |||
| | | N(100,254) | | F:Inner Pkt| | | | | N(100,254) | | F:Inner Pkt| | | |||
| | +------------+ +------------+ | | | +------------+ +------------+ | | |||
| | | F:Inner Pkt| | | | | F:Inner Pkt| | | |||
| | +------------+ | | | +------------+ | | |||
| +---------------------------------------------------+ | +---------------------------------------------------+ | |||
| Figure 3: SR for inter-DC SFC - Part 3 | Figure 3: SR for inter-DC SFC - Part 3 | |||
| The benefits of this scheme are listed hereafter: | The benefits of this scheme are listed hereafter: | |||
| o The network operator is able to take advantage of the transport- | * The network operator is able to take advantage of the transport- | |||
| independent nature of the NSH encapsulation, while the service is | independent nature of the NSH encapsulation, while the service is | |||
| provisioned end-to-end. | provisioned end-to-end. | |||
| o The network operator is able to take advantage of the traffic | * The network operator is able to take advantage of the traffic | |||
| steering (traffic engineering) capability of SR where appropriate. | steering (traffic engineering) capability of SR where appropriate. | |||
| o Clear responsibility division and scope between NSH and SR. | * Clear responsibility division and scope between NSH and SR. | |||
| Note that this scenario is applicable to any case where multiple | Note that this scenario is applicable to any case where multiple | |||
| segments of a service function chain are distributed across multiple | segments of a service function chain are distributed across multiple | |||
| domains or where traffic-engineered paths are necessary between SFFs | domains or where traffic-engineered paths are necessary between SFFs | |||
| (strict forwarding paths for example). Further note that the above | (strict forwarding paths for example). Further note that the above | |||
| example can also be implemented using end-to-end segment routing | 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 | 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 | packets based on segment routing instructions and are not looking at | |||
| the NSH header for forwarding.) | the NSH header for forwarding.) | |||
| skipping to change at page 10, line 41 ¶ | skipping to change at page 10, line 50 ¶ | |||
| +------------+ +------------+ +------------+ | +------------+ +------------+ +------------+ | |||
| | S(SFF2) | | N(100,254) | | | S(SFF2) | | N(100,254) | | |||
| +------------+ +------------+ | +------------+ +------------+ | |||
| | S(SF2) | | F:Inner Pkt| | | S(SF2) | | F:Inner Pkt| | |||
| +------------+ +------------+ | +------------+ +------------+ | |||
| | N(100,255) | | | N(100,255) | | |||
| +------------+ | +------------+ | |||
| | F:Inner Pkt| | | F:Inner Pkt| | |||
| +------------+ | +------------+ | |||
| Figure 4: NSH over SR for SFC | Figure 4: NSH over SR for SFC | |||
| The benefits of this scheme include: | The benefits of this scheme include: | |||
| o It is economically sound for SF vendors to only support one | * It is economically sound for SF vendors to only support one | |||
| unified SFC solution. The SF is unaware of the SR. | unified SFC solution. The SF is unaware of the SR. | |||
| o It simplifies the SFF (i.e., the SR router) by nullifying the | * It simplifies the SFF (i.e., the SR router) by nullifying the | |||
| needs for re-classification and SR proxy. | needs for re-classification and SR proxy. | |||
| o SR is also used for forwarding purposes including between SFFs. | * SR is also used for forwarding purposes including between SFFs. | |||
| o It takes advantage of SR to eliminate the NSH forwarding state in | * It takes advantage of SR to eliminate the NSH forwarding state in | |||
| SFFs. This applies each time strict or loose SFPs are in use. | SFFs. This applies each time strict or loose SFPs are in use. | |||
| o It requires no interworking as would be the case if SR-MPLS based | * It requires no interworking as would be the case if SR-MPLS based | |||
| SFC and NSH-based SFC were deployed as independent mechanisms in | SFC and NSH-based SFC were deployed as independent mechanisms in | |||
| different parts of the network. | different parts of the network. | |||
| 5. Packet Processing for SR-based SFC | 5. Packet Processing for SR-based SFC | |||
| This section describes the End.NSH behavior (SRv6), Prefix SID | This section describes the End.NSH behavior (SRv6), Prefix SID | |||
| behavior (SR-MPLS), and NSH processing logic. | behavior (SR-MPLS), and NSH processing logic. | |||
| 5.1. SR-based SFC (SR-MPLS) Packet Processing | 5.1. SR-based SFC (SR-MPLS) Packet Processing | |||
| skipping to change at page 13, line 45 ¶ | skipping to change at page 14, line 4 ¶ | |||
| // // | // // | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| |Ver|O|U| TTL | Length |U|U|U|U|MD Type| Next Protocol | | |Ver|O|U| TTL | Length |U|U|U|U|MD Type| Next Protocol | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ N | |||
| | Service Path Identifier | Service Index | S | | Service Path Identifier | Service Index | S | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ H | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ H | |||
| | | | | | | |||
| ~ Variable-Length Context Headers (opt.) ~ | ~ Variable-Length Context Headers (opt.) ~ | |||
| | | | | | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Figure 6: NSH using SRv6 Transport | ||||
| Figure 6: NSH using SRv6 Transport | ||||
| Encapsulation of NSH following SRv6 is indicated by the IP protocol | Encapsulation of NSH following SRv6 is indicated by the IP protocol | |||
| number for NSH in the Next Header of the SRH. | number for NSH in the Next Header of the SRH. | |||
| 7. Security Considerations | 7. Security Considerations | |||
| Generic SFC-related security considerations are discussed in | Generic SFC-related security considerations are discussed in | |||
| [RFC7665]. | [RFC7665]. | |||
| NSH-specific security considerations are discussed in [RFC8300]. | NSH-specific security considerations are discussed in [RFC8300]. | |||
| skipping to change at page 17, line 49 ¶ | skipping to change at page 17, line 49 ¶ | |||
| Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header | Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header | |||
| (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, | (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, | |||
| <https://www.rfc-editor.org/info/rfc8754>. | <https://www.rfc-editor.org/info/rfc8754>. | |||
| 13.2. Informative References | 13.2. Informative References | |||
| [I-D.ietf-spring-sr-service-programming] | [I-D.ietf-spring-sr-service-programming] | |||
| Clad, F., Xu, X., Filsfils, C., Bernier, D., Li, C., | Clad, F., Xu, X., Filsfils, C., Bernier, D., Li, C., | |||
| Decraene, B., Ma, S., Yadlapalli, C., Henderickx, W., and | Decraene, B., Ma, S., Yadlapalli, C., Henderickx, W., and | |||
| S. Salsano, "Service Programming with Segment Routing", | S. Salsano, "Service Programming with Segment Routing", | |||
| draft-ietf-spring-sr-service-programming-05 (work in | Work in Progress, Internet-Draft, draft-ietf-spring-sr- | |||
| progress), September 2021. | service-programming-05, 10 September 2021, | |||
| <https://www.ietf.org/archive/id/draft-ietf-spring-sr- | ||||
| service-programming-05.txt>. | ||||
| [RFC7498] Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for | [RFC7498] Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for | |||
| Service Function Chaining", RFC 7498, | Service Function Chaining", RFC 7498, | |||
| DOI 10.17487/RFC7498, April 2015, | DOI 10.17487/RFC7498, April 2015, | |||
| <https://www.rfc-editor.org/info/rfc7498>. | <https://www.rfc-editor.org/info/rfc7498>. | |||
| [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function | [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function | |||
| Chaining (SFC) Architecture", RFC 7665, | Chaining (SFC) Architecture", RFC 7665, | |||
| DOI 10.17487/RFC7665, October 2015, | DOI 10.17487/RFC7665, October 2015, | |||
| <https://www.rfc-editor.org/info/rfc7665>. | <https://www.rfc-editor.org/info/rfc7665>. | |||
| skipping to change at page 18, line 26 ¶ | skipping to change at page 18, line 26 ¶ | |||
| "MPLS Transport Encapsulation for the Service Function | "MPLS Transport Encapsulation for the Service Function | |||
| Chaining (SFC) Network Service Header (NSH)", RFC 8596, | Chaining (SFC) Network Service Header (NSH)", RFC 8596, | |||
| DOI 10.17487/RFC8596, June 2019, | DOI 10.17487/RFC8596, June 2019, | |||
| <https://www.rfc-editor.org/info/rfc8596>. | <https://www.rfc-editor.org/info/rfc8596>. | |||
| Authors' Addresses | Authors' Addresses | |||
| James N Guichard (editor) | James N Guichard (editor) | |||
| Futurewei Technologies | Futurewei Technologies | |||
| 2330 Central Express Way | 2330 Central Express Way | |||
| Santa Clara | Santa Clara, | |||
| USA | United States of America | |||
| Email: james.n.guichard@futurewei.com | Email: james.n.guichard@futurewei.com | |||
| Jeff Tantsura (editor) | Jeff Tantsura (editor) | |||
| Microsoft | Microsoft | |||
| USA | United States of America | |||
| Email: jefftant.ietf@gmail.com | Email: jefftant.ietf@gmail.com | |||
| End of changes. 25 change blocks. | ||||
| 38 lines changed or deleted | 36 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||