Re: [Teas] network Slice Endpoint in draft-ietf-teas-ietf-network-slice-definition-00

Greg Mirsky <gregimirsky@gmail.com> Tue, 23 February 2021 17:27 UTC

Return-Path: <gregimirsky@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 D39F93A0C2A for <teas@ietfa.amsl.com>; Tue, 23 Feb 2021 09:27:01 -0800 (PST)
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, 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 6SwSoZ4XS929 for <teas@ietfa.amsl.com>; Tue, 23 Feb 2021 09:26:59 -0800 (PST)
Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) (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 C442A3A0C18 for <teas@ietf.org>; Tue, 23 Feb 2021 09:26:58 -0800 (PST)
Received: by mail-lj1-x229.google.com with SMTP id v17so2897906ljj.9 for <teas@ietf.org>; Tue, 23 Feb 2021 09:26:58 -0800 (PST)
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=c1h6FEyTsWwmw458iSCYuqo9kH/NeId2/x2tsET9oMg=; b=W1MkkJOHiLmftGMKIiwDzQLsxsH9ReM4+aaWMuqDZt6vfTutUtHDnuaBzpGUdqiVN6 zRRfgp529rGr9UpT6p8heS7ZuXX1MruV3+kn9bUBmsoCYJr3NcSLoMLlNWZisACGV90c 98ck4Y66/iPu3bERDXa1TGLIIQCwP3fmGaiSSB5M6BO0a+7SdlPB6gzJENaTkSa3/nFo rglfski3YO2ySkS9ReZ96OiiHY57AfmuBZ/hZVjWcgF2sxKmFX2/og+iJTn3yoLwM3mq qVq+SbG880AfpjP8PQgwO8jWoL2hWhtDaqgchJABfxbApr5UlLcAS5GDo/ZNy9OHjL6V eCYg==
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=c1h6FEyTsWwmw458iSCYuqo9kH/NeId2/x2tsET9oMg=; b=o216Da9pVNCClkOoju2KjLbDMado2BQKeMZeXHjvUQrHVeSIvPOyISB+JFcQh/5UKa +g7C9sinHPZlj6WkmQLpOwjskU0qmMli6Q2a4Zf0rNg+rwrnKdtFuJ8yc0+g4uj0toR3 dJpyD68pCWhvhRH+grZ98Cx2hKbHE/gHEaoHdNzfqJR0Oj+Fw2tU3tTBdjnPkBmiXY1A CMIdDWbr5ORPMwHdOjTWBZ1iyPzIWpVc2QnHo/q3hz6sPthWHbiqd4/zFiOXVyfIKgre QhNoK9JcXRYNGxJ6VzivXiJlWg1Fuzcvhsfr3Z4DJeylpBMccDpWs5r+taUFb+AyGc6H 37Ng==
X-Gm-Message-State: AOAM531B06G26haY7gWa1DGmrBvKqMR5oabpS5Xg3gBQQNhBVE0m8WLM Kl1ks8D0bjXkgh7Ez8ilLLKfOndHzQGpJKaNA+A=
X-Google-Smtp-Source: ABdhPJxEayNO0+5Nl26w0BflTkjA2E1nVuE+RUyvmhg9krWVjQpsWYrkozjCIULAtBuGiEPBLe0fm5O0fd5FhfBCsyM=
X-Received: by 2002:a2e:6c02:: with SMTP id h2mr18033928ljc.170.1614101216884; Tue, 23 Feb 2021 09:26:56 -0800 (PST)
MIME-Version: 1.0
References: <cc3949a4-1e60-7f77-45bd-2470be67d9d5@joelhalpern.com> <28233_1613491513_602BED39_28233_126_1_787AE7BB302AE849A7480A190F8B9330315CF830@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <1bf03e82-3734-885a-7047-cacf5c63d9cc@joelhalpern.com> <8211_1613493543_602BF527_8211_334_1_787AE7BB302AE849A7480A190F8B9330315CF95E@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <cde51de3-4533-9acd-a654-59a1dc9f195b@joelhalpern.com> <11878_1613494720_602BF9C0_11878_194_1_787AE7BB302AE849A7480A190F8B9330315CF9FC@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <MN2PR05MB6623B0D3F5EEECFB3CE3FA8BC7809@MN2PR05MB6623.namprd05.prod.outlook.com>
In-Reply-To: <MN2PR05MB6623B0D3F5EEECFB3CE3FA8BC7809@MN2PR05MB6623.namprd05.prod.outlook.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Tue, 23 Feb 2021 09:26:46 -0800
Message-ID: <CA+RyBmXyqObyKaiJkdz=+sd6UqWUQozLOBLGR4cbsV5_bEVYhg@mail.gmail.com>
To: John E Drake <jdrake=40juniper.net@dmarc.ietf.org>
Cc: "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>, "Joel M. Halpern" <jmh@joelhalpern.com>, "teas@ietf.org" <teas@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000a9fa9505bc043908"
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/XBnHG1eovDKA5V4gToWmwH4uIok>
Subject: Re: [Teas] network Slice Endpoint in draft-ietf-teas-ietf-network-slice-definition-00
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, 23 Feb 2021 17:27:02 -0000

Hi John,
thank you and Eric for putting this part in a great concise way. It is now
much simpler and simple, in my opinion, is always the better way.
Yes, I support the proposed update to this WG document.

Regards,
Greg

On Tue, Feb 23, 2021 at 6:52 AM John E Drake <jdrake=
40juniper.net@dmarc.ietf.org> wrote:

> Hi,
>
> Eric and I have reviewed the Definitions draft, the email thread with the
> subject line: Network Slice Endpoint in
> draft-ietf-teas-ietf-network-slice-definition-00, and the RFCs referenced
> in emails on that thread - 3985, 4110, 4026, 4664, and 8309, and we would
> like to propose that in the Definitions draft we replace 'network slice
> endpoint' with 'CE' and 'network slice realization endpoint' with 'PE',
> that we reference  RFCs  3985, 4110, 4026, 4664, and 8309, and that we
> replace the current figure in Endpoint section with several figures, which
> show connectivity constructs and which are consistent with these RFCs.  We
> would also like to replace 'consumer' with 'customer', add 'attachment
> circuit', and add a new term, viz, 'IETF Network Slice Service', whose
> definition is a set of CEs, a set of connectivity constructs (MP2MP, P2MP,
> P2P, etc.) between subsets of these CEs and an SLO for each CE sending to
> each connectivity construct.
>
> As an aside, the Endpoint section of the Definitions draft uses the bulk
> of its prose enumerating what its endpoints are not.  Per Yakov, since
> there are a potentially infinite number of things which its endpoints are
> not, this is futile and we would like to remove that prose.
>
> Yours Irrespectively,
>
> Eric and John
>
>
> Juniper Business Use Only
>
> > -----Original Message-----
> > From: Teas <teas-bounces@ietf.org> On Behalf Of
> > mohamed.boucadair@orange.com
> > Sent: Tuesday, February 16, 2021 11:59 AM
> > To: Joel M. Halpern <jmh@joelhalpern.com>om>; teas@ietf.org
> > Subject: Re: [Teas] network Slice Endpoint in
> draft-ietf-teas-ietf-network-slice-
> > definition-00
> >
> > [External Email. Be cautious of content]
> >
> >
> > Re-,
> >
> > Indeed. That's need to be fixed.
> >
> > As we are on the terminology, I do also suggest that the draft is
> updated to
> > adhere to RFC8309. Given the recursiveness discussed in the draft,
> having geo-
> > coordinates interfaces is also confusing. Inspiring from RFC8309 would
> make
> > more sense.
> >
> > Cheers,
> > Med
> >
> > > -----Message d'origine-----
> > > De : Joel M. Halpern [mailto:jmh@joelhalpern.com] Envoyé : mardi 16
> > > février 2021 17:44 À : BOUCADAIR Mohamed TGI/OLN
> > > <mohamed.boucadair@orange.com>om>; teas@ietf.org Objet : Re: [Teas]
> > > network Slice Endpoint in draft-ietf-teas-ietf-
> > > network-slice-definition-00
> > >
> > > I would be happy to use CE and PE.  I would also be happy to use
> > > completely different words.  The current diagram and terminology makes
> > > this very confusing, and leads to problems.
> > >
> > > Yours,
> > > Joel
> > >
> > > On 2/16/2021 11:39 AM, mohamed.boucadair@orange.com wrote:
> > > > Re-,
> > > >
> > > > Please see inline.
> > > >
> > > > Cheers,
> > > > Med
> > > >
> > > >> -----Message d'origine-----
> > > >> De : Teas [mailto:teas-bounces@ietf.org] De la part de Joel M.
> > > >> Halpern
> > > >> Envoyé : mardi 16 février 2021 17:12 À : teas@ietf.org Objet : Re:
> > > >> [Teas] network Slice Endpoint in draft-ietf-teas-ietf-
> > > >> network-slice-definition-00
> > > >>
> > > >> The document is not about the request from the external customer
> > > (the
> > > >> request for the end-to-end network slice). It is about the request
> > > >> from other orchestration systems to the IETF Network Slice
> > > management
> > > >> systems.
> > > >
> > > > [Med] ... which is still behaving as the customer role.
> > > >
> > > >   Yes, those systems need to know where they intent to
> > > >> utilize the IETF network slice.  But the IETF network slice does
> > > not
> > > >> need to know about that.
> > > >
> > > > [Med] This is what I fail to see. The orchestrator has an internal
> > > vision that is not available to the entity asking for a slice. These
> > > nodes are not even known to the "other orchestration systems" when
> > > asking for a slice.
> > > >
> > > >>
> > > >> In particular, when we get to talking about configuring the IETF
> > > >> Network Slice properties, the edge (ingress) that the IETF Network
> > > >> Slice controller controls (and corresponding egress) is what needs
> > > to
> > > >> be provisioned.
> > > >
> > > > [Med] Agree, but that is a distinct phase.
> > > >
> > > > BTW, ingress/egress are as a function of the traffic direction. A
> > > node (PE) may behave as both ingress and egress for the same slice.
> > > >
> > > >> It is possible that on the egress side there needs to be
> > > information
> > > >> about how to deliver the traffic externally.
> > > >
> > > > [Med] Agree. That node does not need to be visible (known in
> > > advance) to the entity that will consume the corresponding slice.
> > > >
> > > >    But that would not be
> > > >> in terms of end-points since from the perspective of the IETF
> > > Network
> > > >> Slice, on the egress that is not an endpoint of anything.
> > > >
> > > > [Med] I agree that "endpoint" is confusing. "Customer Node/Edge" vs
> > > "Provider Edge" are my favorite here.
> > > >
> > > >>
> > > >> Yours,
> > > >> Joel
> > > >>
> > > >> On 2/16/2021 11:05 AM, mohamed.boucadair@orange.com wrote:
> > > >>> Hi Joel,
> > > >>>
> > > >>> I disagree with this note. I do think that both flavors of
> > > >> "endpoint" should be included in the draft.
> > > >>>
> > > >>> >From the customer standpoint, a slice request cannot be
> > > >> characterized by elements not visible to the customer. The scope
> > > of a
> > > >> requested slice can only be characterized between nodes that are
> > > >> known to the requestor. This is usually called, CE.
> > > >>>
> > > >>> The mapping between a CE and a network device (typically, a PE)
> > > is
> > > >> a process that is internal to the slice provider.
> > > >>>
> > > >>> The CE-PE link cannot be systematically excluded as some specific
> > > >> behaviors may need to be enforced in the CE-PE link. Think about a
> > > >> slice that is implemented by means of a PE-based VPN and which
> > > >> requires some specific routing + QoS policies at the CE-PE link.
> > > >>>
> > > >>> Cheers,
> > > >>> Med
> > > >
> > > >
> > > >
> > >
> > _________________________________________________________________
> > ____
> > > _
> > > > ___________________________________________________
> > > >
> > > > 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.
> > > >
> >
> > _________________________________________________________________
> > ________________________________________________________
> >
> > 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
> >
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas__;!!N
> > Et6yMaO-gk!TrdpM67-tg4psF0dnG7jBV9LisKHxO_oCNxmQXrJhY-
> > B6MFchY8gBvvb8CNl408$
> _______________________________________________
> Teas mailing list
> Teas@ietf.org
> https://www.ietf.org/mailman/listinfo/teas
>