Subject: [Teas] A draft on the framework for end-to-end IETF network slicing

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Thu, 13 May 2021 02:53:37 +0000

Hi WG,

Recently we published a draft on the framework for end-to-end IETF network slicing: https://datatracker.ietf.org/doc/html/draft-li-teas-e2e-ietf-network-slicing

This document describes the scenarios of end-to-end network slicing, and the framework of network slice mapping between different network segments and network domains. Multiple network slice related identifiers are defined to covers different network scopes.

The network slice related identifiers of different network scopes can be instantiated with MPLS or IPv6 data plane, which are further described in the following drafts:

https://datatracker.ietf.org/doc/draft-li-mpls-e2e-ietf-network-slicing/

https://datatracker.ietf.org/doc/html/draft-li-6man-e2e-ietf-network-slicing

https://datatracker.ietf.org/doc/html/draft-li-spring-sr-e2e-ietf-network-slicing

Your review and comments are welcome. (Comments on the specific data plane draft can go to the corresponding WG mail list).

Best regards,
Jie

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 13 May 2021 00:48:31 -0400

It is not at all clear that any identifiers are needed inside the 
various networks, and specifically it is not clear that an internal 
identifier for the end-to-end network slice is needed at the level of 
the IETF network slice as is being defined by teas.  Since path 
selection, QoS parameter handling, and resource allocation needs to be 
handled in aggregate, it seems likely that no such identifier is needed.

Yours,
Joel

On 5/12/2021 10:53 PM, Dongjie (Jimmy) wrote:
> Hi WG,
> 
> Recently we published a draft on the framework for end-to-end IETF 
> network slicing: 
> https://datatracker.ietf.org/doc/html/draft-li-teas-e2e-ietf-network-slicing 
> <https://datatracker.ietf.org/doc/html/draft-li-teas-e2e-ietf-network-slicing>
> 
> This document describes the scenarios of end-to-end network slicing, and 
> the framework of network slice mapping between different network 
> segments and network domains. Multiple network slice related identifiers 
> are defined to covers different network scopes.
> 
> The network slice related identifiers of different network scopes can be 
> instantiated with MPLS or IPv6 data plane, which are further described 
> in the following drafts:
> 
> <https://datatracker.ietf.org/doc/draft-li-mpls-e2e-ietf-network-slicing/>
> 
> <https://datatracker.ietf.org/doc/html/draft-li-6man-e2e-ietf-network-slicing>
> 
> <https://datatracker.ietf.org/doc/html/draft-li-spring-sr-e2e-ietf-network-slicing>
> 
> Your review and comments are welcome. (Comments on the specific data 
> plane draft can go to the corresponding WG mail list).
> 
> Best regards,
> 
> Jie
> 
> 
> _______________________________________________
> Teas mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/teas
>

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Fri, 14 May 2021 03:54:52 +0000

Hi Joel, 

Thanks for your comments.

The requirement of carrying network slice related identifier in the data packet was described in draft-dong-teas-enhanced-vpn-vtn-scalability and other relevant documents. Currently there are several proposals about the encapsulation of network slice related identifiers. Based on that, this document further describes the considerations about the multi-domain IETF network slice scenario, and the interaction with other technical domains for 5G end-to-end network slicing. 

You are right that the path selection, resource allocation and traffic handling would be based on the identifiers internal to a network domain. As described in this draft, the end-to-end network slice identifier may be used for traffic monitoring at the end-to-end network slice granularity.

Best regards,
Jie

> -----Original Message-----
> From: Joel M. Halpern [mailto:[email-masked]]
> Sent: Thursday, May 13, 2021 12:49 PM
> To: Dongjie (Jimmy) <[email-masked]>; [email-masked]
> Subject: Re: [Teas] A draft on the framework for end-to-end IETF network
> slicing
> 
> It is not at all clear that any identifiers are needed inside the various networks,
> and specifically it is not clear that an internal identifier for the end-to-end
> network slice is needed at the level of the IETF network slice as is being defined
> by teas.  Since path selection, QoS parameter handling, and resource
> allocation needs to be handled in aggregate, it seems likely that no such
> identifier is needed.
> 
> Yours,
> Joel
> 
> > This document describes the scenarios of end-to-end network slicing,
> > and the framework of network slice mapping between different network
> > segments and network domains. Multiple network slice related
> > identifiers are defined to covers different network scopes.
> >
> > The network slice related identifiers of different network scopes can
> > be instantiated with MPLS or IPv6 data plane, which are further
> > described in the following drafts:
> >

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 14 May 2021 00:05:27 -0400

Do you mean traffic monitoring at the domain edges?  Or inside the 
domain?  If at the domain edges, then any mapping technology can also be 
used for monitoring.
If inside the domain, this places a significant disaggregated statistics 
collection load on the internals of the network.
Edge-to-Edge monitoring by the consumer (client? customer?) of the 
component is clealry useful.  But does not requrie such identification. 
  Nor does it requrie internal disaggregated state reporting.
the internals presumably will monitor the aggregated behavior.  Which 
again does not require the identification.

Yours,
Joel

---

From: Igor Bryskin <[email-masked]>
Date: Fri, 14 May 2021 16:45:51 +0000 (UTC)

Hi Joel,
Suppose a TE service/tunnel is requested and set up connecting access points A and B across the network. Can I consider such a tunnel as a trivial IETF network slice? If not, why? If yes. why not to reduce, generally speaking, the  IETF network slice problem to the problem of p2p and p2mp TE tunnels interconnecting IETF slice end points? For example, we have spent a lot of time discussing e2e multi-domain TE tunnels and how their segments in each domain are identified, associated, etc. Is it necessary or useful in your opinion to repeat the discussion in the context of slicing?

Thanks,Igor

    On Friday, May 14, 2021, 12:05:44 AM EDT, Joel M. Halpern <[email-masked]> wrote:  

Yours,
Joel

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 14 May 2021 12:50:17 -0400

The answer seems to depend upon ones perspective.  While I have an 
opinion (maybe even several) about where our IETF network slice 
(service or interface) definitions will end up, I do not speak for the 
community.  Until we have arrived, I will treat these things as distinct.

On 5/14/2021 12:45 PM, Igor Bryskin wrote:
> Hi Joel,
> 
> Suppose a TE service/tunnel is requested and set up connecting access 
> points A and B across the network. Can I consider such a tunnel as a 
> trivial IETF network slice? If not, why? If yes. why not to reduce, 
> generally speaking, the  IETF network slice problem to the problem of 
> p2p and p2mp TE tunnels interconnecting IETF slice end points? For 
> example, we have spent a lot of time discussing e2e multi-domain TE 
> tunnels and how their segments in each domain are identified, 
> associated, etc. Is it necessary or useful in your opinion to repeat the 
> discussion in the context of slicing?
> 
> 
> Thanks,
> Igor
> 
> 
>  > The requirement of carrying network slice related identifier in the 
> data packet was described in 
> draft-dong-teas-enhanced-vpn-vtn-scalability and other relevant 
> documents. Currently there are several proposals about the encapsulation 
> of network slice related identifiers. Based on that, this document 
> further describes the considerations about the multi-domain IETF network 
> slice scenario, and the interaction with other technical domains for 5G 
> end-to-end network slicing.
>  >
>  > You are right that the path selection, resource allocation and 
> traffic handling would be based on the identifiers internal to a network 
> domain. As described in this draft, the end-to-end network slice 
> identifier may be used for traffic monitoring at the end-to-end network 
> slice granularity.
>  >
>  > Best regards,
>  > Jie
>  >
>  >> From: Joel M. Halpern [mailto:[email-masked] 
> <mailto:[email-masked]>]
>  >> To: Dongjie (Jimmy) <[email-masked] 
> <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
> various networks,
> https://datatracker.ietf.org/doc/html/draft-li-teas-e2e-ietf-network-s 
> <https://datatracker.ietf.org/doc/html/draft-li-teas-e2e-ietf-network-s>
>  >>> licing
>  >>> 
> <https://datatracker.ietf.org/doc/html/draft-li-teas-e2e-ietf-network- 
> <https://datatracker.ietf.org/doc/html/draft-li-teas-e2e-ietf-network->
>  >>> slicing>
>  >>>
> https://datatracker.ietf.org/doc/draft-li-mpls-e2e-ietf-network-slicin 
> <https://datatracker.ietf.org/doc/draft-li-mpls-e2e-ietf-network-slicin>
>  >>> g/
>  >>> 
> <https://datatracker.ietf.org/doc/draft-li-mpls-e2e-ietf-network-slici 
> <https://datatracker.ietf.org/doc/draft-li-mpls-e2e-ietf-network-slici>
>  >>> ng/>
>  >>>
>  >>> 
> https://datatracker.ietf.org/doc/html/draft-li-6man-e2e-ietf-network-s 
> <https://datatracker.ietf.org/doc/html/draft-li-6man-e2e-ietf-network-s>
>  >>> licing
>  >>> 
> <https://datatracker.ietf.org/doc/html/draft-li-6man-e2e-ietf-network- 
> <https://datatracker.ietf.org/doc/html/draft-li-6man-e2e-ietf-network->
>  >>> slicing>
>  >>>
>  >>> 
> https://datatracker.ietf.org/doc/html/draft-li-spring-sr-e2e-ietf-netw 
> <https://datatracker.ietf.org/doc/html/draft-li-spring-sr-e2e-ietf-netw>
>  >>> ork-slicing
>  >>> 
> <https://datatracker.ietf.org/doc/html/draft-li-spring-sr-e2e-ietf-net 
> <https://datatracker.ietf.org/doc/html/draft-li-spring-sr-e2e-ietf-net>
>  >>> work-slicing>
>  >>>
>  >>> [email-masked] <mailto:[email-masked]>
> <https://www.ietf.org/mailman/listinfo/teas>
>  >>>
> 
> [email-masked] <mailto:[email-masked]>
> <https://www.ietf.org/mailman/listinfo/teas>

---

From: Jeff Tantsura <[email-masked]>
Date: Fri, 14 May 2021 14:14:04 -0700

Jie,

I think, it would have been more appropriate to have “vtn/vtn-id” in the draft name, rather than "e2e-ietf-network-slicing"

Cheers,
Jeff

---

From: Daniele Ceccarelli <[email-masked]>
Date: Mon, 17 May 2021 07:36:54 +0000

I agree with Jeff, or even better, since there is a draft on the applicability of ACTN to network slicing, this one could be used to describe the applicability of VPN+/Enhanced VPN to Network slicing.

Don’t forget about the pending discussion on the relationship between ACTN VN and VTN, I still believe this duality can be easily resolved with an augmentation and have a single solution for network slicing instead of many.

BR
Daniele

From: Teas <[email-masked]> On Behalf Of Jeff Tantsura
Sent: den 14 maj 2021 23:14
To: [email-masked]; Dongjie (Jimmy) <[email-masked]>
Subject: Re: [Teas] A draft on the framework for end-to-end IETF network slicing

Jie,

Cheers,
Jeff
On May 12, 2021, 7:54 PM -0700, Dongjie (Jimmy) <[email-masked]<mailto:[email-masked]>>, wrote:

Hi WG,

Best regards,
Jie
_______________________________________________
Teas mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/teas

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Mon, 17 May 2021 09:09:34 +0000

Hi Joel, 

The traffic monitoring may happen at the edge or inside the domain, depends on the required scope of monitoring. For example, a customer may ask for edge-to-edge service monitoring by default, once there is service degradation, per-hop or per-segment monitoring could be triggered to help figure out and fix the problem timely. How the monitoring is performed in the network is not the focus of this document, it just shows some information about the end-to-end service may be used by the network nodes for monitoring.

Best regards,
Jie

> From: Teas [mailto:[email-masked]] On Behalf Of Joel M. Halpern
> Sent: Friday, May 14, 2021 12:05 PM
> Do you mean traffic monitoring at the domain edges?  Or inside the domain?
> If at the domain edges, then any mapping technology can also be used for
> monitoring.
> If inside the domain, this places a significant disaggregated statistics collection
> load on the internals of the network.
> the internals presumably will monitor the aggregated behavior.  Which again
> does not require the identification.
> 
> Yours,
> Joel
> 
> > The requirement of carrying network slice related identifier in the data packet
> was described in draft-dong-teas-enhanced-vpn-vtn-scalability and other
> relevant documents. Currently there are several proposals about the
> encapsulation of network slice related identifiers. Based on that, this document
> further describes the considerations about the multi-domain IETF network slice
> scenario, and the interaction with other technical domains for 5G end-to-end
> network slicing.
> >
> > You are right that the path selection, resource allocation and traffic handling
> would be based on the identifiers internal to a network domain. As described in
> this draft, the end-to-end network slice identifier may be used for traffic
> monitoring at the end-to-end network slice granularity.
> >
> > Best regards,
> > Jie
> >
> >> selection, QoS parameter handling, and resource allocation needs to
> >> be handled in aggregate, it seems likely that no such identifier is needed.
> >>
> >> Yours,
> >> Joel
> >>
> >>> The network slice related identifiers of different network scopes
> >>> can be instantiated with MPLS or IPv6 data plane, which are further

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Mon, 17 May 2021 09:28:14 +0000

Hi Jeff,

Thanks for your comments and suggestion.

This document mainly describes the mapping of end-to-end IETF network slices and 5G end-to-end network slices to the multi-domain and intra-domain VTNs in the underlay, this is reflected by “e2e-ietf-network-slicing” in the draft name.

I understand your point is to add “VTN” in the draft name, we will think about it.

Best regards,
Jie

From: Jeff Tantsura [mailto:[email-masked]]
Sent: Saturday, May 15, 2021 5:14 AM
To: [email-masked]; Dongjie (Jimmy) <[email-masked]>
Subject: Re: [Teas] A draft on the framework for end-to-end IETF network slicing

Jie,

Cheers,
Jeff

Hi WG,

Best regards,
Jie

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Mon, 17 May 2021 10:03:25 +0000

Hi Daniele,

Thanks for your suggestion.

This draft mainly describes the mapping of end-to-end IETF network slices and 5G end-to-end network slices to the multi-domain and intra-domain VTNs in the underlay, thus it is more about the “end-to-end” or multi-domain aspect of network slices. VPN+ and VTN are used to represent the realization of IETF network slice in the overlay and underlay respectively.

Agree further discussion about the term ACTN VN, VTN, Slice Aggregate, etc. is needed, once their relationship is resolved, the discussion on the solutions would be easier.

Best regards,
Jie

From: Daniele Ceccarelli [mailto:[email-masked]]
Sent: Monday, May 17, 2021 3:37 PM
To: Jeff Tantsura <[email-masked]>; [email-masked]; Dongjie (Jimmy) <[email-masked]>
Subject: RE: [Teas] A draft on the framework for end-to-end IETF network slicing

BR
Daniele

From: Teas <[email-masked]<mailto:[email-masked]>> On Behalf Of Jeff Tantsura
Sent: den 14 maj 2021 23:14
To: [email-masked]<mailto:[email-masked]>; Dongjie (Jimmy) <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Teas] A draft on the framework for end-to-end IETF network slicing

Jie,

Cheers,
Jeff

Best regards,
Jie

---

From: Tarek Saad <[email-masked]>
Date: Mon, 17 May 2021 15:50:22 +0000

Hi Joel/all,

Indeed, not all usecases necessitate distinguishing packets belonging to different slices/aggregates on a transit router. For example, packets of different slice/aggregates can share the same queue(s) on specific resource/link. Slicing of BW resources can still happen in control plane (e.g. assigning max guaranteed bandwidth per slice/aggregate, and/or allowing sharing of available bandwidth amongst slice aggregates, etc.). We have described this in draft-bestbar-teas-ns-packet<https://datatracker.ietf.org/doc/html/draft-bestbar-teas-ns-packet> as the “control plane” slicing mode (3GPP may also refer to this as “soft slicing”).

In other cases, assigning dedicated queues per slice aggregate is desirable to achieve certain level of isolation between different slice aggregate traffic (I reference “isolation” requirement from section 4.1.2.1<https://datatracker.ietf.org/doc/html/draft-ietf-teas-ietf-network-slices-02#section-4.1.2.1>. of draft-ietf-teas-ietf-network-slices). In such cases, packets of different slice aggregates will need to distinguishable. We have described two methods in MPLS to distinguish such packets (either by carrying a slice-ID in the packet, or by allocating a different label per prefix for different slice/aggregates – in draft-bestbar-spring-scalable<https://datatracker.ietf.org/doc/html/draft-bestbar-spring-scalable-ns>).

Regards,

Tarek

On 5/13/21, 12:48 AM, "Teas" <[email-masked]> wrote:

Yours,
Joel