Re: [Teas-ns-dt] draft-liu-teas-transport-network-slice-yang-00

[Xufeng Liu <[e-mail]>]

Hi Reza,

Sorry for the delayed response because of traveling. Thanks for reviewing
and the feedback. Put some replies in-line below.

Best,
- Xufeng

On Tue, Nov 12, 2019 at 10:10 AM Rokui, Reza (Nokia - CA/Ottawa) <
[e-mail]> wrote:

> Hi Xufeng, Jeff et al.,
>
>
>
> Thanks for putting together the first version of the following draft.
>
>    - Transport Network Slice YANG Data Model
>    (draft-liu-teas-transport-network-slice-yang-00)
>
>
>
> A few comments:
>
>
>
>    - I would like to be part of this draft as a co-author.
>
> We appreciate your contributions.

>
>    -
>    - The title of the draft is “Transport Network Slice”. As per
>    https://tools.ietf.org/html/draft-nsdt-teas-transport-slice-definition-00,
>    my suggestion is to use only “*Transport Slice”* since the term
>    “network slice” has a specifc meaning. IETF is going to address only the
>    “Transport slice”. We shall finalize our terminology and hopefully we can
>    do this with f2f meeting next week.
>
> Right. We will align with the consensus once it is reached in the DT and
working group. For now, there are still different opinions.

>
>    -
>    - IMHO, the model has a fundamental issue of mixing the definition of
>    the “Transport Slice” with its implementation. As per the latest slides
>    from Jari from last meeting, we need to do:
>       - Specify a *northbound interface* whereby a higher level system
>       can request connections with specific characteristics (perhaps as a data
>       model)
>
> Every interface is between two parties (a provider and a client). In this
case, the higher-level system is the client. When the client sends a
request to the provider, the model specifies the syntax and the semantics.
Any usable interface needs to have feedback for any request. This model
needs to include the result status and additional useful state information.
You could say that some such information is implementation related, but it
is something that a usable interface must have.

>
>    -
>       - Specify a *mapping* how northbound request maps to IETF tech
>       (possibly)
>
> The two examples show how two different technologies are mapped and
utilized to satisfy the clients' requests. Since the model contains useful
intended configuration and state information (above). The client can drill
down into lower layers and technologies of the system in the provider
system. The references to other models are provided so that the client can
retrieve the information specific to any applied underlying technology.
This methodology is how current TE models and ACTN interfaces are put
together to provide feature-rich capabilities.

>
>    -
>
>
>
>    - More details on this
>
> We should do the mapping to the ACTN architecture framework here.

>
>    -
>       - As mentioned in
>       https://tools.ietf.org/html/draft-rokui-5g-transport-slice-00, and
>       shown below, the “Transport Slice Data Model” will address (1). This model
>       shall be abstract where a higher level system (e.g. e2e network slice
>       orchestrator) can request connections with specific characteristics
>       - Number (2) below is the Mapping needed from northbound to any
>       IETF model
>       - Number (3) is IETF Services/Tunnels/Paths models
>
>
>
>     |------------------------------------------|
>
>     |     A Hight level system                 |
>
>     |    (e2e network slice orchestrator)      |
>
>     |------------------------------------------|
>
>                           | (1)
>
>                           |
>
>                           V
>
>     |------------------------------------------|
>
>     |         Transport Slice Controller       | (2)
>
>     |------------------------------------------|
>
>                           | (3)
>
>                           |
>
>                           V
>
>
>
>    - The “Transport Slice YANG Data Model” shall also address the
>    monitoring and optimization of the transport slices.
>    - The “Transport Slice YANG Data Model” shall also contains some
>    information about the higher level system which help for assurance. For
>    example in case of 5G network slices, these information can be the e2e
>    network slice id (aka S-NSSAI), customer (aka tenant), service type (e.g.
>    CCTV, URLLC, eMBB etc.) and so on.
>
>
>
> We can discuss these during our f2f meeting next week.
>

Sure we will discuss further on these and other topics.


>
> Cheers,
>
> Reza
>
>
>