Re: [Teas] New term for the underlay construct used for slice realization

Vishnu Pavan Beeram <vishnupavan@gmail.com> Tue, 17 August 2021 16:11 UTC

Return-Path: <vishnupavan@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 278E83A2188 for <teas@ietfa.amsl.com>; Tue, 17 Aug 2021 09:11:31 -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=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 lONTPpf3C5p1 for <teas@ietfa.amsl.com>; Tue, 17 Aug 2021 09:11:25 -0700 (PDT)
Received: from mail-io1-xd2e.google.com (mail-io1-xd2e.google.com [IPv6:2607:f8b0:4864:20::d2e]) (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 6B8313A2152 for <teas@ietf.org>; Tue, 17 Aug 2021 09:11:22 -0700 (PDT)
Received: by mail-io1-xd2e.google.com with SMTP id q16so26106093ioj.0 for <teas@ietf.org>; Tue, 17 Aug 2021 09:11:22 -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=N1sPigERHgAGipX0KmMcdyB9qqu+lU3giJAPTlztV20=; b=DCwh5IirjSwvvlw/MAvmYQ8ni2qrDKD+LyLmQcQWSik9ipmjSz37UhDqROuyrj2x25 5Lo2CCd6dNUVtNbk+J6i4KnpkrJe7jD1XUbbvjAWc1Sb1vII9vyuQ9LWmuALfNPtOu0U tyYuoUpYJ+pWGRz5RjKKqSJnvOy/um9I6H+Iu9HNDxLvp6K1ZYYM6iZDyY+jFeyEXyvq fseDz2RQvcGo/q3aykesl3R6BptFJdaxBf3mj6vTa/j8kAQ1KILIBLRYhp/gbt2SRJoH in1H/kfjJmCbr9P1Mt3brY+dLciQqHii7vuSYMzrJPsh/eFWU/QoFmiDcrAmYCzRfXPM b04A==
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=N1sPigERHgAGipX0KmMcdyB9qqu+lU3giJAPTlztV20=; b=Eszau98tEzT+KlcttvmlW9UySzJH2rS6GVa7jf9Tego0gXGYE37sWIQh4vDCKjjlzo ug9YRgU0aWhRtRSjJ/cVtHiEqPWn7j3eFqAsV5esGCmy+i/8Y5mqft8c5vm7JlTKOpHu zsgqPEnLTMaG1c2zWCIFrJ+zCBKpOdqyruYuyXfE1ISPfvDbP0UGhBUxm1UvH8u/mKor /qICoOmZlp58ubSQLnZsuly9Kyka7WbFI3nNbItZo70/ZuDjXsvcyW19oiQklqsJHJPa EIk5+BTaj4z2kOfadHtLXSd2dCq/td3vsuNQQks0PzWpa0vwWIbnwIFx0F267pnDcdjD Qx2g==
X-Gm-Message-State: AOAM531Oe+xd/ok6rjfrtUgacNV4H/ZYtzG2iiiAqa0B2aMto4Mxc/Xb vbt4Vnf2y/YsTEbjqzx0h182iCLXtW1hQmsfM5c=
X-Google-Smtp-Source: ABdhPJybJd2N91YsxvnppRj3pQmI2g3VfmPKhShgYO46jMiwMEm8QGXmpqz6Jblgx32pJSy8Gw/7uh+e445/HXNo4do=
X-Received: by 2002:a5d:9f11:: with SMTP id q17mr3271402iot.62.1629216679607; Tue, 17 Aug 2021 09:11:19 -0700 (PDT)
MIME-Version: 1.0
References: <2ae53e44d60548e6ac961ac992615e9b@huawei.com> <BY3PR05MB80819A0E7F8CAFD5BAE79A91C7F79@by3pr05mb8081.namprd05.prod.outlook.com> <33ca73966af4490d84b88c765e183a98@huawei.com> <BY3PR05MB80816B3982271C1FEA86E46CC7F89@by3pr05mb8081.namprd05.prod.outlook.com> <eme7fd3b03-1b2a-47d5-a8f5-b45ecdadeb90@kmak-book2> <00e401d78ee8$5ea55790$1bf006b0$@olddog.co.uk>
In-Reply-To: <00e401d78ee8$5ea55790$1bf006b0$@olddog.co.uk>
From: Vishnu Pavan Beeram <vishnupavan@gmail.com>
Date: Tue, 17 Aug 2021 11:11:08 -0500
Message-ID: <CA+YzgTt-kLPSStbgbWmeKJwO9Zggs+0M04BUUL-E7rg3nZ_zbQ@mail.gmail.com>
To: Adrian Farrel <adrian@olddog.co.uk>
Cc: Kiran Makhijani <kiran.ietf@gmail.com>, John E Drake <jdrake=40juniper.net@dmarc.ietf.org>, "Dongjie (Jimmy)" <jie.dong@huawei.com>, Lizhenbin <lizhenbin@huawei.com>, TEAS WG <teas@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000073422205c9c3914d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/uOekyumRvEgjo5pnDowvbHGI4Wo>
Subject: Re: [Teas] New term for the underlay construct used for slice realization
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, 17 Aug 2021 16:11:38 -0000

** As a WG participant.. **

Adrian, Hi!

>> Why "resource partition"? Well it is a collection of "nodes, links, and
network resources that are marked within the network for use by a set of
network slice traffic flows".

In the definition above, Is “resource partition” a collection of “items”
that are marked within the network for “exclusive” use by a set of network
slice traffic flows (slice aggregate)? Or can multiple slice aggregates use
the same resource partition?

Regards,
-Pavan (as a WG participant)



On Wed, Aug 11, 2021 at 2:38 PM Adrian Farrel <adrian@olddog.co.uk> wrote:

> I wonder whether we can pick this apart and put it back together in a way
> that makes sense.
>
> The customer's view of all this is an "IETF network slice service". I think
> (hope) we are all agreed on this. The customer may ask (in shorthand) for a
> "network slice", but:
> - they are talking about IETF technology, so they asking for an "IETF
> network slice"
> - they actually want behavioural characteristics and have no right to tell
> the operator
>   how to manage the network, so they are asking for an "IETF network slice
> service."
>
> The operator has a bigger set of things to worry about.
>
> 1. At the top of the operator's view is the "IETF network slice service" as
>     requested by the customer. We have this defined already, so nothing
> more
>     to say.
>
> 2. The operator maps the request for a slice service into the "IETF network
>     slice" which is the expression of the service in terms of network
> connectivity
>     in the context of the operator's network. The relationship here is like
> the
>     relationship between the L3SM and L3NM.
>
> 3. At the bottom of their view is an underlying network. The technology of
> this
>    network depends, of course, on the operator's offering, but this is the
> network
>    technology being sliced. It may be an IP network, and MPLS network, an
> OTN,
>    or whatever. I would call this the "Underlay Network." This network may,
> in
>    turn, be built upon an underlay network of the same or a different
> technology,
>    and it may be facilitated through network slicing - but this need not
> concern
>    us here.
>
> 4. That leaves the glue in the middle: the bit that enables the scaling and
> maps
>    the network slice to the network. And I think it is this bit that is
> causing the
>    most debate about terminology. There are some points to consider:
>
>    a. The term "network resources" applies to the bandwidth, queues,
> buffers,
>        etc. available on the links and nodes in the network. That may be
>        extended to refer to whole links and nodes.
>
>    b. The number of IETF network slice services is potentially large and
> the
>        operator needs a mechanism to scale the mapping of services to
>        network resources.
>
>    c. The IETF network slices may be grouped for identical treatment to
>        achieve scaling, where the grouping collects IETF network slices
> with
>        similar SLAs.
>
>    d. It may be that different traffic flows within a single IETF network
> slice
>         have different characteristics. In this case, it may be beneficial
> to group
>         together some of the traffic flows from different slices.
>
>    e. The grouped slices/flows are enabled in the network using network
>         resources assigned for that purpose. The assignment may be anything
>         from a fully-fledged virtual network (such as in ACTN or VPN+),
> through
>         network reserved resources (such as in MPLS-TE), and centrally
>         accounted resources (such as SDN or possible SR), to statistically
>         shared resources.
>
> There seems to be various points for and against 4d. But, it would appear
> that this is an implementation or deployment issue that doesn't change what
> the protocols need to do. So we should probably allow it architecturally,
> or
> at least, not disallow it.
>
> Of course, as Kiran points out, 4c/d/e may be a pass-through. That is, it
> is
> not necessary to implement such groupings either because there are only a
> few slices (which has been the view of some operators) or because the
> network systems can handle the number of slices. And it is in the nature of
> architectures of this sort that all functions can be nulled out without
> loss
> of generality, and we have to recall that the internals of provisioning
> systems may appear as functional blocks in our architectures, but we don't
> compel implementations to adhere to that type of architecture. So I don't
> think we have to worry on that account.
>
> And that brings the question of how we name the resources that are gathered
> in 4e.
>
> I can't decide whether it is helpful to spend time saying why I don't like
> each of the proposed terms. I certainly have things I don't like about (for
> example) "slice aggregate" (because of 4d, which means it is really a
> "slice
> sub-flow aggregate"), and I am not a fan of "VTN" (because of "transport"
> and maybe it is not really a network). But maybe it is better for me to say
> what I think we should call things? I think we have...
>
> -       IETF network slice service (customer view)
> -       IETF network slice (operator view)
> -       Resource partition (delivery mechanism)
> -       Underlay network (network used to support the slice)
>
> Why "resource partition"? Well it is a collection of "nodes, links, and
> network resources that are marked within the network for use by a set of
> network slice traffic flows".
> It is possible that the word "partition" is too strong because it may imply
> to some people that resources in a partition cannot be shared, but I don't
> feel that.
> Softer words than "partition" would be "group", "bundle", "pool", and I
> could live with any of them.
>
> Best,
> Adrian
>
>
> -----Original Message-----
> From: Teas <teas-bounces@ietf.org> On Behalf Of Kiran Makhijani
> Sent: 11 August 2021 16:00
> To: John E Drake <jdrake=40juniper.net@dmarc.ietf.org>rg>; Dongjie (Jimmy)
> <jie.dong@huawei.com>om>; Lizhenbin <lizhenbin@huawei.com>om>; teas@ietf.org
> Subject: Re: [Teas] New term for the underlay construct used for slice
> realization
>
> Hi John, (and all),
>
> Two very basic clarification questions:
> 1. How do we differentiate between  the slice-segments that are
> resource-aware vs those that are not? I had assumed that since a slice
> has an SLO, it will need network resource allocations in some form.
>
> 2. Is it ok to assume that the customer view of slice is an 'IETF
> network slice service' and the 'IETF slice realization' of that service
> in a provider network is raises the question of underlay and overlay
> constructs. Am I right?
> (a) if so, then we are acknowledging  the presence of another layer of
> abstraction (for realization). It could be underlay/overlay or
> aggregate/??. Then the term 'slice aggregate' is better and my
> preference, it is easier to see that different slice-services are
> aggregated into a single construct  in a provider network. Use of
> underlay/overlay are confusing.
> (b) for a leaner provisioning, I would also prefer to see it documented
> that the aggregate is optional and it should be possible to directly map
> a slice-service to physical or real resources in the network.
> specifically useful when a single domain is carving out slices for
> different purposes.
>
> Thanks
> Kiran
>
>
> ------ Original Message ------
> From: "John E Drake" <jdrake=40juniper.net@dmarc.ietf.org>
> To: "Dongjie (Jimmy)" <jie.dong@huawei.com>om>; "Lizhenbin"
> <lizhenbin@huawei.com>om>; "teas@ietf.org" <teas@ietf.org>
> Sent: 8/11/2021 5:38:05 AM
> Subject: Re: [Teas] New term for the underlay construct used for slice
> realization
>
> >Jimmy,
> >
> >Snipped, comments inline.
> >
> >Yours Irrespectively,
> >
> >John
> >
> >
> >Juniper Business Use Only
> >
> >>  -----Original Message-----
> >>  From: Dongjie (Jimmy) <jie.dong@huawei.com>
> >>  Sent: Tuesday, August 10, 2021 11:03 PM
> >>  To: John E Drake <jdrake@juniper.net>et>; Lizhenbin <lizhenbin@huawei.com
> >;
> >>teas@ietf.org
> >>  Subject: RE: New term for the underlay construct used for slice
> realization
> >>
> >>  [External Email. Be cautious of content]
> >>
> >underlay construct for network slice realization bound to
> >>  > > network slice services? That is, is the underlay construct only for
> >>  > > use in network slicing, or should it be generalized for more
> possible uses?
> >>  >
> >>  > [JD] Absolutely yes
> >>
> >>  [Jie] I guess you mean "Yes" to the latter case, which is "it should be
> generalized
> >>  for more possible uses", is my understanding correct?
> >
> >[JD]  Yes to the latter
> >
> >>
> >>  >
> >>  > >
> >>  > > 2.      If the answer to question 1 is YES, should it reflect the
> following
> >>  > > characteristics?
> >>  > >
> >>  > > a.      It is about the underlay
> >>  > > b.      It is about the partitioned resources used to deliver the
> network slice
> >>  > > services
> >>  > > c.      It allows the 1:1, N:1, and 1:N mapping models between the
> network
> >>  > slice
> >>  > > services and the underlay construct. The 1:1 and N:1 mapping may be
> >>  > > straightforward. Does it also make sense to divide the elements or
> >>  > > traffic flows in a single network slice service to carry them in
> >>  > > different
> >>  > underlay constructs?
> >>  >
> >>  > [JD]  Yes to all of the above.  Please see:
> >>  >
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draf
> >>  > t-drake-bess-enhanced-vpn-06__;!!NEt6yMaO-
> >>  gk!TCiJHCZCwFgwpuFoujxVlZ4r9
> >>  > F6mLpE4nJ-9zpqkY-kls-ROxL4C2_xNaR2ImI4$
> >>  > >
> >>  > > Lastly, here are some candidates of the "new term":
> >>  > >
> >>  > > Option 1: The network slice service is called "overlay slice", then
> >>  > > the underlay construct is called "underlay slice".
> >>  > >
> >>  > > Option 2: The network slice service is called "service slice", then
> >>  > > the underlay construct is called "resource slice".
> >>  >
> >>  > [JD]  I don't think we need another term for what we are already
> >>  > calling an 'IETF Network Slice Service'.  Adrian and I are
> considering
> >>  > the term 'resource partition' to describe the partitioning of
> underlay
> >>  > network resources in support of various overlay services such as IETF
> Network
> >>  Slice Services.
> >>  > This is congruent with the ideas expressed in:
> >>  >
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draf
> >>  > t-ietf-spring-resource-aware-segmen__;!!NEt6yMaO-
> >>  gk!TCiJHCZCwFgwpuFouj
> >>  > xVlZ4r9F6mLpE4nJ-9zpqkY-kls-ROxL4C2_xNxEfwaXg$
> >>  > ts-03.  What this allows one to build is an 'partitioned underlay
> >>  > network topology'.
> >>
> >>  [Jie] Agree that here we are talking about the term for the underlay
> construct.
> >>  "Resource partition" captures one of its key characteristics, while IMO
> another
> >>  thing the term needs to reflect is that the resource partition is
> needed
> on a
> >>  subset of the links and nodes (rather than on a single node or link) in
> the physical
> >>  network, which together builds a logical network topology.
> >
> >[JD]  In my initial email, above, I was proposing 'partitioned underlay
> network topology'
> >
> >>
> >>  Best regards,
> >>  Jie
> >>
> >>  >
> >>  > >
> >>  > > Your opinion about these candidates are much appreciated. You may
> >>  > > also propose other new term if it complies with the above two
> points.
> >>  >
> >>  > [JD]  I think you have exceeded your remit.
> >>  >
> >>  > >
> >>  > >
> >>  > >
> >>  > > Best Regards,
> >>  > > Robin
> >>  > >
> >>  > > _______________________________________________
> >>  > > Teas mailing list
> >>  > > Teas@ietf.org
> >>  > >
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/te
> >>  > > as
> >>  > > __;!!N
> >>  > > Et6yMaO-gk!Q0ycOf0ELxT6mG1GbnO4LSL-Q99J4uu7jfdUtBECaI-
> >>  > > O08HqD31TGJciNjuxL2A$
> >>  >
> >>  > _______________________________________________
> >>  > Teas mailing list
> >>  > Teas@ietf.org
> >>  >
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas
> >>  > __;!!NEt6yMaO-gk!TCiJHCZCwFgwpuFoujxVlZ4r9F6mLpE4nJ-9zpqkY-kls-
> >>  ROxL4C2
> >>  > _xNDCrPaNQ$
> >
> >_______________________________________________
> >Teas mailing list
> >Teas@ietf.org
> >https://www.ietf.org/mailman/listinfo/teas
>
> _______________________________________________
> Teas mailing list
> Teas@ietf.org
> https://www.ietf.org/mailman/listinfo/teas
>
> _______________________________________________
> Teas mailing list
> Teas@ietf.org
> https://www.ietf.org/mailman/listinfo/teas
>