Re: [Teas] Upcoming changes to draft-ietf-teas-ietf-network-slices

[Gyan Mishra <[e-mail]>]

Hi Adrian

Excellent  summarization !

Kind Regards

Gyan

On Wed, Mar 2, 2022 at 4:15 PM Adrian Farrel <[e-mail]> wrote:

> Hi,
>
>
>
> I am just about to post -06 of this document. None of the changes, below
> should be a surprise. 1, 3, and 4 were talked about at IETF-112. 2 is just
> fine-tuning the text already in -05.
>
>
>
>    1. Deprecating NBI/SBI
>
>
>
> Per the discussion at IETF-112 and following on from Med’s comments, I am
> replacing “NBI” with “IETF Network Slice Service Interface”, and “SBI” with
> “Network Configuration Interface”.
>
>
>
> These are abstract terms, and the implementations might choose to use NSSM
> and NSNM. They might also choose to stick with NBI, but I personally find
> that term ambiguous in the greater scheme of things.
>
>
>
>    1. Clarifying the relationships between slices, connectivity
>    constructs, SLOs/SLEs, and network resource partitions.
>
>
>
> Recent reviews and discussions of draft-bestbar-teas-ns-packet have made
> it clear that the current text is not sufficiently unambiguous. Although I
> know what I meant, the text is open to interpretation and needs to be
> tightened up.
>
>
>
> The relationships are easy to express:
>
>
>
>    - A network slice is a service requested by / provided for the customer
>    - The network slice service is expressed in terms of one or more
>    connectivity constructs.
>    An implementation or operator is free to limit the number of
>    connectivity constructs in a slice to exactly one.
>    - Each connectivity construct has a set of SLOs and SLEs.
>    The set does not need to be the same for every connectivity construct
>    in the slice.
>    An implementation or operator is free to require that all connectivity
>    constructs in a slice have the same set of SLOs and SLEs.
>    - One or more connectivity constructs from one or more slices are
>    mapped to a set of network resources called a Network Resource Partition
>    (NRP).
>    One connectivity construct is only mapped to one NRP.
>    An NRP may be chosen because of its ability to support a specific set
>    of SLOs and SLEs, or its ability to support particular connectivity types.
>    An implementation or operator is free to map each connectivity
>    construct to a separate NRP, although there may be scaling implications
>    depending on the solution implemented.
>    Thus, the connectivity constructs in one slice may be mapped to one or
>    more NRPs.
>    By implication from the above, an implementation or operator is free
>    to map all the connectivity constructs in a slice to a single NRP and to
>    not share that NRP with connectivity constructs from another slice.
>    - An NRP is simply a collection of (reserved) resources extracted from
>    the underlying physical network.
>    The process of determining the NRP may be made easier if the physical
>    network topology is first filtered into a Filter Topology in order to be
>    aware of the subset of network resources that are suitable for specific
>    NRPs.
>
>
>
>    1. What to call an end point
>
>
>
> During IETF-112 we spotted several overlapping terms (CE, end-point, NSE,
> maybe PE) and decided that the more generic term “Service Demarcation
> Point” should be used.
>
>
>
> This will help remove the confusion about where the service begins and
> ends, allowing the existing text that enumerates the options to not get
> blurred by other text in the document. Of course, CEs and PEs still exist
> and need to be mentioned, but the service demarcation point term allows us
> to be generic without forcing any one of the four implementation options
> already described in the text and Figure 1.
>
>
>
>    1. General editorial pass to clean up spelling and language use
>
>
>
> Best,
>
> Adrian
>
>
>
>
> _______________________________________________
> Teas mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/teas
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [e-mail] <[e-mail]>*



*M 301 502-1347*