[Teas] Customer control of inclusion, policy/intent, etc. [Was: Moving forward with draft-ietf-teas-ietf-network-slices]

[Adrian Farrel <[e-mail]>]

Hi,

 

Tarek raised an issue a couple of weeks back.

 

It’s about how a network slice customer can request constraints on the
resources used in the provider network to realise the slice.

 

I believe that, in the context of this high-level document we already have
this covered in the section on Service Level Expectations (4.1.2).
Obviously, we can edit that text, but it seems to me that this type of
request made to the provider is unverifiable by the customer.

 

Tarek is right that, when specifying the NBI, this sort of thing needs to be
included. I would suggest that, unlike the SLOs, the SLEs will take quite a
bit of careful specification. It may be that the SLEs should be specified
individually in their own modules that augment the base NBI spec.

 

Igor and Joel also had a conversation on this, and I think the conclusion
was also that SLEs would normally be used for all such controls (don’t send
my traffic through country X, don’t use devices made by company Y, don’t use
services provided on DC Z). If, however, the provider chooses to supply
additional information about how the underlying network is designed, the
customer might operate on that to specify constraints. My understanding of
the relationship between provider and an external customer is that the
provider is not likely to supply that information in an operational context.
That might be different with an internal customer.

 

Unless, anyone feels strongly, I propose that we move that discussion to a
different thread and a different document.

 

Best,

Adrian

 

From: Tarek Saad <[e-mail]> 
Sent: 07 May 2021 18:46
To: John E Drake <jdrake=[e-mail]>; Igor Bryskin
<i_bryskin=[e-mail]>; Igor Bryskin <[e-mail]>;
Loa Andersson <[e-mail]>; [e-mail];
[e-mail]; [e-mail]; Oscar González de Dios
<[e-mail]>
Subject: Re: [Teas] Moving forward with draft-ietf-teas-ietf-network-slices

 

A customer may want to have a say in defining a policy on top of the route
that a NS connection can take. In absence of a common language to express
such (inclusion/exclusion) policy/intent, does it suffice to express this in
terms of geographies (GPS locations, countries, cities, roads), srlgs (srlgs
may not have global meaning), diversity needs (from other connections),
etc.? Alternatively, does it help if the NBI request expresses such
inclusions/exclusions policy using/referencing a “customer-centric” topology
that a provider may have furnished earlier to the customer, and which the
provider can readily map to their network?

 

Regards,

Tarek