| < draft-li-spring-sr-e2e-ietf-network-slicing-02.txt | draft-li-spring-sr-e2e-ietf-network-slicing-03.txt > | |||
|---|---|---|---|---|
| Network Working Group Z. Li | Network Working Group Z. Li | |||
| Internet-Draft J. Dong | Internet-Draft J. Dong | |||
| Intended status: Standards Track Huawei Technologies | Intended status: Standards Track Huawei Technologies | |||
| Expires: 8 September 2022 R. Pang | Expires: 25 September 2022 R. Pang | |||
| China Unicom | China Unicom | |||
| Y. Zhu | Y. Zhu | |||
| China Telecom | China Telecom | |||
| 7 March 2022 | 24 March 2022 | |||
| Segment Routing for End-to-End IETF Network Slicing | Segment Routing for End-to-End IETF Network Slicing | |||
| draft-li-spring-sr-e2e-ietf-network-slicing-02 | draft-li-spring-sr-e2e-ietf-network-slicing-03 | |||
| Abstract | Abstract | |||
| Network slicing can be used to meet the connectivity and performance | Network slicing can be used to meet the connectivity and performance | |||
| requirement of different services or customers in a shared network. | requirement of different services or customers in a shared network. | |||
| An IETF network slice can be realized as enhanced VPNs (VPN+), which | An IETF network slice can be realized as enhanced VPNs (VPN+), which | |||
| is delivered by integrating the overlay VPN service with a Virtual | is delivered by integrating the overlay VPN service with a Virtual | |||
| Transport Network (VTN) as the underlay. An end-to-end IETF network | Transport Network (VTN) as the underlay. An end-to-end IETF network | |||
| slice may span multiple network domains. Within each domain, traffic | slice may span multiple network domains. Within each domain, traffic | |||
| of the end-to-end network slice service is mapped to a domain VTN. | of the end-to-end network slice service is mapped to a domain VTN. | |||
| In the context of IETF network slicing, a VTN can be instantiated as | In the context of IETF network slicing, a VTN can be instantiated as | |||
| a Network Resource Partition (NRP). | a Network Resource Partition (NRP). | |||
| When segment routing (SR) is used to build a multi-domain IETF | When segment routing (SR) is used to build a multi-domain IETF | |||
| network slices, information of the local network slices in each | network slices, information of the local network slices in each | |||
| domain can be specified using special SR binding segments called VTN | domain can be specified using special SR binding segments called NRP | |||
| binding segments (VTN BSID). The multi-domain IETF network slice can | binding segments (NRP BSID). The multi-domain IETF network slice can | |||
| be specified using a list of VTN BSIDs in the packet, each of which | be specified using a list of NRP BSIDs in the packet, each of which | |||
| can be used by the corresponding domain edge nodes to steer the | can be used by the corresponding domain edge nodes to steer the | |||
| traffic of end-to-end IETF network slice into the specific VTN in the | traffic of end-to-end IETF network slice into the specific NRP in the | |||
| local domain. | local domain. | |||
| This document describes the functionality of VTN binding segment and | This document describes the functionality of NRP binding segment and | |||
| its instantiation in SR-MPLS and SRv6. | its instantiation in SR-MPLS and SRv6. | |||
| Requirements Language | Requirements Language | |||
| The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
| "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | |||
| document are to be interpreted as described in RFC 2119 [RFC2119]. | document are to be interpreted as described in RFC 2119 [RFC2119]. | |||
| Status of This Memo | Status of This Memo | |||
| skipping to change at page 2, line 15 ¶ | skipping to change at page 2, line 15 ¶ | |||
| 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 8 September 2022. | This Internet-Draft will expire on 25 September 2022. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2022 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 (https://trustee.ietf.org/ | Provisions Relating to IETF Documents (https://trustee.ietf.org/ | |||
| license-info) in effect on the date of publication of this document. | license-info) in effect on the date of publication of this document. | |||
| Please review these documents carefully, as they describe your rights | Please review these documents carefully, as they describe your rights | |||
| and restrictions with respect to this document. Code Components | and restrictions with respect to this document. Code Components | |||
| extracted from this document must include Revised BSD License text as | extracted from this document must include Revised BSD License text as | |||
| described in Section 4.e of the Trust Legal Provisions and are | described in Section 4.e of the Trust Legal Provisions and are | |||
| provided without warranty as described in the Revised BSD License. | provided without warranty as described in the Revised BSD License. | |||
| Table of Contents | Table of Contents | |||
| 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
| 2. Segment Routing for IETF E2E Network Slicing . . . . . . . . 4 | 2. Segment Routing for IETF E2E Network Slicing . . . . . . . . 4 | |||
| 3. SRv6 VTN Binding Functions . . . . . . . . . . . . . . . . . 5 | 3. SRv6 NRP Binding Functions . . . . . . . . . . . . . . . . . 5 | |||
| 3.1. End.VTN.Encaps . . . . . . . . . . . . . . . . . . . . . 5 | 3.1. End.B6NRP.Encaps . . . . . . . . . . . . . . . . . . . . 5 | |||
| 3.2. End.BVTN.Encaps . . . . . . . . . . . . . . . . . . . . . 6 | 3.2. End.NRP.Encaps . . . . . . . . . . . . . . . . . . . . . 6 | |||
| 3.3. End.B6VTN.Encaps . . . . . . . . . . . . . . . . . . . . 8 | 3.3. End.BNRP.Encaps . . . . . . . . . . . . . . . . . . . . . 7 | |||
| 4. SR-MPLS VTN BSIDs . . . . . . . . . . . . . . . . . . . . . . 9 | 4. SR-MPLS NRP BSIDs . . . . . . . . . . . . . . . . . . . . . . 8 | |||
| 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 | 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 | |||
| 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 | 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 | |||
| 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 | 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 | |||
| 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 | 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 | |||
| 8.1. Normative References . . . . . . . . . . . . . . . . . . 10 | 8.1. Normative References . . . . . . . . . . . . . . . . . . 10 | |||
| 8.2. Informative References . . . . . . . . . . . . . . . . . 10 | 8.2. Informative References . . . . . . . . . . . . . . . . . 10 | |||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 | |||
| 1. Introduction | 1. Introduction | |||
| [I-D.ietf-teas-ietf-network-slices] introduces the concept and the | [I-D.ietf-teas-ietf-network-slices] introduces the concept and the | |||
| characteristics of IETF network slice, and describes a general | characteristics of IETF network slice, and describes a general | |||
| framework for IETF network slice management and operation.It also | framework for IETF network slice management and operation.It also | |||
| skipping to change at page 3, line 27 ¶ | skipping to change at page 3, line 27 ¶ | |||
| require above traditional VPNs. It also introduces the concept of | require above traditional VPNs. It also introduces the concept of | |||
| Virtual Transport Network (VTN). A Virtual Transport Network (VTN) | Virtual Transport Network (VTN). A Virtual Transport Network (VTN) | |||
| is a virtual underlay network which consists of a set of dedicated or | is a virtual underlay network which consists of a set of dedicated or | |||
| shared network resources allocated from the physical underlay | shared network resources allocated from the physical underlay | |||
| network, and is associated with a customized logical network | network, and is associated with a customized logical network | |||
| topology. VPN+ services can be delivered by mapping one or a group | topology. VPN+ services can be delivered by mapping one or a group | |||
| of overlay VPNs to the appropriate VTNs as the underlay, so as to | of overlay VPNs to the appropriate VTNs as the underlay, so as to | |||
| provide the network characteristics required by the customers. | provide the network characteristics required by the customers. | |||
| Enhanced VPN (VPN+) and VTN can be used for the realization of IETF | Enhanced VPN (VPN+) and VTN can be used for the realization of IETF | |||
| network slices. In the context of IETF network slicing, a VTN can be | network slices. In the context of IETF network slicing, a VTN can be | |||
| instantiated as an NRP. VTN and NRP are considered interchangable in | instantiated as an NRP. VTN and NRP are considered interchangable | |||
| this document. | terms in this document. | |||
| [I-D.dong-teas-nrp-scalability] describes the scalability | [I-D.dong-teas-nrp-scalability] describes the scalability | |||
| considerations in the control plane and data plane to enable NRPs and | considerations in the control plane and data plane to enable NRPs and | |||
| provide the suggestions to improve the scalability of NRP. In the | provide the suggestions to improve the scalability of NRP. In the | |||
| control plane, It proposes the approach of decoupling the topology | control plane, It proposes the approach of decoupling the topology | |||
| and resource attributes of NRP, so that multiple NRPs may share the | and resource attributes of NRP, so that multiple NRPs may share the | |||
| same topology and the result of topology based path computation. In | same topology and the result of topology based path computation. In | |||
| the data plane, it proposes to carry a dedicated NRP-ID of a network | the data plane, it proposes to carry a dedicated NRP-ID of a network | |||
| domain in the data packet to determine the set of resources reserved | domain in the data packet to determine the set of resources reserved | |||
| for the corresponding NRP. | for the corresponding NRP. | |||
| An IETF network slice may span multiple network domains. Within each | An IETF network slice may span multiple network domains. Within each | |||
| domain, traffic of the end-to-end network slice is mapped to a local | domain, traffic of the end-to-end network slice is mapped to a local | |||
| network slice. The NRP ID which identifies the NRP in the local | network slice. The NRP ID which identifies the NRP in the local | |||
| domain for the end-to-end network slice needs to be determined on the | domain for the end-to-end network slice needs to be determined on the | |||
| domain edge node. | domain edge node. | |||
| When segment routing (SR) is used to build a multi-domain IETF | When segment routing (SR) is used to build a multi-domain IETF | |||
| network slice, information of the local network slices in each domain | network slice, information of the local network slices in each domain | |||
| can be specified using special SR binding segments called VTN binding | can be specified using special SR binding segments called NRP binding | |||
| segments (VTN BSID). The multi-domain IETF network slice can be | segments (NRP BSID). The multi-domain IETF network slice can be | |||
| specified using a list of VTN BSIDs in the packet, each of which can | specified using a list of NRP BSIDs in the packet, each of which can | |||
| be used by the corresponding domain edge nodes to steer the traffic | be used by the corresponding domain edge nodes to steer the traffic | |||
| of end-to-end IETF network slice using the specific resource-aware | of end-to-end IETF network slice using the specific resource-aware | |||
| segments or VTN-ID of the local domain. | segments or NRP-ID of the local domain. | |||
| This document describes the functionality of the network slice | This document describes the functionality of the network slice | |||
| binding segment and its instantiation in SR-MPLS and SRv6. | binding segment and its instantiation in SR-MPLS and SRv6. | |||
| 2. Segment Routing for IETF E2E Network Slicing | 2. Segment Routing for IETF E2E Network Slicing | |||
| [I-D.dong-teas-nrp-scalability] describes the scalability | [I-D.dong-teas-nrp-scalability] describes the scalability | |||
| considerations in the control plane and data plane to create NRPs. | considerations in the control plane and data plane to create NRPs. | |||
| In data plane, it proposes to carry a dedicated NRP-ID in data packet | In data plane, it proposes to carry a dedicated NRP-ID in data packet | |||
| to determine the set of resources reserved for the corresponding NRP | to determine the set of resources reserved for the corresponding NRP | |||
| skipping to change at page 4, line 35 ¶ | skipping to change at page 4, line 35 ¶ | |||
| [I-D.li-teas-e2e-ietf-network-slicing] describes the framework of | [I-D.li-teas-e2e-ietf-network-slicing] describes the framework of | |||
| carrying network slice related identifiers in the data plane, each of | carrying network slice related identifiers in the data plane, each of | |||
| the network slice IDs may have a different network scope. It | the network slice IDs may have a different network scope. It | |||
| provides an approach of mapping the global NRP-ID to domain NRP-IDs | provides an approach of mapping the global NRP-ID to domain NRP-IDs | |||
| at the network domain border nodes. | at the network domain border nodes. | |||
| With Segment Routing, there are several optional approaches to | With Segment Routing, there are several optional approaches to | |||
| realize the mapping between the end-to-end network slice and the | realize the mapping between the end-to-end network slice and the | |||
| network slice constructs in the local domain. | network slice constructs in the local domain. | |||
| 1. The first approach is to use one type of VTN binding segment to | The first type of approaches are to use one type of NRP BSID to steer | |||
| specify the mapping of traffic to a list of resource-aware | traffic to an SR Policy associated with a local NRP. This is called | |||
| segments of a local VTN. | the NRP-TE BSID. There are some variants in terms of the detailed | |||
| behavior: | ||||
| 2. The second approach is to use one type of VTN binding segment to | * The first variant is to use one type of NRP BSID to specify the | |||
| determine a local VTN-ID, and instruct the encapsulation of the | mapping of traffic to a SR policy which consists of list of | |||
| local VTN-ID into the packet at the domain edge node. | resource-aware segments [I-D.ietf-spring-resource-aware-segments] | |||
| associated with a local NRP. | ||||
| 3. The third approach is to use one type of VTN binding segment to | * The second variant is to use one type of NRP BSID to specify the | |||
| specify the mapping of traffic to a local VTN, the local VTN-ID | mapping of traffic to a SR policy which is bound to a local NRP- | |||
| is specified in the associated fields by the ingress node, and is | ID. | |||
| encapsulated into the packet at the domain edge node. | ||||
| 4. The fourth approach is to use one type of VTN binding segment to | The second type of approaches is to use one type of NRP BSID to steer | |||
| specify the mapping of traffic to a SR policy which is bound to a | traffic to follow the shortest path within a local domain NRP. This | |||
| local VTN. | is called the NRP-BE BSID. There are some variants in terms of the | |||
| detailed behavior: | ||||
| The function of the first type of VTN binding segment is similar to | * The first variant is to use one type of NRP BSID to determine a | |||
| the function of the existing binding segment, the difference is it is | local NRP-ID, and instruct the encapsulation of the local NRP-ID | |||
| associated with a particular VTN. The other types of the VTN binding | into the packet at the domain edge node. | |||
| segments are different from the existing binding segment, and their | ||||
| instantiation in SR-MPLS and SRv6 are described in the following | ||||
| sections. | ||||
| 3. SRv6 VTN Binding Functions | * The second variant is to use one type of NRP BSID to specify the | |||
| mapping of traffic to a local NRP, the local NRP-ID is specified | ||||
| in the associated fields by the ingress node, and is encapsulated | ||||
| into the packet at the domain edge node. | ||||
| The behavior of the first type of NRP BSID is similar to the function | ||||
| of the existing SR BSID, the difference is it is associated with a | ||||
| particular NRP. The second type of the NRP BSID is different from | ||||
| the existing binding segment. The instantiation of the NRP BSIDs in | ||||
| SR-MPLS and SRv6 are described in the following sections. | ||||
| 3. SRv6 NRP Binding Functions | ||||
| [RFC8986] defines the SRv6 Network Programming concept and specifies | [RFC8986] defines the SRv6 Network Programming concept and specifies | |||
| the base set of SRv6 behaviors. The SRv6 End.B6.Encaps function is | the base set of SRv6 behaviors. The SRv6 End.B6.Encaps function is | |||
| defined to instantiate the Binding SID in SRv6, which can be used as | defined to instantiate the Binding SID in SRv6, which can be reused | |||
| the first type of VTN binding function to specify the mapping of | as one type of NRP-TE BSID to specify the mapping of traffic to a | |||
| traffic to a list of resource-aware SRv6 segments of a domain VTN. | list of resource-aware SRv6 segments of a domain NRP. | |||
| [I-D.dong-6man-enhanced-vpn-vtn-id] describes the mechanism of | [I-D.ietf-6man-enhanced-vpn-vtn-id] describes the mechanism of | |||
| carrying the VTN-ID of a network domain in the IPv6 Hop-by-Hop (HBH) | carrying the VTN-ID of a network domain in the IPv6 Hop-by-Hop (HBH) | |||
| extension header. For the type 2, 3, 4 of VTN binding segments | extension header. For the type 2, 3, 4 of NRP binding segments | |||
| described in section 2, three new SRv6 Binding functions are defined | described in section 2, three new SRv6 Binding functions are defined | |||
| in the following sections. | in the following sections. | |||
| 3.1. End.VTN.Encaps | 3.1. End.B6NRP.Encaps | |||
| A new SRv6 function called End.VTN.Encaps is defined. This is a | A new SRv6 function called End.B6NRP.Encaps: Endpoint bound to a SRv6 | |||
| variation of the End behavior. It instructs the endpoint node to | Policy in a NRP with IPv6 encapsulation is defined in this section. | |||
| determine the corresponding VTN-ID of the local domain based on the | This is a variation of the End behavior. It instructs the endpoint | |||
| mapping relationship between the End.VTN.Encaps SID and the VTNs | node to determine an SRv6 Policy in a specific NRP of the local | |||
| maintained on the endpoint. The VTN-ID is encapsulated in the VTN-ID | domain, and encapsulate the SID list of the SR Policy and the NRP-ID | |||
| option in the IPv6 HBH extension header. | in a new IPv6 header. | |||
| Any SID instance of this behavior is associated with one VTN-ID V and | Any SID instance of this behavior is associated with an SR Policy B, | |||
| a source address A. | a NRP-ID V and a source address A. | |||
| When node N receives a packet whose IPv6 DA is S, and S is a local | When node N receives a packet whose IPv6 DA is S, and S is a local | |||
| End.VTN.Encaps SID, N does the following: | End.B6NRP.Encaps SID, N does the following: | |||
| S01. When an SRH is processed { | S01. When an SRH is processed { | |||
| S02. If (Segments Left == 0) { | S02. If (Segments Left == 0) { | |||
| S03. Stop processing the SRH, and proceed to process the next | S03. Stop processing the SRH, and proceed to process the next | |||
| header in the packet, whose type is identified by | header in the packet, whose type is identified by | |||
| the Next Header field in the routing header. | the Next Header field in the routing header. | |||
| S04. } | S04. } | |||
| S05. If (IPv6 Hop Limit <= 1) { | S05. If (IPv6 Hop Limit <= 1) { | |||
| S06. Send an ICMP Time Exceeded message to the Source Address | S06. Send an ICMP Time Exceeded message to the Source Address | |||
| with Code 0 (Hop limit exceeded in transit), | with Code 0 (Hop limit exceeded in transit), | |||
| skipping to change at page 6, line 26 ¶ | skipping to change at page 6, line 26 ¶ | |||
| S08. max_LE = (Hdr Ext Len / 2) - 1 | S08. max_LE = (Hdr Ext Len / 2) - 1 | |||
| S09. If ((Last Entry > max_LE) or (Segments Left > Last Entry+1)) { | S09. If ((Last Entry > max_LE) or (Segments Left > Last Entry+1)) { | |||
| S10. Send an ICMP Parameter Problem to the Source Address | S10. Send an ICMP Parameter Problem to the Source Address | |||
| with Code 0 (Erroneous header field encountered) | with Code 0 (Erroneous header field encountered) | |||
| and Pointer set to the Segments Left field, | and Pointer set to the Segments Left field, | |||
| interrupt packet processing, and discard the packet. | interrupt packet processing, and discard the packet. | |||
| S11. } | S11. } | |||
| S12. Decrement IPv6 Hop Limit by 1 | S12. Decrement IPv6 Hop Limit by 1 | |||
| S13. Decrement Segments Left by 1 | S13. Decrement Segments Left by 1 | |||
| S14. Update IPv6 DA with Segment List [Segments Left] | S14. Update IPv6 DA with Segment List [Segments Left] | |||
| S15. Set the VTN-ID option to V in the HBH Ext header | S15. Push a new IPv6 header with its own SRH containing B, and | |||
| S16. Submit the packet to the egress IPv6 FIB lookup for | the VTN-ID in VTN option set to V in the HBH Ext header | |||
| S16. Set the outer IPv6 SA to A | ||||
| S17. Set the outer IPv6 DA to the first SID of B | ||||
| S18. Set the outer Payload Length, Traffic Class, Flow Label, | ||||
| Hop Limit, and Next Header fields | ||||
| S19. Submit the packet to the egress IPv6 FIB lookup for | ||||
| transmission to the new destination | transmission to the new destination | |||
| S17. } | S20. } | |||
| 3.2. End.BVTN.Encaps | 3.2. End.NRP.Encaps | |||
| A new SRv6 function called End.BVTN.Encaps: Endpoint bound to a VTN | A new SRv6 function called End.NRP.Encaps is defined. This is a | |||
| with IPv6 encapsulation is defined. This is a variation of the End | variation of the End behavior. It instructs the endpoint node to | |||
| behavior. For the End.BVTN SID, its corresponding VTN-ID should be | determine the corresponding NRP-ID of the local domain based on the | |||
| specified and encapsulated by the ingress node of SRv6 Path. It | mapping relationship between the End.NRP.Encaps SID and the NRPs | |||
| instructs the endpoint node to obtain the corresponding VTN-ID from | maintained on the endpoint. The NRP-ID is encapsulated in the VTN | |||
| the SRH, and encapsulate it in the VTN-ID option in the IPv6 HBH | option in the IPv6 HBH extension header. | |||
| extension header. Through the End.BVTN.Encaps, the ingress node can | ||||
| flexibly specify the local VTN the packet traverses in the network. | ||||
| Any SID instance of this behavior is associated with one VTN-ID V and | Any SID instance of this behavior is associated with one NRP-ID V and | |||
| a source address A. | a source address A. | |||
| There can be several options to carry the local VTN-ID corresponding | ||||
| to the End.BVTN.Encaps function: | ||||
| 1. The VTN-ID is carried in the argument field of the | ||||
| End.BVTN.Encaps SID. | ||||
| 2. The VTN-ID is carried in the SRH TLV field. | ||||
| 3. The VTN-ID is carried in the next SID following the | ||||
| End.BVTN.Encaps SID in the SID list. | ||||
| Editor's note: In the current version of this document, option 1 is | ||||
| preferred, in which the local VTN-ID is carried in the argument field | ||||
| of the SRv6 SID. | ||||
| When an ingress node of an SR path encapsulates the End.BVTN.Encaps | ||||
| SID into the packet, it SHOULD put the VTN-ID which the packet is | ||||
| expected to be mapped to into the argument part of the SID. | ||||
| When node N receives a packet whose IPv6 DA is S, and S is a local | When node N receives a packet whose IPv6 DA is S, and S is a local | |||
| End.BVTN.Encaps SID, N does the following: | End.NRP.Encaps SID, N does the following: | |||
| S01. When an SRH is processed { | S01. When an SRH is processed { | |||
| S02. If (Segments Left == 0) { | S02. If (Segments Left == 0) { | |||
| S03. Stop processing the SRH, and proceed to process the next | S03. Stop processing the SRH, and proceed to process the next | |||
| header in the packet, whose type is identified by | header in the packet, whose type is identified by | |||
| the Next Header field in the routing header. | the Next Header field in the routing header. | |||
| S04. } | S04. } | |||
| S05. If (IPv6 Hop Limit <= 1) { | S05. If (IPv6 Hop Limit <= 1) { | |||
| S06. Send an ICMP Time Exceeded message to the Source Address | S06. Send an ICMP Time Exceeded message to the Source Address | |||
| with Code 0 (Hop limit exceeded in transit), | with Code 0 (Hop limit exceeded in transit), | |||
| interrupt packet processing, and discard the packet. | interrupt packet processing, and discard the packet. | |||
| S07. } | S07. } | |||
| S08. max_LE = (Hdr Ext Len / 2) - 1 | S08. max_LE = (Hdr Ext Len / 2) - 1 | |||
| S09. If ((Last Entry > max_LE) or (Segments Left > Last Entry+1)) { | S09. If ((Last Entry > max_LE) or (Segments Left > Last Entry+1)) { | |||
| S10. Send an ICMP Parameter Problem to the Source Address | S10. Send an ICMP Parameter Problem to the Source Address | |||
| with Code 0 (Erroneous header field encountered) | with Code 0 (Erroneous header field encountered) | |||
| and Pointer set to the Segments Left field, | and Pointer set to the Segments Left field, | |||
| interrupt packet processing, and discard the packet. | interrupt packet processing, and discard the packet. | |||
| S11. } | S11. } | |||
| S12. Obtain the VTN-ID V from the argument part of the IPv6 DA | S12. Decrement IPv6 Hop Limit by 1 | |||
| S13. Decrement IPv6 Hop Limit by 1 | S13. Decrement Segments Left by 1 | |||
| S14. Decrement Segments Left by 1 | S14. Update IPv6 DA with Segment List [Segments Left] | |||
| S15. Update IPv6 DA with Segment List [Segments Left] | S15. Set the VTN-ID in VTN option to V in the HBH Ext header | |||
| S16. Set the VTN-ID option to V in the HBH Ext header | S16. Submit the packet to the egress IPv6 FIB lookup for | |||
| S17. Submit the packet to the egress IPv6 FIB lookup for | ||||
| transmission to the new destination | transmission to the new destination | |||
| S18. } | S17. } | |||
| 3.3. End.B6VTN.Encaps | 3.3. End.BNRP.Encaps | |||
| A new SRv6 function called End.B6VTN.Encaps: Endpoint bound to a SRv6 | A new SRv6 function called End.BNRP.Encaps: Endpoint bound to a NRP | |||
| Policy in a VTN with IPv6 encapsulation is defined in this section. | with IPv6 encapsulation is defined. This is a variation of the End | |||
| This is a variation of the End behavior. It instructs the endpoint | behavior. For the End.BNRP SID, its corresponding NRP-ID should be | |||
| node to determine an SRv6 Policy in a specific VTN of the local | specified and encapsulated by the ingress node of SRv6 Path. It | |||
| domain, and encapsulate the SID list of the SR Policy and the VTN-ID | instructs the endpoint node to obtain the corresponding NRP-ID from | |||
| in a new IPv6 header. | the SRH, and encapsulate it in the VTN option in the IPv6 HBH | |||
| extension header. Through the End.BNRP.Encaps, the ingress node can | ||||
| flexibly specify the local NRP the packet traverses in the network. | ||||
| Any SID instance of this behavior is associated with an SR Policy B, | Any SID instance of this behavior is associated with one NRP-ID V and | |||
| a VTN-ID V and a source address A. | a source address A. | |||
| There can be several options to carry the local NRP-ID corresponding | ||||
| to the End.BNRP.Encaps function: | ||||
| 1. The NRP-ID is carried in the argument field of the | ||||
| End.BNRP.Encaps SID. | ||||
| 2. The NRP-ID is carried in the SRH TLV field. | ||||
| 3. The NRP-ID is carried in the next SID following the | ||||
| End.BNRP.Encaps SID in the SID list. | ||||
| Editor's note: In the current version of this document, option 1 is | ||||
| preferred, in which the local NRP-ID is carried in the argument field | ||||
| of the SRv6 SID. | ||||
| When an ingress node of an SR path encapsulates the End.BNRP.Encaps | ||||
| SID into the packet, it SHOULD put the NRP-ID which the packet is | ||||
| expected to be mapped to into the argument part of the SID. | ||||
| When node N receives a packet whose IPv6 DA is S, and S is a local | When node N receives a packet whose IPv6 DA is S, and S is a local | |||
| End.B6VTN.Encaps SID, N does the following: | End.BNRP.Encaps SID, N does the following: | |||
| S01. When an SRH is processed { | S01. When an SRH is processed { | |||
| S02. If (Segments Left == 0) { | S02. If (Segments Left == 0) { | |||
| S03. Stop processing the SRH, and proceed to process the next | S03. Stop processing the SRH, and proceed to process the next | |||
| header in the packet, whose type is identified by | header in the packet, whose type is identified by | |||
| the Next Header field in the routing header. | the Next Header field in the routing header. | |||
| S04. } | S04. } | |||
| S05. If (IPv6 Hop Limit <= 1) { | S05. If (IPv6 Hop Limit <= 1) { | |||
| S06. Send an ICMP Time Exceeded message to the Source Address | S06. Send an ICMP Time Exceeded message to the Source Address | |||
| with Code 0 (Hop limit exceeded in transit), | with Code 0 (Hop limit exceeded in transit), | |||
| interrupt packet processing, and discard the packet. | interrupt packet processing, and discard the packet. | |||
| S07. } | S07. } | |||
| S08. max_LE = (Hdr Ext Len / 2) - 1 | S08. max_LE = (Hdr Ext Len / 2) - 1 | |||
| S09. If ((Last Entry > max_LE) or (Segments Left > Last Entry+1)) { | S09. If ((Last Entry > max_LE) or (Segments Left > Last Entry+1)) { | |||
| S10. Send an ICMP Parameter Problem to the Source Address | S10. Send an ICMP Parameter Problem to the Source Address | |||
| with Code 0 (Erroneous header field encountered) | with Code 0 (Erroneous header field encountered) | |||
| and Pointer set to the Segments Left field, | and Pointer set to the Segments Left field, | |||
| interrupt packet processing, and discard the packet. | interrupt packet processing, and discard the packet. | |||
| S11. } | S11. } | |||
| S12. Decrement IPv6 Hop Limit by 1 | S12. Obtain the NRP-ID V from the argument part of the IPv6 DA | |||
| S13. Decrement Segments Left by 1 | S13. Decrement IPv6 Hop Limit by 1 | |||
| S14. Update IPv6 DA with Segment List [Segments Left] | S14. Decrement Segments Left by 1 | |||
| S15. Push a new IPv6 header with its own SRH containing B, and | S15. Update IPv6 DA with Segment List [Segments Left] | |||
| the VTN-ID option set to V in the HBH Ext header | S16. Set the VTN-ID in VTN option to V in the HBH Ext header | |||
| S16. Set the outer IPv6 SA to A | S17. Submit the packet to the egress IPv6 FIB lookup for | |||
| S17. Set the outer IPv6 DA to the first SID of B | ||||
| S18. Set the outer Payload Length, Traffic Class, Flow Label, | ||||
| Hop Limit, and Next Header fields | ||||
| S19. Submit the packet to the egress IPv6 FIB lookup for | ||||
| transmission to the new destination | transmission to the new destination | |||
| S20. } | S18. } | |||
| 4. SR-MPLS VTN BSIDs | 4. SR-MPLS NRP BSIDs | |||
| [I-D.li-mpls-enhanced-vpn-vtn-id] describes the mechanism of carrying | [I-D.li-mpls-enhanced-vpn-vtn-id] describes the mechanism of carrying | |||
| the VTN-ID of a network domain in the MPLS extension header. | the VTN-ID of a network domain in the MPLS extension header. | |||
| With SR-MPLS data plane, VTN binding SIDs can be allocated by a | With SR-MPLS data plane, NRP BSIDs can be allocated by a domain edge | |||
| domain edge node for the three types of VTN binding behaviors | node for the three types of NRP binding behaviors described in | |||
| described in section 2. | section 2. | |||
| For the first type of VTN binding segment, a BSID is bound to a list | For the first type of NRP BSID, a BSID can be bound to a list of | |||
| of resource-aware segments of a local VTN. When a node receives a | resource-aware segments of a local NRP. When a node receives a | |||
| packet with a locally assigned VTN BSID, it determines the | packet with a locally assigned NRP BSID, it determines the | |||
| corresponding SID list which consists of the resource-aware segments | corresponding SID list which consists of the resource-aware segments | |||
| of a local VTN, and encapsulates the SID list to the MPLS label | of a local NRP, and encapsulates the SID list to the MPLS label | |||
| stack. | stack. | |||
| For the second type of VTN binding segment, a VTN BSID is bound to a | For another variant of the first type NRP BSID, a NRP BSID is bound | |||
| VTN of the local network domain. When a node receives a packet with | to a SR Policy and a local NRP-ID. When a node receives a packet | |||
| a locally assigned VTN BSID, it determines the corresponding local | with a locally assigned NRP BSID, it determines the corresponding SID | |||
| VTN-ID based on the mapping relationship between the VTN BSID and the | list and the local NRP-ID, and encaps the packet with the SID list | |||
| VTN-ID, and encapsulates the packet with an MPLS VTN extension header | and an MPLS VTN extension header which carries the local NRP-ID. | |||
| which carries the local VTN-ID option. Note this requires to assign | Note this requires to assign a NRP BSID for each SR policy in each | |||
| a VTN BSID for each VTN. | NRP the node participates in. | |||
| For the third type of VTN binding segment, a VTN BSID is bound to a | For the second type of NRP BSID, a NRP BSID is bound to the shortest | |||
| VTN of the local network domain, the VTN-ID is specified and | path in an NRP of the local network domain. When a node receives a | |||
| encapsulated by the ingress node in the MPLS VTN extension header. | packet with a locally assigned NRP BSID, it determines the | |||
| When a node receives a packet with a locally assigned VTN BSID, it | corresponding local NRP-ID based on the mapping relationship between | |||
| obtains the corresponding local VTN-ID from the VTN-ID list in the | the NRP BSID and the NRP-ID, and encapsulates the packet with an MPLS | |||
| VTN extension header, and update the local VTN-ID option in the VTN | VTN extension header which carries the local NRP-ID. Note this | |||
| extension header with the obtained VTN-ID. | requires to assign a NRP BSID for each local NRP. | |||
| For the fourth type of VTN binding behavior, a VTN BSID is bound to a | For a variant of the second type NRP BSID, a NRP BSID is bound to the | |||
| SR Policy in a VTN of the local network domain. When a node receives | shortest path in an NRP of the local network domain, the NRP-ID is | |||
| a packet with a locally assigned VTN BSID, it determines the | specified and encapsulated by the ingress node in the MPLS VTN | |||
| corresponding SID list and the local VTN-ID, and encaps the packet | extension header. When a node receives a packet with a locally | |||
| with the SID list and an MPLS VTN extension header which carries the | assigned NRP BSID, it obtains the corresponding local NRP-ID from the | |||
| local VTN-ID option. Note this requires to assign a VTN BSID for | NRP-ID list in the VTN extension header, and update the local NRP-ID | |||
| each SR policy in each VTN the node participates in. | in the VTN extension header with the obtained NRP-ID. | |||
| 5. IANA Considerations | 5. IANA Considerations | |||
| TBD | TBD | |||
| 6. Security Considerations | 6. Security Considerations | |||
| TBD | TBD | |||
| 7. Acknowledgements | 7. Acknowledgements | |||
| skipping to change at page 10, line 18 ¶ | skipping to change at page 10, line 13 ¶ | |||
| comments. | comments. | |||
| 8. References | 8. References | |||
| 8.1. Normative References | 8.1. Normative References | |||
| [I-D.ietf-teas-enhanced-vpn] | [I-D.ietf-teas-enhanced-vpn] | |||
| Dong, J., Bryant, S., Li, Z., Miyasaka, T., and Y. Lee, "A | Dong, J., Bryant, S., Li, Z., Miyasaka, T., and Y. Lee, "A | |||
| Framework for Enhanced Virtual Private Network (VPN+) | Framework for Enhanced Virtual Private Network (VPN+) | |||
| Services", Work in Progress, Internet-Draft, draft-ietf- | Services", Work in Progress, Internet-Draft, draft-ietf- | |||
| teas-enhanced-vpn-09, 25 October 2021, | teas-enhanced-vpn-10, 6 March 2022, | |||
| <https://www.ietf.org/archive/id/draft-ietf-teas-enhanced- | <https://www.ietf.org/archive/id/draft-ietf-teas-enhanced- | |||
| vpn-09.txt>. | vpn-10.txt>. | |||
| [I-D.ietf-teas-ietf-network-slices] | [I-D.ietf-teas-ietf-network-slices] | |||
| Farrel, A., Drake, J., Rokui, R., Homma, S., Makhijani, | Farrel, A., Drake, J., Rokui, R., Homma, S., Makhijani, | |||
| K., Contreras, L. M., and J. Tantsura, "Framework for IETF | K., Contreras, L. M., and J. Tantsura, "Framework for IETF | |||
| Network Slices", Work in Progress, Internet-Draft, draft- | Network Slices", Work in Progress, Internet-Draft, draft- | |||
| ietf-teas-ietf-network-slices-08, 6 March 2022, | ietf-teas-ietf-network-slices-08, 6 March 2022, | |||
| <https://www.ietf.org/archive/id/draft-ietf-teas-ietf- | <https://www.ietf.org/archive/id/draft-ietf-teas-ietf- | |||
| network-slices-08.txt>. | network-slices-08.txt>. | |||
| [I-D.li-teas-e2e-ietf-network-slicing] | [I-D.li-teas-e2e-ietf-network-slicing] | |||
| Li, Z., Dong, J., Pang, R., and Y. Zhu, "Framework for | Li, Z., Dong, J., Pang, R., and Y. Zhu, "Framework for | |||
| End-to-End IETF Network Slicing", Work in Progress, | End-to-End IETF Network Slicing", Work in Progress, | |||
| Internet-Draft, draft-li-teas-e2e-ietf-network-slicing-01, | Internet-Draft, draft-li-teas-e2e-ietf-network-slicing-02, | |||
| 25 October 2021, <https://www.ietf.org/archive/id/draft- | 7 March 2022, <https://www.ietf.org/archive/id/draft-li- | |||
| li-teas-e2e-ietf-network-slicing-01.txt>. | teas-e2e-ietf-network-slicing-02.txt>. | |||
| [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
| Requirement Levels", BCP 14, RFC 2119, | Requirement Levels", BCP 14, RFC 2119, | |||
| DOI 10.17487/RFC2119, March 1997, | DOI 10.17487/RFC2119, March 1997, | |||
| <https://www.rfc-editor.org/info/rfc2119>. | <https://www.rfc-editor.org/info/rfc2119>. | |||
| [RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, | [RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, | |||
| D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 | D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 | |||
| (SRv6) Network Programming", RFC 8986, | (SRv6) Network Programming", RFC 8986, | |||
| DOI 10.17487/RFC8986, February 2021, | DOI 10.17487/RFC8986, February 2021, | |||
| <https://www.rfc-editor.org/info/rfc8986>. | <https://www.rfc-editor.org/info/rfc8986>. | |||
| 8.2. Informative References | 8.2. Informative References | |||
| [I-D.dong-6man-enhanced-vpn-vtn-id] | ||||
| Dong, J., Li, Z., Xie, C., Ma, C., and G. Mishra, | ||||
| "Carrying Virtual Transport Network (VTN) Identifier in | ||||
| IPv6 Extension Header", Work in Progress, Internet-Draft, | ||||
| draft-dong-6man-enhanced-vpn-vtn-id-06, 24 October 2021, | ||||
| <https://www.ietf.org/archive/id/draft-dong-6man-enhanced- | ||||
| vpn-vtn-id-06.txt>. | ||||
| [I-D.dong-teas-nrp-scalability] | [I-D.dong-teas-nrp-scalability] | |||
| Dong, J., Li, Z., Gong, L., Yang, G., Guichard, J. N., | Dong, J., Li, Z., Gong, L., Yang, G., Guichard, J. N., | |||
| Mishra, G., Qin, F., Saad, T., and V. P. Beeram, | Mishra, G., Qin, F., Saad, T., and V. P. Beeram, | |||
| "Scalability Considerations for Network Resource | "Scalability Considerations for Network Resource | |||
| Partition", Work in Progress, Internet-Draft, draft-dong- | Partition", Work in Progress, Internet-Draft, draft-dong- | |||
| teas-nrp-scalability-01, 7 February 2022, | teas-nrp-scalability-01, 7 February 2022, | |||
| <https://www.ietf.org/archive/id/draft-dong-teas-nrp- | <https://www.ietf.org/archive/id/draft-dong-teas-nrp- | |||
| scalability-01.txt>. | scalability-01.txt>. | |||
| [I-D.ietf-6man-enhanced-vpn-vtn-id] | ||||
| Dong, J., Li, Z., Xie, C., Ma, C., and G. Mishra, | ||||
| "Carrying Virtual Transport Network (VTN) Identifier in | ||||
| IPv6 Extension Header", Work in Progress, Internet-Draft, | ||||
| draft-ietf-6man-enhanced-vpn-vtn-id-00, 5 March 2022, | ||||
| <https://www.ietf.org/archive/id/draft-ietf-6man-enhanced- | ||||
| vpn-vtn-id-00.txt>. | ||||
| [I-D.ietf-spring-resource-aware-segments] | [I-D.ietf-spring-resource-aware-segments] | |||
| Dong, J., Bryant, S., Miyasaka, T., Zhu, Y., Qin, F., Li, | Dong, J., Bryant, S., Miyasaka, T., Zhu, Y., Qin, F., Li, | |||
| Z., and F. Clad, "Introducing Resource Awareness to SR | Z., and F. Clad, "Introducing Resource Awareness to SR | |||
| Segments", Work in Progress, Internet-Draft, draft-ietf- | Segments", Work in Progress, Internet-Draft, draft-ietf- | |||
| spring-resource-aware-segments-03, 12 July 2021, | spring-resource-aware-segments-04, 5 March 2022, | |||
| <https://www.ietf.org/archive/id/draft-ietf-spring- | <https://www.ietf.org/archive/id/draft-ietf-spring- | |||
| resource-aware-segments-03.txt>. | resource-aware-segments-04.txt>. | |||
| [I-D.ietf-spring-sr-for-enhanced-vpn] | [I-D.ietf-spring-sr-for-enhanced-vpn] | |||
| Dong, J., Bryant, S., Miyasaka, T., Zhu, Y., Qin, F., Li, | Dong, J., Bryant, S., Miyasaka, T., Zhu, Y., Qin, F., Li, | |||
| Z., and F. Clad, "Segment Routing based Virtual Transport | Z., and F. Clad, "Segment Routing based Virtual Transport | |||
| Network (VTN) for Enhanced VPN", Work in Progress, | Network (VTN) for Enhanced VPN", Work in Progress, | |||
| Internet-Draft, draft-ietf-spring-sr-for-enhanced-vpn-01, | Internet-Draft, draft-ietf-spring-sr-for-enhanced-vpn-02, | |||
| 12 July 2021, <https://www.ietf.org/archive/id/draft-ietf- | 5 March 2022, <https://www.ietf.org/archive/id/draft-ietf- | |||
| spring-sr-for-enhanced-vpn-01.txt>. | spring-sr-for-enhanced-vpn-02.txt>. | |||
| [I-D.li-mpls-enhanced-vpn-vtn-id] | [I-D.li-mpls-enhanced-vpn-vtn-id] | |||
| Li, Z. and J. Dong, "Carrying Virtual Transport Network | Li, Z. and J. Dong, "Carrying Virtual Transport Network | |||
| Identifier in MPLS Packet", Work in Progress, Internet- | Identifier in MPLS Packet", Work in Progress, Internet- | |||
| Draft, draft-li-mpls-enhanced-vpn-vtn-id-01, 14 April | Draft, draft-li-mpls-enhanced-vpn-vtn-id-02, 7 March 2022, | |||
| 2021, <https://www.ietf.org/archive/id/draft-li-mpls- | <https://www.ietf.org/archive/id/draft-li-mpls-enhanced- | |||
| enhanced-vpn-vtn-id-01.txt>. | vpn-vtn-id-02.txt>. | |||
| Authors' Addresses | Authors' Addresses | |||
| Zhenbin Li | Zhenbin Li | |||
| Huawei Technologies | Huawei Technologies | |||
| Huawei Campus, No. 156 Beiqing Road | Huawei Campus, No. 156 Beiqing Road | |||
| Beijing | Beijing | |||
| 100095 | 100095 | |||
| China | China | |||
| Email: lizhenbin@huawei.com | Email: lizhenbin@huawei.com | |||
| End of changes. 56 change blocks. | ||||
| 167 lines changed or deleted | 177 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/ | ||||