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

Greg Mirsky <gregimirsky@gmail.com> Sun, 04 April 2021 03:04 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 297E23A10C0 for <teas@ietfa.amsl.com>; Sat, 3 Apr 2021 20:04:22 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 m1NX1BaEJG1L for <teas@ietfa.amsl.com>; Sat, 3 Apr 2021 20:04:16 -0700 (PDT)
Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) (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 153E63A10BD for <teas@ietf.org>; Sat, 3 Apr 2021 20:04:15 -0700 (PDT)
Received: by mail-lf1-x135.google.com with SMTP id m12so12754645lfq.10 for <teas@ietf.org>; Sat, 03 Apr 2021 20:04:15 -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=aS7BTOUS4yI0Te+6Rp6L2xjw55n5dzdzfUtPSTiLtgs=; b=KScyDhCVR2bGsOPdN4S0xkYvybB2iQ9Bs5eSC19kYeUmUwYKu/Cm3X3NKF7PxnT4sv GRVKXoEqc/xDSpZuV/T+XvaQMFrFALlrh1GHMd34Dsyi9K0vpz79GQ9MR4qlHzPSffUY CfAzo2OGx4IrXARwm8oOwupYoJEYsYV9FEWM9Jrmg6BDHmFDizcLBVg3nfF4v7NfQ05D DbUw2UeNQtd0Z6brsco6RUFaCOAGnnGhZ07GFTSV0EIDB41CWpegbAQuyV7ojYnHvZe1 e96Fd9GbkWfuE7jHFQcM+eTUN6Wl7a8enEq6+urKC96DQhdSdcwQxRbnkJ3hhTb46iw7 zMGg==
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=aS7BTOUS4yI0Te+6Rp6L2xjw55n5dzdzfUtPSTiLtgs=; b=k+OrDG1I8O63R5LEvPJdofYYRi+5r45pPnGZelRPDYEVkd93corpi7IzkveUCKSNBn 9QCCwnBgJFt7efzp1F2t2Wx1E/Enemdl3ADa3GpFhBIjaB2UzTQYXiij5pUjpMacwpJ3 DDiv9Z1DUQb0S5ozekJPYw67yT1OHl7JormtBxSjh7l/31eyo8E8xnBo/vryU4HXExcI MuzrmFYLldVohj0OMZSmr1b43fDXNyARquiO/LU6LHvoKhTsuPURjD5JXgfZAbKD19+L K46cgts2CrK9bUxLVaAkbZtmWNNBfDulTie4HcTHzfx839tHs9EATHISxjt/c8+44kuE eT1g==
X-Gm-Message-State: AOAM533FQICG9qTMCv3Fo2L2ufarTt6svSe4crZzL0dBQMCezvVuas/1 KxkR1CoyJQkPKctIFXrlvtcY27S1RvGZ6LjcznY=
X-Google-Smtp-Source: ABdhPJxAXgg9aNZNj/fs557Zk5Lgltrs2thgiO0mMOUBwwJzdOF0xLTcvaDEpEhZyMmBWuomq37DkhWfKIIxfwTR4wA=
X-Received: by 2002:a19:5005:: with SMTP id e5mr14103585lfb.109.1617505452585; Sat, 03 Apr 2021 20:04:12 -0700 (PDT)
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> <MN2PR05MB66239ACEF39F04C622ED51E6C7799@MN2PR05MB6623.namprd05.prod.outlook.com> <218C08BA-342C-4FDF-A0E9-E91D53485BFD@juniper.net>
In-Reply-To: <218C08BA-342C-4FDF-A0E9-E91D53485BFD@juniper.net>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Sat, 3 Apr 2021 20:04:02 -0700
Message-ID: <CA+RyBmWnsehgfib5kKpc2e8HEZVFfX1wXGwfneY4VxAM6Yg5Dw@mail.gmail.com>
To: Tarek Saad <tsaad=40juniper.net@dmarc.ietf.org>
Cc: John E Drake <jdrake=40juniper.net@dmarc.ietf.org>, "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>, "Joel M. Halpern" <jmh@joelhalpern.com>, "teas@ietf.org" <teas@ietf.org>, Kireeti Kompella <kireeti@juniper.net>, Manish Gupta <manishgupta@juniper.net>
Content-Type: multipart/alternative; boundary="000000000000ec743705bf1cd504"
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/wY0oQ8N90IVlkMRr8buiVVPL8DE>
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: Sun, 04 Apr 2021 03:04:22 -0000

Hi Tarek,
thank you for bringing up these questions. I've been thinking, playing in
my mind with the SLO in a network slice.
I agree that the SLO is for an ordered pair of CEs, and thus it is
unidirectional regardless of the connection matrix. But I think that there
might be a use case for a bidirectional P2P connection, especially if [A,
B] and [B, A] SLOs are identical. Also, a bidirectional P2P connection
might be a useful construct when directions are sharing each other fate
under the protection switchover scenario.

What are your thoughts?

Regards,
Greg

On Sat, Apr 3, 2021 at 7:31 PM Tarek Saad <tsaad=
40juniper.net@dmarc.ietf.org> wrote:

> John/all,
>
>
>
> I can glean the following from this definition. Let me know if
> misinterpreted.
>
>
>
> 1) A connection supporting a network slice is unidirectional. A corollary
> is: SLO(s) are unidirectional too.
>
> 2) From a sending CE, there are only 2 types of connectivity matrices:
>
>    - P2P unidirectional
>    - P2MP unidirectional
>
> Using the above type of matrices on a sending CE, one can realize any of
> network slice connectivity type required – e.g., quoting your example, a
> MP2P can be realized by (N – 1) P2P unidirectional connectivity matrices on
> the sending CEs.
>
>
>
> 3) The SLOs are per matrix type – either P2P or P2MP. Is the definition
> anywhere precluding having multiple connectivity types of matrices from a
> sending CE for the same network slice?(e.g. a mix of (n x P2P) and m x P2MP
> connectivity matrices on the same sending CE for the same network slice)?
>
>
>
> Regards,
>
> Tarek
>
>
>
> On 4/3/21, 4:06 PM, "Teas on behalf of John E Drake" <
> teas-bounces@ietf.org on behalf of jdrake=40juniper.net@dmarc.ietf.org>
> wrote:
>
>
>
>     Hi,
>
>
>
>     As a follow-up to the email, below, that Eric and I sent in late
> February, here is our proposed definition of an IETF Network Slice Service:
>
>
>
>
>
>     IETF Network Slice Service - A service provider instantiates a service
> for a customer which is specified in terms of a set of the customer's
> endpoints (CEs), a set of connectivity matrices (MP2MP, P2MP, MP2P, and
> P2P) between subsets of these CEs and an SLO for each CE sending to each
> connectivity matrix.  I.e.,
>
> in a given IETF network slice service there may be multiple connectivity
> matrices of the same or different type, each connectivity matrix may be
> between a different subset of CEs, and for a given connectivity matrix each
> sending CE has its own SLO and each SLO may be different.  It is also the
> case that a given sending CE may have a different SLO for each connectivity
> matrix to which it is sending.  Note that a given sending CEs's SLO for a
> given connectivity matrix applies between it and each of the receiving CEs
> for that connectivity matrix.
>
>
>
>     This results in the following connectivity matrices:
>
>
>
>              For a MP2MP connectivity matrix with N CEs, each of the N
> sending CEs has its own SLO and each may be different
>
>
>
>              For a P2MP connectivity matrix, there is only one sending CE
> and there is only one SLO
>
>
>
>              For a MP2P connectivity matrix with N CEs, each of the N - 1
> sending CEs has its own SLO and each may be different
>
>
>
>              For a P2P unidirectional connectivity matrix, there is only
> one sending CE and there is only one SLO
>
>
>
>                   For a P2P bidirectional connectivity matrix, there are
> two sending CEs, there are two SLOs, and each may be different
>
>
>
>     If an IETF network slice service customer wants to have hub and spoke
> connectivity between N CEs in order to control how traffic is distributed
> between its CEs, it requests a set of N - 1 P2P unidirectional connectivity
> matrices, each between a sending CE spoke and the hub CE, and a P2MP
> connectivity matrix between the sending CE hub and the spoke CEs.
>
>
>
>     It should be noted that per [RFC4364} section 9 (
> https://datatracker.ietf.org/doc/html/rfc4364#section-9) an IETF network
> slice service customer may actually be its own IETF network slice service
> provider in the same or different provider network.
>
>
>
>     For a given IETF network slice service, the IETF network slice
> customer and the IETF network slice provider agree, on a per-CE basis which
> end of the attachment circuit provides the service demarcation point.  This
> determines whether the attachment circuit is included in any SLOs for the
> subject CE.
>
>
>
>     Yours Irrespectively,
>
>
>
>     John
>
>
>
>
>
>     Juniper Business Use Only
>
>
>
>     > -----Original Message-----
>
>     > From: John E Drake
>
>     > Sent: Tuesday, February 23, 2021 9:53 AM
>
>     > To: mohamed.boucadair@orange.com; 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
>
>     >
>
>     > 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
>
> Juniper Business Use Only
> _______________________________________________
> Teas mailing list
> Teas@ietf.org
> https://www.ietf.org/mailman/listinfo/teas
>