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

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 23 May 2021 17:59:51 +0100

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 <[email-masked]> 
Sent: 07 May 2021 18:46
To: John E Drake <jdrake=[email-masked]>; Igor Bryskin
<i_bryskin=[email-masked]>; Igor Bryskin <[email-masked]>;
Loa Andersson <[email-masked]>; [email-masked];
[email-masked]; [email-masked]; Oscar González de Dios
<[email-masked]>
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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 23 May 2021 14:10:57 -0400

Thanks Adrian.  That all sounds reasonable to me.
Yours,
Joel

On 5/23/2021 12:59 PM, Adrian Farrel wrote:
> 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). 
> 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 <[email-masked]>
> *Sent:* 07 May 2021 18:46
> *To:* John E Drake <jdrake=[email-masked]>; Igor Bryskin 
> <i_bryskin=[email-masked]>; Igor Bryskin 
> <[email-masked]>; Loa Andersson <[email-masked]>; [email-masked]; 
> *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
> 
> 
> _______________________________________________
> Teas mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/teas
>