< 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/