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

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

> -----Original Message-----
> From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Joel M. Halpern
> Sent: Friday, May 14, 2021 12:05 PM
> To: Dongjie (Jimmy) <jie.dong@huawei.com>; teas@ietf.org
> Subject: Re: [Teas] A draft on the framework for end-to-end IETF network
> slicing
> 
> 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
> 
> On 5/13/2021 11:54 PM, Dongjie (Jimmy) wrote:
> > 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:jmh@joelhalpern.com]
> >> Sent: Thursday, May 13, 2021 12:49 PM
> >> To: Dongjie (Jimmy) <jie.dong@huawei.com>; teas@ietf.org
> >> 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
> >>
> >> 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
> >>> -s
> >>> licing
> >>> <https://datatracker.ietf.org/doc/html/draft-li-teas-e2e-ietf-networ
> >>> k-
> >>> 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-slic
> >>> in
> >>> g/
> >>> <https://datatracker.ietf.org/doc/draft-li-mpls-e2e-ietf-network-sli
> >>> ci
> >>> ng/>
> >>>
> >>> 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-networ
> >>> k-
> >>> slicing>
> >>>
> >>> https://datatracker.ietf.org/doc/html/draft-li-spring-sr-e2e-ietf-ne
> >>> tw
> >>> ork-slicing
> >>> <https://datatracker.ietf.org/doc/html/draft-li-spring-sr-e2e-ietf-n
> >>> et
> >>> work-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
> >>> Teas@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/teas
> >>>
> 
> _______________________________________________
> Teas mailing list
> Teas@ietf.org
> https://www.ietf.org/mailman/listinfo/teas