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-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-slicin
>>> g/
>>> <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
>>> licing
>>> <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
>>> ork-slicing
>>> <https://datatracker.ietf.org/doc/html/draft-li-spring-sr-e2e-ietf-net
>>> 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
>>>