Re: [Teas] Moving forward with draft-ietf-teas-ietf-network-slices

Adrian Farrel <> Sun, 23 May 2021 16:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 293B43A1DF9 for <>; Sun, 23 May 2021 09:09:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.049
X-Spam-Status: No, score=-1.049 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MAY_BE_FORGED=0.846, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8e5X1btAShPB for <>; Sun, 23 May 2021 09:09:24 -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 C212C3A1DF7 for <>; Sun, 23 May 2021 09:09:23 -0700 (PDT)
Received: from ( []) by (8.14.4/8.14.4) with ESMTP id 14NG9KXC005009; Sun, 23 May 2021 17:09:21 +0100
Received: from (unknown []) by IMSVA (Postfix) with ESMTP id B300C4604B; Sun, 23 May 2021 17:09:20 +0100 (BST)
Received: from (unknown []) by IMSVA (Postfix) with ESMTP id A713846048; Sun, 23 May 2021 17:09:20 +0100 (BST)
Received: from (unknown []) by (Postfix) with ESMTPS; Sun, 23 May 2021 17:09:20 +0100 (BST)
Received: from LAPTOPK7AS653V ( [] (may be forged)) (authenticated bits=0) by (8.14.4/8.14.4) with ESMTP id 14NG9JOi009759 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 23 May 2021 17:09:20 +0100
From: Adrian Farrel <>
To: "'Ogaki, Kenichi'" <>
Cc: 'TEAS WG' <>
References: <037401d740c5$70a9cc30$51fd6490$> <> <009401d74195$41fd70a0$c5f851e0$> <9933_1620212302_60927A4E_9933_344_1_787AE7BB302AE849A7480A190F8B933035376DFA@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <00a001d7419e$99e5a040$cdb0e0c0$> <> <> <> <>
In-Reply-To: <>
Date: Sun, 23 May 2021 17:09:12 +0100
Organization: Old Dog Consulting
Message-ID: <006201d74fed$fd2eb8a0$f78c29e0$>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQIxNfjF9qcx9VubDm1D4ubI8og6YwEz+LibAjUMGbABYFA3hgHvb8wpAemJjtIBZXPn4gI55yiCAf3KYIypy2iHAA==
Content-Language: en-gb
X-TM-AS-Product-Ver: IMSVA-
X-TM-AS-Result: No--10.473-10.0-31-10
X-imss-scan-details: No--10.473-10.0-31-10
X-TMASE-Result: 10--10.472900-10.000000
X-TMASE-MatchedRID: gjZGo2H/wj+yoI+bK8UPQnFPUrVDm6jtiRPU6vvejXJQKAQSutQYXG5T dz7oO5gDYdIOC1NgIlHmH0IryjPgmTgcoj/JqpGb2PArUpVkoPzg02I3oyGU8IDpStszePepRci PnulmwZJFmap458UxIgqq7jK3PysyJvvmH9qMmwlswYo64ufkVUxAi7xkncUqBXf5SNAXllZSOp OCC9n7Lmus3lijnklNz7QMJFmJFzNrLYf5UBryJd5x7RpGJf1aa1wRdX1rZ06mN8unTxTf9Yy+A fTlDGN1X6sad3k2XW04OmD2kFbOf4pEmz1GDP2KHch4gZ8olb9SQLJ/PYofeDyorQlAw+NJXcbb ObOZU/fyBjb2q8zIH0BT2y3wGAdtXSJ4c3nT+QcrCLswi3NpjciSpZfTU/nYHWPU3lubAmeI8GM xdQ4zT2FsBpHiMZFz+nlvRmQA9jG7wTr8Ih9OqPrNPkGWAHDfvMRNh9hLjFk10hFCwEzEucajin ev47U2oZKuxEczWUy4LZzenDhGP3wWgwyzaBU1KzfM9B6IRt76C0ePs7A07YVH0dq7wY7up8Odl 1VwpCTaauVTf8uT+8artCUyCpoNGAdYrdq34Pk3Z7IkFuNQqizx5e5h1ACv
X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0
Archived-At: <>
Subject: Re: [Teas] 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 16:09:28 -0000

Hi Kenichi,

I'm cleaning up the comments to produce a new revision.

>I agree with Loa, moving the definition of how the term "customer" is interpreted in
> the document to the Terms and Abbreviations section seems very reasonable.
> +1

OK. I'm doing this.

> I don't stick to "customer", but a discussion how about rephrasing "provider" with
> "producer" may also rise when I choose non-ietf-standard "consumer" term

Two things:
- Yes, the discussion of alternatives to "provider" is also still open
- I am keeping a list of people who feel "strongly" about customer/consumer/client
  At the moment I don't feel able to draw any conclusions. I don't think this will 
  change the text on the definition, and we can change the name later if we can
  reach agreement.

> Related to this, should we rephrase " IETF Network Slice user" if there is any
> intention to leave?

Good catch.

> the expectation currently is that the IETF Network Slice Service will use
> something along the lines of the service models (L2SM and L3SM).  It seems
> reasonable to enhance those with something about service functions, quite
> possibly along the lines you are already working on.

Yes. I hope to bring some text on "slice as a service" for discussion SOON.

> [TS] (snip) 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
> FYI, L3SM tried to let the customer define such policy against PE site in
> sec. 6.6.
> I know this is non-exhaustive for IETF Network Slice.

Thanks for the pointer to L3SM.

> Editorials:
> - I'm not sure if recent RFCs should refer SNMP as an NBI in the sense of
> .

I agree with you. I'll remove SNMP from the list in 5.2 unless someone shouts (see separate email).

> - multipoint-to-point twice
> .2.  IETF Network Slice Endpoints
> As noted in Section 3.1, an IETF Network Slice describes connectivity between multiple
> endpoints across the underlying network.  These connectivity types are: point-to-point,
> point-to-multipoint,  multipoint-to-point, multipoint-to-point, or multipoint-to-multipoint.