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

"Joel M. Halpern" <> Sun, 23 May 2021 18:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A83143A2125 for <>; Sun, 23 May 2021 11:11:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ThCiziona18i for <>; Sun, 23 May 2021 11:10:59 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9157D3A2124 for <>; Sun, 23 May 2021 11:10:59 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4Fp7gl28mQz6GBf4; Sun, 23 May 2021 11:10:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=2.tigertech; t=1621793459; bh=XFqcCpWC5cqpHT0uqxZiNMCsV/NNSkYozRuB/rqbLeE=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=AfoULfr7u/ppC+Hnj7WOKAtGtf8cO64d+l2Qpe+YsqR+5fR1EXCptZ5nPE6BcTLh6 wnaTUV432aHZQM+ElKtlCY5JVpTrzaI+x23FN2VHfpBwguSIe381xLwPKF3IQ2HkNU YuaG3KBnln9+lY1U8ZnGNauy+dqqhGMVNYIzf0EA=
X-Quarantine-ID: <Rz3TqYWJD6-V>
X-Virus-Scanned: Debian amavisd-new at
Received: from [] ( []) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPSA id 4Fp7gk4SfXz6G9jq; Sun, 23 May 2021 11:10:58 -0700 (PDT)
Cc:, 'Tarek Saad' <>
References: <006301d74ff5$0c5926b0$250b7410$>
From: "Joel M. Halpern" <>
Message-ID: <>
Date: Sun, 23 May 2021 14:10:57 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.2
MIME-Version: 1.0
In-Reply-To: <006301d74ff5$0c5926b0$250b7410$>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <>
Subject: Re: [Teas] Customer control of inclusion, policy/intent, etc. [Was: Moving forward with draft-ietf-teas-ietf-network-slices]
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 23 May 2021 18:11:04 -0000

Thanks Adrian.  That all sounds reasonable to me.

On 5/23/2021 12:59 PM, Adrian Farrel wrote:
> 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 <>
> *Sent:* 07 May 2021 18:46
> *To:* John E Drake <>; Igor Bryskin 
> <>; Igor Bryskin 
> <>; Loa Andersson <>;; 
>;; Oscar González de Dios 
> <>
> *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