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

[Kiran M <[e-mail]>]

Great, look forward to the revised text.

The reason for ‘vaguely resembles slice’ is to influence a different 
kind of thinking that this is the lowest level of a slice, everything is 
built using those - either recursively or hierarchically. I still prefer 
hierarchical over recursion since slices have specific outcomes and 
over-generalization is not necessary, but it is not as important and I 
wouldn’t care either way.

Thanks again,
Kiran


On 8/12/2021 3:10:15 AM, "Adrian Farrel" <[e-mail]> wrote:

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