Re: [CCAMP] [Teas] Decision point on scope of draft-ietf-teas-ietf-network-slices

Yes, agreed. The management and optimization of NRP resources in the network is key.
It would be possible (and up to the NSC) to decide whether to pin existing NRP resources, or whether to aggregate/multiplex new services on top of a new or an existing NRP.
As you point out, the underlying network resource utilization and/or policies that are in-place can indeed govern the above decisions.

Regards,
Tarek

From: Igor Bryskin <i_bryskin@yahoo.com>
Date: Monday, March 14, 2022 at 4:04 PM
To: tsaad.net@gmail.com <tsaad.net@gmail.com>, Tarek Saad <tsaad.net@gmail.com>, Krzysztof Szarkowicz <kszarkowicz@gmail.com>, LUIS MIGUEL CONTRERAS MURILLO <luismiguel.contrerasmurillo@telefonica.com>
Cc: adrian@olddog.co.uk <adrian@olddog.co.uk>, CCAMP <ccamp@ietf.org>, Gyan Mishra <hayabusagsm@gmail.com>, TEAS WG <teas@ietf.org>, Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>
Subject: Re: [Teas] [CCAMP] Decision point on scope of draft-ietf-teas-ietf-network-slices
Tarek,

I don't mind creation/manipulation of NRPs on the fly, but only as long as it does not require re-configuration of underlying  transport layer networks. Otherwise, how do you guarantee any level of optimality of transport resource utilization? For example, how do you ensure that  the newly created 400G Och trails do not remain 5% utilized for the remainder of the NRP's life time? Note that subsequent resizing of the NRP won't help because:
- it would be very difficult to achieve, especially, if IP layer spans multiple transport networks;
- would be destructive to existing service unpredictably violating their SLOs;
- as inefficient and imprudent as the very automatic creation of yhe NRPs in the first place

In a way it would be not unlike creating , say,  Boeing 777 service Washington DC - Sydney just  because several Australians showed up in the Dulles Airport.
Do you agree with the analogy?

Igor

Sent from Yahoo Mail on Android<https://go.onelink.me/107872968?pid=InProduct&c=Global_Internal_YGrowth_AndroidEmailSig__AndroidUsers&af_wl=ym&af_sub1=Internal&af_sub2=Global_YGrowth&af_sub3=EmailSignature>

On Mon, Mar 14, 2022 at 1:39 PM, Tarek Saad
<tsaad.net@gmail.com> wrote:
_______________________________________________
Teas mailing list
Teas@ietf.org<mailto:Teas@ietf.org>
https://www.ietf.org/mailman/listinfo/teas