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

Xufeng Liu <xufeng.liu.ietf@gmail.com> Tue, 11 May 2021 19:59 UTC

Return-Path: <xufeng.liu.ietf@gmail.com>
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 EAAB33A247C for <teas@ietfa.amsl.com>; Tue, 11 May 2021 12:59:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 4EFoc_0aJCfC for <teas@ietfa.amsl.com>; Tue, 11 May 2021 12:59:03 -0700 (PDT)
Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com [IPv6:2a00:1450:4864:20::530]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2E313A247B for <teas@ietf.org>; Tue, 11 May 2021 12:59:02 -0700 (PDT)
Received: by mail-ed1-x530.google.com with SMTP id l7so24359484edb.1 for <teas@ietf.org>; Tue, 11 May 2021 12:59:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=lF5qg82sTTYO/B4QwTCblJg8EiO9lm9sQrd2JeC18vY=; b=Ox8vk8s8Xl6sgnVYPyUTAU2jm4X0y/JlR5CuO4aI9oXgmUb+HG6Q7jcm9eI2l+42xs FDo76HiSl3IHRxN2RMEswxQYWSNz/tgmyFw315Axh8UwiIacDGEzmgcaup6zqRPe/sMO sWpyKQj10mpHSeqlcaZjdAbmVH4LkEB2y3aFqYBFPK+ao4oN3zW8kcRmUku47TGDAdgB +HXj0E2+r3FFDzIQHqGASNTJd70N3JklLM2i+xv/oTfzuquw6mRObbrD8EDcuaPOzyhb 9+mADJgtlsKPEg2rqeAGz75IVcdAAEkA1OfL9PpUcOmk+RmQmsIjlveNq1dw7tSEr3NM aS8Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=lF5qg82sTTYO/B4QwTCblJg8EiO9lm9sQrd2JeC18vY=; b=p3xKVS/O5nLjUb2pXAuIqoLfeQ/pA/eOH3t0bkfdQdKuj9C3vicSOFWoN0RlwkYD10 sMl/cRMNwv0L9PSsBtYnU+5nAvxc1WTvtKz+6KF9UZShYnrkRmxxgQGBGHxKf9VFZe2Q kMu+hZjjVmWlace6hBhLsthek2Xx//Usyet6rnqndCyrQjsaUvhDMrsKO4t3epQv+7f1 tmGya/r7v30L+hKGSw+lcUURCgKT9ylLPCKx0jP+zeTD1rGY0v4uGqWa4foKZsr9Q589 m4nuR41aBOJ3F2wALouKUVGKqzZg0cJbn84FIr6Y42gIe7bFP7XpVVf4ekAa9Sxn2IeD mE3Q==
X-Gm-Message-State: AOAM531m7FuDI8/2m2sGMwgr78O9S8lyZp3KhmQSqJhooVm5wQh8QtJX 5qJELuHl1rL+o4qxS5lf8jmXYYGSuNN+CVa42Bs=
X-Google-Smtp-Source: ABdhPJzcKCU4vdEe4DuMPfFNkl4sqeVURFEjWx3u52WylRRhVUI/rTPtgctYSQkuwAT/a8wIx7TvyWHonxwsyj96pqY=
X-Received: by 2002:aa7:c7d3:: with SMTP id o19mr24349335eds.142.1620763140383; Tue, 11 May 2021 12:59:00 -0700 (PDT)
MIME-Version: 1.0
References: <037401d740c5$70a9cc30$51fd6490$@olddog.co.uk> <3ea262cf-e4c0-5ec0-9736-aedaf6d5d4d8@pi.nu> <009401d74195$41fd70a0$c5f851e0$@olddog.co.uk> <9933_1620212302_60927A4E_9933_344_1_787AE7BB302AE849A7480A190F8B933035376DFA@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <00a001d7419e$99e5a040$cdb0e0c0$@olddog.co.uk> <03cf404d-59a7-0ec5-e18f-0a98bf638c0f@pi.nu> <CA+RyBmXoVT6z-tMEZdVoRVRzFp9gR5Ch2Ge_YQACJDUes6ja0w@mail.gmail.com> <CABNhwV0m9M+zQ5DRNv+-6xuEc52tkegO6Jho=5Pt+=Fz-GtFgg@mail.gmail.com> <TY2PR01MB3562779751C2B50D54373EB190549@TY2PR01MB3562.jpnprd01.prod.outlook.com>
In-Reply-To: <TY2PR01MB3562779751C2B50D54373EB190549@TY2PR01MB3562.jpnprd01.prod.outlook.com>
From: Xufeng Liu <xufeng.liu.ietf@gmail.com>
Date: Tue, 11 May 2021 15:58:48 -0400
Message-ID: <CAEz6PPTe1kkiHpSYfSr2gD495MUcCfGHpWqnScbYax-BXgEKLQ@mail.gmail.com>
To: "Ogaki, Kenichi" <ke-oogaki@kddi.com>
Cc: Gyan Mishra <hayabusagsm@gmail.com>, Greg Mirsky <gregimirsky@gmail.com>, Adrian Farrel <adrian@olddog.co.uk>, Med Boucadair <mohamed.boucadair@orange.com>, TEAS WG <teas@ietf.org>, Loa Andersson <loa@pi.nu>
Content-Type: multipart/alternative; boundary="0000000000003f65c205c2135316"
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/EBG-jyCDcYe35G3grMAiXgH11jo>
Subject: Re: [Teas] 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: Tue, 11 May 2021 19:59:08 -0000

On Sun, May 9, 2021 at 10:09 PM Ogaki, Kenichi <ke-oogaki@kddi.com> wrote:

> Hi Adrian and All,
>
> >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
> 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,
>
> Related to this, should we rephrase " IETF Network Slice user" if there is
> any intention to leave?
> 5.2.  Expressing Connectivity Intents
> The NSC northbound interface (NBI) can be used to communicate between IETF
> Network Slice users (or customers) and the NSC.
> An IETF Network Slice user may be a network operator who, in turn,
> provides the IETF Network Slice to another IETF Network Slice user or
> customer.
>

During the discussions on TE Topology Model, there was a similar discussion
on such terminology. At that time, the pair "client/provider" was picked
over "consumer" and "customer". The term "client" has my vote here too.


> >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.
> >
> > [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.
>
>
> Editorials:
> - I'm not sure if recent RFCs should refer SNMP as an NBI in the sense of
> https://www.ietf.org/about/groups/iesg/statements/writable-mib-module/ .
> 5.2.  Expressing Connectivity Intents
> o  SNMP ([RFC3417], [RFC3412] and [RFC3414] uses binary encoding (ASN.1).
> o  For data modeling, YANG ([RFC6020] and [RFC7950]) may be used to model
> configuration and other data for NETCONF, RESTCONF, and GNMI - among
> others; ProtoBufs can be used to model gRPC and GNMI data; Structure of
> Management Information (SMI) [RFC2578] may be used to define Management
> Information Base (MIB) modules for SNMP, using an adapted subset of OSI's
> Abstract Syntax Notation One (ASN.1, 1988).
>
> - 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.
>
>
> All the best,
> Kenichi
>
> -----Original Message-----
> From: Teas <teas-bounces@ietf.org> On Behalf Of Gyan Mishra
> Sent: Saturday, May 8, 2021 10:55 AM
> To: Greg Mirsky <gregimirsky@gmail.com>
> Cc: Adrian Farrel <adrian@olddog.co.uk>uk>; Med Boucadair <
> mohamed.boucadair@orange.com>gt;; TEAS WG <teas@ietf.org>rg>; Loa Andersson <
> loa@pi.nu>
> Subject: Re: [Teas] Moving forward with draft-ietf-teas-ietf-network-slices
>
> I agree with Loa and am not crazy about either customer or consumer as
> either refers to a “human” endpoint and not a system endpoint made of
> hardware or software like the term “CE”.
>
> +1 for Customer over Consumer as a customer is human endpoint that has
> paid for service SLA where  a consumer is  broader term like subscriber
> describing for example all broadband subscriber community.
>
> On Fri, May 7, 2021 at 3:55 PM Greg Mirsky <gregimirsky@gmail.com <mailto:
> gregimirsky@gmail.com> > wrote:
>
>
>         Hi,
>         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. Perhaps the section can include two sub-sections -
> Abbreviations/Acronyms and Terms/Terminology. I've noticed that there is
> the forward reference in the section:
>            The above terminology is defined in greater details in the
> remainder
>            of this document.
>
>         It could be those other definitions of terms used in the specific
> context in the document be collected in the new sub-section.
>
>         Regards,
>         Greg
>
>
>         On Thu, May 6, 2021 at 12:32 AM Loa Andersson <loa@pi.nu <mailto:
> loa@pi.nu> > wrote:
>
>
>                 Adrian,
>
>                 That is acceptable.
>
>                 As you said it is late in the document, and really not in
> a definitions
>                 section. I don't know if we can we place something in
> Section "2.  Terms
>                 and Abbreviations", but there seems to be only
> abbreviations.
>
>                 Your wholesale example:
>
>                 I think you forget about wholesale. What do you call the
> school that
>                 buys food at the shop to provide to the children? Do you
> call the school
>                 the customer, or do you refer to the cook who buys the
> food as the
>                 customer? The contract is with the school, negotiated by
> the cook,
>                 signed by the bursar.
>
>                 I think "the school! is the customer, which is OK in this
> context. The
>                 cook and the school kids could be viewed as consumers",
> one removed from
>                 the system.
>
>                 It strikes me that "Customer System" and "IETF Slice" are
> somewhat
>                 similar, the risk is that we talk about "customer" (even
> if we change
>                 it), and "slice" (even though if is really "IETF Slice)",
>
>                 Having said that, though it is not my task to call
> consensus, I think we
>                 have a enough support to use "customer".
>
>                 I rest my case.
>
>                 /Loa
>
>
>                 On 05/05/2021 13:05, Adrian Farrel wrote:
>                 > We currently have (in section 5.1, which may be a bit
> late in the document)
>                 >
>                 >     Customer:  A customer is the requester of an IETF
> Network Slice.
>                 >        Customers may request monitoring of SLOs.  A
> customer may manage
>                 >        the IETF Network Slice service directly by
> interfacing with the
>                 >        IETF NSC or indirectly through an orchestrator.
>                 >
>                 > We could add "A customer may be an entity such as an
> enterprise network or a
>                 > network operator, an individual working at such an
> entity, a private
>                 > individual contracting for a service, or an application
> or software
>                 > component."
>                 >
>                 > Cheers,
>                 > Adrian
>                 >
>                 > -----Original Message-----
>                 > From: mohamed.boucadair@orange.com <mailto:
> mohamed.boucadair@orange.com>  <mohamed.boucadair@orange.com <mailto:
> mohamed.boucadair@orange.com> >
>                 > Sent: 05 May 2021 11:58
>                 > To: adrian@olddog.co.uk <mailto:adrian@olddog.co.uk> ;
> 'Loa Andersson' <loa@pi.nu <mailto:loa@pi.nu> >; teas@ietf.org <mailto:
> teas@ietf.org>
>                 > Subject: RE: [Teas] Moving forward with
> draft-ietf-teas-ietf-network-slices
>                 >
>                 > Hi all,
>                 >
>                 >> Anyone else got anything to say on the topic?
>                 >
>                 > I would simply use "customer" and make sure the
> definition is generic enough
>                 > to denote a role/entity.
>                 >
>                 > Thanks.
>                 >
>                 > Cheers,
>                 > Med
>                 >
>                 >> -----Message d'origine-----
>                 >> De : Teas [mailto:teas-bounces@ietf.org <mailto:
> teas-bounces@ietf.org> ] De la part de Adrian Farrel
>                 >> Envoyé : mercredi 5 mai 2021 11:59
>                 >> À : 'Loa Andersson' <loa@pi.nu <mailto:loa@pi.nu> >;
> teas@ietf.org <mailto:teas@ietf.org>
>                 >> Objet : Re: [Teas] Moving forward with
> draft-ietf-teas-ietf-network-
>                 >> slices
>                 >>
>                 >> Hi Loa,
>                 >>
>                 >>> On customer vs. consumer Adrian says:
>                 >>>
>                 >>>>    c. "Consumer" vs "customer". I have made this
> consistent (we
>                 >> only need to
>                 >>>>         use one term). I selected "Customer" because
> that seemed
>                 >> best, but I
>                 >>>>         know some people prefer "consumer". Please
> discuss if you
>                 >> are not
>                 >>>>         happy.
>                 >>>
>                 >>> If the choice is between customer vs. consumer, I
> prefer customer.
>                 >>
>                 >> OK. So I made an improvement, but...
>                 >>
>                 >>> I don't know if it is too late to bring this up.
>                 >>
>                 >> It's never too late to bring things up.
>                 >>
>                 >>> But I really don't like either, normal language has a
> strong
>                 >>> indication that that that a customer is a person (a
> person that
>                 >> walks
>                 >>> inte to your
>                 >>> shop) and consumer is also a person /that eats what I
> bought at
>                 >> your shop).
>                 >>
>                 >> I think you forget about wholesale. What do you call
> the school that
>                 >> buys food at the shop to provide to the children? Do
> you call the
>                 >> school the customer, or do you refer to the cook who
> buys the food as
>                 >> the customer? The contract is with the school,
> negotiated by the
>                 >> cook, signed by the bursar.
>                 >>
>                 >>> IETF specifies "systems", including what goes into SW
> and HW, but
>                 >> we
>                 >>> don't specify normative rules for human behavior.
>                 >>>
>                 >>> I don't know if we can talk about Customer System?
>                 >>
>                 >> I'm afraid of this getting heavy for the reader. There
> are 73
>                 >> instances of "customer" in the document, and "customer
> system" may
>                 >> become tiresome to read.
>                 >>
>                 >> Anyone else got anything to say on the topic?
>                 >>
>                 >> Cheers,
>                 >> Adrian
>                 >>
>                 >> _______________________________________________
>                 >> Teas mailing list
>                 >> Teas@ietf.org <mailto:Teas@ietf.org>
>                 >> https://www.ietf.org/mailman/listinfo/teas
>                 >
>                 >
> ____________________________________________________________________________
>                 > _____________________________________________
>                 >
>                 > Ce message et ses pieces jointes peuvent contenir des
> informations
>                 > confidentielles ou privilegiees et ne doivent donc
>                 > pas etre diffuses, exploites ou copies sans
> autorisation. Si vous avez recu
>                 > ce message par erreur, veuillez le signaler
>                 > a l'expediteur et le detruire ainsi que les pieces
> jointes. Les messages
>                 > electroniques etant susceptibles d'alteration,
>                 > Orange decline toute responsabilite si ce message a ete
> altere, deforme ou
>                 > falsifie. Merci.
>                 >
>                 > This message and its attachments may contain
> confidential or privileged
>                 > information that may be protected by law;
>                 > they should not be distributed, used or copied without
> authorisation.
>                 > If you have received this email in error, please notify
> the sender and
>                 > delete this message and its attachments.
>                 > As emails may be altered, Orange is not liable for
> messages that have been
>                 > modified, changed or falsified.
>                 > Thank you.
>                 >
>                 > _______________________________________________
>                 > Teas mailing list
>                 > Teas@ietf.org <mailto:Teas@ietf.org>
>                 > https://www.ietf.org/mailman/listinfo/teas
>                 >
>
>                 --
>
>                 Loa Andersson                        email: loa@pi.nu
> <mailto:loa@pi.nu>
>                 Senior MPLS Expert
> loa.pi.nu@gmail.com <mailto:loa.pi.nu@gmail.com>
>                 Bronze Dragon Consulting             phone: +46 739 81 21
> 64
>
>                 _______________________________________________
>                 Teas mailing list
>                 Teas@ietf.org <mailto:Teas@ietf.org>
>                 https://www.ietf.org/mailman/listinfo/teas
>
>
>         _______________________________________________
>         Teas mailing list
>         Teas@ietf.org <mailto:Teas@ietf.org>
>         https://www.ietf.org/mailman/listinfo/teas
>
>
> --
>
>
>  <http://www.verizon.com/>
>
>
> Gyan Mishra
>
> Network Solutions Architect
>
> Email gyan.s.mishra@verizon.com <mailto:gyan.s.mishra@verizon.com>
>
>
> M 301 502-1347
>
>
>
>
> _______________________________________________
> Teas mailing list
> Teas@ietf.org
> https://www.ietf.org/mailman/listinfo/teas
>