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

Adrian Farrel <adrian@olddog.co.uk> Sun, 23 May 2021 17:00 UTC

Return-Path: <adrian@olddog.co.uk>
X-Original-To: teas@ietfa.amsl.com
Delivered-To: teas@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E66423A1F25 for <teas@ietfa.amsl.com>; Sun, 23 May 2021 10:00:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.05
X-Spam-Level:
X-Spam-Status: No, score=-1.05 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MAY_BE_FORGED=0.846, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5kaMvDrml9QT for <teas@ietfa.amsl.com>; Sun, 23 May 2021 09:59:57 -0700 (PDT)
Received: from mta7.iomartmail.com (mta7.iomartmail.com [62.128.193.157]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC4AF3A1F24 for <teas@ietf.org>; Sun, 23 May 2021 09:59:55 -0700 (PDT)
Received: from vs2.iomartmail.com (vs2.iomartmail.com [10.12.10.123]) by mta7.iomartmail.com (8.14.4/8.14.4) with ESMTP id 14NGxqgd009694; Sun, 23 May 2021 17:59:52 +0100
Received: from vs2.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id A27484604B; Sun, 23 May 2021 17:59:52 +0100 (BST)
Received: from vs2.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 8C58946048; Sun, 23 May 2021 17:59:52 +0100 (BST)
Received: from asmtp2.iomartmail.com (unknown [10.12.10.249]) by vs2.iomartmail.com (Postfix) with ESMTPS; Sun, 23 May 2021 17:59:52 +0100 (BST)
Received: from LAPTOPK7AS653V (65.151.51.84.dyn.plus.net [84.51.151.65] (may be forged)) (authenticated bits=0) by asmtp2.iomartmail.com (8.14.4/8.14.4) with ESMTP id 14NGxpJh028046 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 23 May 2021 17:59:52 +0100
Reply-To: <adrian@olddog.co.uk>
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: <teas@ietf.org>
Cc: "'Tarek Saad'" <tsaad.net@gmail.com>, "'Joel M. Halpern'" <jmh@joelhalpern.com>, <i_bryskin@yahoo.com>
Date: Sun, 23 May 2021 17:59:51 +0100
Organization: Old Dog Consulting
Message-ID: <006301d74ff5$0c5926b0$250b7410$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0064_01D74FFD.6E1E03E0"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AddP8WbQtWXVO8BET66hgr0OGy3Czw==
Content-Language: en-gb
X-Originating-IP: 84.51.151.65
X-Thinkmail-Auth: adrian@olddog.co.uk
X-TM-AS-GCONF: 00
X-TM-AS-Product-Ver: IMSVA-9.1.0.2034-8.6.0.1017-26176.001
X-TM-AS-Result: No--24.058-10.0-31-10
X-imss-scan-details: No--24.058-10.0-31-10
X-TMASE-Version: IMSVA-9.1.0.2034-8.6.1017-26176.001
X-TMASE-Result: 10--24.058400-10.000000
X-TMASE-MatchedRID: U/PHmQDCHWoaf3p8Lo2lejjNGpWCIvfTGnGYpZN+xAi/md2adk3dRPon 0k/OvQV1/fPselhSQhig/bewdJRDN+ebvkLr2VWfXK5keCa+bmiL5MCc+du22P4DDXoaCqk7oSn PJtmDAFIleG4is28+30C/ow0yG5yfspb4bu0m9eJsExK7i/Tm0zlYgt0CDgEgBXf5SNAXllZPT/ REbnZuzm+JneoOfPbqFjAvvhjNwW0Z1VI1DVL4ZRzsdVXXq/9LpRgiDG6+4P4B9Ua7EJMxQoOyk UqGw9SMSMyGchnpVhVLCObiQqubnV2P5fu1s84xmOFnGEL0JONboh0Au8fxU0EkCwjf78lm65m9 UAMkuJybMLsgNbnVuOSzWOm8L2lIKV8HMKUQpyDFwO/GbRS/4AgnaupNy5h21I1aqyIUVaon3U5 H2maWx31mjPmKBMSqC3x9PDRUSdzzjNGi2apLGCWj5wKnsklKtD/Lx+LfvEuTS1+cdzrPk+//vb MLiEkV0+0G7io/4HWtQ57zuXEmXBWVVkGuW6Jr3zSg/bkXzGld5/m3qrxFzEqa6TyhyXvPk/W3d qvyXNMLwTxkKC1upZfrKASrZ1St8/HAP78oRbYmEURBmKrZlJkShYcLpGH9rDZuIFerDYSD1dmb wZsuTo0id0pIhqxTwlNIR2Yo/WS2tlYdo0NnhNjwK1KVZKD8WaKvOaBFthQowpDqBFN+r+CfwdX r9Uztu7C4hieFwVLQL/7nfhGuGgRAFIbudrfIfwO+RRpsStWrEHfaj14Zyet5xHYKbwmO+83hlI v7pXbzUVKm7FbQzJ44v/JGEFYReZcRGEp+Txc=
X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/hOJMG8te5dmI2EJUfuio3tctEzk>
Subject: [Teas] Customer control of inclusion, policy/intent, etc. [Was: Moving forward with draft-ietf-teas-ietf-network-slices]
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <teas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/teas>, <mailto:teas-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teas/>
List-Post: <mailto:teas@ietf.org>
List-Help: <mailto:teas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/teas>, <mailto:teas-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 23 May 2021 17:00:02 -0000

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 <tsaad.net@gmail.com> 
Sent: 07 May 2021 18:46
To: John E Drake <jdrake=40juniper.net@dmarc.ietf.org>rg>; Igor Bryskin
<i_bryskin=40yahoo.com@dmarc.ietf.org>rg>; Igor Bryskin <i_bryskin@yahoo.com>om>;
Loa Andersson <loa@pi.nu>nu>; adrian@olddog.co.uk;
mohamed.boucadair@orange.com; teas@ietf.org; Oscar González de Dios
<oscar.gonzalezdedios@telefonica.com>
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