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

[Adrian Farrel <[e-mail]>]

Hi Kiran,

You make an important observation about functional architectures. I recall having a similar discussion back in around 2004 in Geneva as we worked on G.7712 and associated Recommendations.

The points are:
- Functional components do not need to be implemented as separate
   software components.
- Where functional components are bundled together in software, they
   do not need to implement the formal functional interfaces between
   the functional components.
- Where a function is "not needed" in an implementation or deployment
   it may be present as a "null" or "pass-through" function, but it actually
   doesn't need to be present at all.

Thus, while it is possible to treat a functional architecture as a high level design for a software implementation, it may not necessarily be the best approach.

Now, to your specific points...

> In this 4-tier architecture (for the sake of convenience), few things 
> could be documented after clarification:
>
> 1) is it mandatory that operator must have an 'IETF Network slice 
> instance' to realize an IETF network slice service?

As above, no it is not mandatory. Just as in L3VPN, an operator could map direct from a VPN service request at the NBI (using L3SM) to programming of the forwarding plane.

> - One of the things we discussed early on was that it should be 
>   possible to map a customer’s network slice request even when the 
>   operator does not have slice-infrastructure. This is why Southbound 
>   interface had lot of discussions on using existing data models. Should 
>   we now redefine what a SBI would be? Is it between 2nd and 3rd tier? 
>   Should architecture allow 1st to 3rd? Since resource-partitioning is an 
>   important part of slices should we name the interface between 3rd to
>   4th tier?

Well, let's be really careful about the term "SBI". Southbound to what?
An Orchestrator may have an SBI to a Network Slice Controller.
A Network Slice Controller may an SBI to a Network Controller.
And a Network Controller may have an SBI to the devices.
draft-contreras-teas-slice-controller-models may give some good context for this.

I'm setting aside "even when the operator does not have slice-infrastructure" since I don't know what it means. But I will say that it entirely possible for an operator to map direct from an IETF Network Slice Service request to "programming" the data plane. I believe that is possible with this 4-layer functional model. Furthermore, I believe the functional model allows any or all forms of "pass-through". That is, to repeat myself, it is a functional model not a mandatory implementation guide (notwithstanding RFC 8962, there is no Protocol Police!).

> 2) in order to scale the slices, hierarchical slices were defined. The 
>   stitching could be done horizontally or vertically over the 
>   resource-partitions. are they still needed in this architecture.

Architectures are recursive. That recursion may be transparent or visible. Hierarchical slicing "comes for free".

Lateral stitching of slices is, of course, more complicated because it requires coordination between adjacent "domains". But the architecture should easily allow this.

> In my mind, what you call a resource partition is nothing but an 
> abstraction of connected network resources (vaguely resembles the 
> definition of slice, isn’t it?). What happens above that is an 
> orchestration on different slice segments to produce the desired 
> effects.

"Orchestration" is a key word.

I think "vaguely resembles the definition of a slice" is not completely a surprise because what is going on is a marshalling of resources to support a slice.

Is it an abstraction? No! It is actually the identification of specific resources. I think the network slice, itself, (the 2nd layer down) is the abstraction.

> So I think, with this architecture we would need to clean up/edit the 
> text on 3 items in the document - SBI, optionality of 2nd tier (if you 
> agree - related to your 4c/d/e), section on hierarchical structure.

I agree that cleaning of text is what this is all about. A lot of the text is still in its inherited form and needs work.
Currently the document mainly uses "SBI" to mean the device-facing interface. But it also talks about the "NSC SBI", I find the term SBI over-used, and I think we can tidy that up.
Yes, it should be clear about the fact that this is a functional architecture and that you don't have to implement it like that.
Yes we should have some text (although probably not a lot) on the fact that you can recurse the architecture and that you can orchestrate and stitch across adjacent domains/networks.

Cheers,
Adrian


On 8/11/2021 12:37:49 PM, "Adrian Farrel" <[e-mail]> 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 <[e-mail]> On Behalf Of Kiran Makhijani
>Sent: 11 August 2021 16:00
>To: John E Drake <jdrake=[e-mail]>; Dongjie (Jimmy)
><[e-mail]>; Lizhenbin <[e-mail]>; [e-mail]
>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=[e-mail]>
>To: "Dongjie (Jimmy)" <[e-mail]>; "Lizhenbin"
><[e-mail]>; "[e-mail]" <[e-mail]>
>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) <[e-mail]>
>>>   Sent: Tuesday, August 10, 2021 11:03 PM
>>>   To: John E Drake <[e-mail]>; Lizhenbin <[e-mail]>;
>>>[e-mail]
>>>   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
>>>   > > [e-mail]
>>>   > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/te
>>>   > > as
>>>   > > __;!!N
>>>   > > Et6yMaO-gk!Q0ycOf0ELxT6mG1GbnO4LSL-Q99J4uu7jfdUtBECaI-
>>>   > > O08HqD31TGJciNjuxL2A$
>>>   >
>>>   > _______________________________________________
>>>   > Teas mailing list
>>>   > [e-mail]
>>>   > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas
>>>   > __;!!NEt6yMaO-gk!TCiJHCZCwFgwpuFoujxVlZ4r9F6mLpE4nJ-9zpqkY-kls-
>>>   ROxL4C2
>>>   > _xNDCrPaNQ$
>>
>>_______________________________________________
>>Teas mailing list
>>[e-mail]
>>https://www.ietf.org/mailman/listinfo/teas
>
>_______________________________________________
>Teas mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/teas
>