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

Adrian Farrel <adrian@olddog.co.uk> Tue, 17 August 2021 16:57 UTC

Return-Path: <adrian@olddog.co.uk>
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 597333A2288 for <teas@ietfa.amsl.com>; Tue, 17 Aug 2021 09:57:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 I5CD3AmrNVTw for <teas@ietfa.amsl.com>; Tue, 17 Aug 2021 09:57:39 -0700 (PDT)
Received: from mta5.iomartmail.com (mta5.iomartmail.com [62.128.193.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3FAC3A2289 for <teas@ietf.org>; Tue, 17 Aug 2021 09:57:38 -0700 (PDT)
Received: from vs4.iomartmail.com (vs4.iomartmail.com [10.12.10.122]) by mta5.iomartmail.com (8.14.4/8.14.4) with ESMTP id 17HGvZKl024603; Tue, 17 Aug 2021 17:57:35 +0100
Received: from vs4.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id B7DF64604A; Tue, 17 Aug 2021 17:57:34 +0100 (BST)
Received: from vs4.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 968BC46050; Tue, 17 Aug 2021 17:57:34 +0100 (BST)
Received: from asmtp2.iomartmail.com (unknown [10.12.10.249]) by vs4.iomartmail.com (Postfix) with ESMTPS; Tue, 17 Aug 2021 17:57:34 +0100 (BST)
Received: from LAPTOPK7AS653V ([84.51.144.29]) (authenticated bits=0) by asmtp2.iomartmail.com (8.14.4/8.14.4) with ESMTP id 17HGvXvd005411 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 17 Aug 2021 17:57:34 +0100
Reply-To: <adrian@olddog.co.uk>
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: "'Vishnu Pavan Beeram'" <vishnupavan@gmail.com>
Cc: "'TEAS WG'" <teas@ietf.org>
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> <CA+YzgTt-kLPSStbgbWmeKJwO9Zggs+0M04BUUL-E7rg3nZ_zbQ@mail.gmail.com>
In-Reply-To: <CA+YzgTt-kLPSStbgbWmeKJwO9Zggs+0M04BUUL-E7rg3nZ_zbQ@mail.gmail.com>
Date: Tue, 17 Aug 2021 17:57:32 +0100
Organization: Old Dog Consulting
Message-ID: <068f01d79388$f9144710$eb3cd530$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0690_01D79391.5ADA83D0"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQH9WPjPe7OLYGFxvp7Om4goMHB+mgIE4X06AmGfN04Br92MDgPTkFzmAN23K4kCYE3+5arDFUnA
Content-Language: en-gb
X-Originating-IP: 84.51.144.29
X-Thinkmail-Auth: adrian@olddog.co.uk
X-TM-AS-GCONF: 00
X-TM-AS-Product-Ver: IMSVA-9.1.0.2034-8.6.0.1018-26352.001
X-TM-AS-Result: No--15.239-10.0-31-10
X-imss-scan-details: No--15.239-10.0-31-10
X-TMASE-Version: IMSVA-9.1.0.2034-8.6.1018-26352.001
X-TMASE-Result: 10--15.239100-10.000000
X-TMASE-MatchedRID: JpK4gqzx2HLaseab4dmKaHoSz3d3UycuVO/udpxTutmwQEC6hpSor/as UbStwoVITf7gOymYF/VYbPLopoBzQtKbU5dPvzKnSpOUbhJ3Z4GykidumpmDjXDAzxVFgG3AOGT V4fFD6yBQpR+9srkRaD2yosu2E9kKGdPtm7hd09KIZNCnu2oWZPuX8LWcyG/u6cNqHK5BsjjFhI xcUCY1/VJAsn89ih94teXjSBMYnmlt4deMXoeltOmbW2nbPz9xGZBcpP9rEHk2HUUd7rI6ITA2E jh8jKIC5T1HpvyeXOROEILBOBemLy9hFU3U5ZOuc+A10JAgABUBiBIm75L197z5DD0+tkb1rMcM K3Nm8dmHnrXtAg8lI+Xtimcp/wuttzBkuk8VO0CepAzyBcy9BgOmy1V2mBEKb0esXyL20NDbbgI 4AuYpV/XuWpt5ue19ilzcm2p6JE/fv015hl5nyMCsfVhCHzOquZnpC1DG3WrszzS6pOc8cvSG/+ sPtZVk+LidURF+DB0KfrbmG+DbUIlvSoUAxubLQ2w7z/HSnbQ+/S8FPnUALIBWXEpi910MUyxW4 vmvLt05OMMyyCn/wTxzAG47ocHfFCgqCG1FODIsrKdgFk7OBhmo7IDg37A4ahH+l6+69lgM6z3i DvziBw+jS+LRpl81WfmMcjcXc0eJmq9nT+IAf4vmf7ubWwK/pwIolABL97f2htYIu4yJeIrkmrf 0Igi/i+TAnPnbtthG2qlFbyxbIgnf5JZh+MGVw2y5G0XnvHLXs+NDjbA5Uf23RzCuz8YULGDmqz fHOB9ezmeoa8MJ86Rea8wUAdQ6Uo0qb2/3Ma1AjzdPjuttgP306Q4zhC4DsjvNV98mpPM5H1L22 kCGSALx8ejWhTZsnaDmH1wbPWX/NfuFgNW3u6E2hbEzB3lBe0VV9A6v4vQiDmbVL857IR+H74bz T2mLM0SU3Ar5uGk=
X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/O4CUVsgM_CRjwXq7dlMDsETu9gg>
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:57:46 -0000

Hi Pavan,

 

> ** As a WG participant.. **

 

** As a humble servant of the WG and pen-holder for the document **

 

> 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?

 

I see that you have determined to introduce a separation between the concept you call a “slice aggregate” and the resources used by that thing.

 

I, on the other hand, had considered that the “resource partition” is the set of resources available for / used by the collection of slice flows, and that there is no need to introduce a separate construct. That is, in one hand you have a set of slices each comprised of one or more traffic flows, and in the other hand you have a network. You map one to the other by associating slice flows with the resources they can use. 

 

There could be a debate about “resource sharing”. That is, when resources in one partition are not being used, can they be “borrowed” by another partition? I suppose the answer is yes, but I wonder how both slices can guarantee the service SLAs if the resources they use are not guaranteed to be available. This is considerably different from borrowing resources for best effort traffic, which can happen in any resource reservation scheme.

 

Regards,

Adrian (as a humble WG participant and pen-holder for the document)

 

> Regards,

> -Pavan (as a WG participant)

 

 

 

On Wed, Aug 11, 2021 at 2:38 PM Adrian Farrel <adrian@olddog.co.uk <mailto: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 <mailto: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 <mailto:40juniper.net@dmarc.ietf.org> >; Dongjie (Jimmy)
<jie.dong@huawei.com <mailto:jie.dong@huawei.com> >; Lizhenbin <lizhenbin@huawei.com <mailto:lizhenbin@huawei.com> >; teas@ietf.org <mailto: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 <mailto:40juniper.net@dmarc.ietf.org> >
To: "Dongjie (Jimmy)" <jie.dong@huawei.com <mailto:jie.dong@huawei.com> >; "Lizhenbin" 
<lizhenbin@huawei.com <mailto:lizhenbin@huawei.com> >; "teas@ietf.org <mailto:teas@ietf.org> " <teas@ietf.org <mailto: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 <mailto:jie.dong@huawei.com> >
>>  Sent: Tuesday, August 10, 2021 11:03 PM
>>  To: John E Drake <jdrake@juniper.net <mailto:jdrake@juniper.net> >; Lizhenbin <lizhenbin@huawei.com <mailto:lizhenbin@huawei.com> >;
>>teas@ietf.org <mailto: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 <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 <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 <mailto:Teas@ietf.org> 
>>  > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/te <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/te> 
>>  > > as
>>  > > __;!!N
>>  > > Et6yMaO-gk!Q0ycOf0ELxT6mG1GbnO4LSL-Q99J4uu7jfdUtBECaI-
>>  > > O08HqD31TGJciNjuxL2A$
>>  >
>>  > _______________________________________________
>>  > Teas mailing list
>>  > Teas@ietf.org <mailto:Teas@ietf.org> 
>>  > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/teas> 
>>  > __;!!NEt6yMaO-gk!TCiJHCZCwFgwpuFoujxVlZ4r9F6mLpE4nJ-9zpqkY-kls-
>>  ROxL4C2
>>  > _xNDCrPaNQ$
>
>_______________________________________________
>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

_______________________________________________
Teas mailing list
Teas@ietf.org <mailto:Teas@ietf.org> 
https://www.ietf.org/mailman/listinfo/teas