Re: [Teas] draft-wd-teas-transport-slice-yang-01 - Mike question

[Dhruv Dhody <[e-mail]>]

Hi Sue,


On Fri, Apr 24, 2020 at 5:03 PM Susan Hares <[e-mail]> wrote:
>
> Bo:
>
>
>
> Just to repeat your answers along with Dhruv’s answers:
>
>
>
> 1)  You are not operating at the customer level, but an interior network model

I think its best to point to the definition draft -
https://tools.ietf.org/html/draft-nsdt-teas-transport-slice-definition-01#section-5.2;
"interior network" might be a little subjective :)

TS-NBI is from the point of view of the service and thus should hide
the network realization details on how the slice is mapped to the
network.

>
> 2) You elected not to use the IETF topology model and create your own model
>

Yes

>          a)because you feel your abstraction is better because ______  (I still cannot tell)
>

It follows the design philosophy of the IETF service models - as this
is the customer's view (instead of the network's view), we hide any
mapping details of how this slice maps to the underlay network
topology (similar to L3SM). Plus we find it easier to define a logical
TS-endpoint v/s augmenting it at termination-point.



>          b) decided the ACTN model is just one model
>

No, do you mean ietf-vn model instead?

>          c) TE topology model does not fit because it has too much _____ ( I still cannot tell)
>
First answer to a) applies here as well and we find it is better
suited for TS-SBI as a transport slice realization (how the slice is
realized in the network).

>         d) you answered the question about ephemeral  - that is allocated resources
>
>             I assume you mean required resources that must always be configured.
>

The current focus is on configuration and monitoring. But with NMDA do
we need something else in our model?

>
>
> 3) You mentioned other people from DT have asked the same question I have.
>

yes, mainly on augmenting ietf-network model. The current I-D captures
the preference of the authors for an independent model.

Thanks!
Dhruv

>
>
> Thank you responding to my  email,
>
> Sue
>
>
>
>
>
> Your answers from below – in case I missed something.
>
> [Bo] This figure is from the Transport slice definition draft, where the customer is the user who uses the slice.
>
> [Bo] No to the above questions, The TSC is unaware of slice customers. And what I want to highlight is that the consumer in this draft refers to the higher level management system
>
> [Bo] This draft has been discussed several times at DT. During the discussion, some members suggested to reuse the existing IETF topology definition since the definition draft defines TS as a logical topology connecting a number of endpoints.
>
> [Bo] No, the slice model is an abstraction of resources that are dedicated allocated or shared in the Underlay layer. For example, a Transport slice could be the aggregation of interfaces, VPNs, and tunnels from entry to exit endpoint
>
>
>
>
>
> From: Wubo (lana) [mailto:[e-mail]]
> Sent: Friday, April 24, 2020 5:33 AM
> To: Susan Hares; 'Rokui, Reza (Nokia - CA/Ottawa)'; 'Dhruv Dhody'; 'Teas-ns-dt'; 'TEAS WG'
> Subject: Re: [Teas] draft-wd-teas-transport-slice-yang-01 - Mike question
>
>
>
> Hi Sue,
>
>
>
> Many thanks for the detailed comments.
>
> Let me answer first and see if my co-author has anything to add.
>
> Please see inline below.
>
>
>
> Thanks,
>
> Bo
>
> -----邮件原件-----
> 发件人: Teas [mailto:[e-mail]] 代表 Susan Hares
> 发送时间: 2020年4月24日 2:02
> 收件人: 'Rokui, Reza (Nokia - CA/Ottawa)' <[e-mail]>; 'Dhruv Dhody' <[e-mail]>; 'Teas-ns-dt' <[e-mail]>; 'TEAS WG' <[e-mail]>
> 主题: Re: [Teas] draft-wd-teas-transport-slice-yang-01 - Mike question
>
>
>
> Reza:
>
>
>
> Your answer to my request for clarification of your slides seems to have skipped a step.
>
>  I asked for clarification, and you stated you prepared a clear set of slides
>
> (smile)
>
> A clarification question indicates your slides were unclear to me.
>
> Perhaps you would kindly explain a few things to me.
>
>
>
> Sue
>
> ----------------
>
>
>
> Question 1)  Your slides stated
>
>
>
> Customer level
>
>     |
>
> Higher level systems
>
>   |  (your model is here)
>
> Transport slide controller
>
> |
>
> Network controllers
>
> [Bo] This figure is from the Transport slice definition draft, where the customer is the user who uses the slice.
>
>
>
> On slide 2,
>
> a) who is the customer?
>
> [Bo]The customer here refers to the Higher level systems.
>
> b) who is running the higher level systems?
>
> c) who is running transport slide controller
>
> [Bo] As defined in the definition draft, it is quite possible that the higher level systems and the TSC are not in the same management domain.
>
>
>
> Your text says in section 3, page
>
>   "The intention of the transport slice model is to allow the consumers,
>
>    e.g.  A higher level management system, to request and monitor
>
>    transport slices.  In particular, the model allows consumers to
>
>    operate in an abstract, technology-agnostic manner, with
>
>    implementation details hidden. "
>
>
>
> Is the end-customer directly running the system?
>
> Is this directly linked to the certified paying customer?
>
> Or is the customer really the person on the inside of the 5G provider configuring it.
>
> [Bo] No to the above questions, The TSC is unaware of slice customers. And what I want to highlight is that the consumer in this draft refers to the higher level management system.
>
>
>
> Question-2)  If you are using the TS-Endpoint as an entry point (slide  4) How is this conceptually different that the site endpoints defined by
>
> RFC8466 (section 5.5), RFC8049 (section 6.5 and 6.6)?
>
>
>
> In the L2SM and l3SM models, you sites with:
>
> a) end-to-end p2p connectivity
>
> b) ~logical LANs (multiple connections through a single transport)?
>
> c) multiple VPNs (translated to multiple Transport slides connectivity)
>
> [Bo]
>
> In L2SM and L3SM, 'site' is defined to configure links between CE and PE.
>
> In the context of transport slices, it is assumed that the connection between the customer site and transport network has been established,
>
> and multiple slices can share the connection.
>
>
>
> Additionally, the higher level system may use different endpoints, which may be the termination point on the CE side or the TP on the PE side.
>
> +------+
>
> |CE  TS1EP--+
>
> +------+      |
>
>             |
>
>             |   +--------------+
>
> +------+      +-----+         |
>
> |CE  TS2EP      |     PE  |
>
> |    +----------------+         |
>
> |    TS3EP      |         |
>
> +------+          +-------------+
>
>
>
> +------+
>
> |CE  +--------+
>
> +------+      |
>
>             |
>
>             |  +----------------+
>
> +------+      +-TS1EP       |
>
> |CE  |        TS2EP  PE   |
>
> |    +----------+             |
>
> |    |        TS3EP       |
>
> +------+          +-------------- +
>
>
>
> Question-3:  Slide 15 -  TS-NBI as Augmenting network model (RFC8345)
>
>
>
> The slide makes it appear as you model TS-NBI as a network layer connection.
>
> Is this correct?
>
> [Bo] No, the authors prefer TS-NBI as a customer-view connection for Higher level systems.
>
>
>
> If you are modeling as network connection, Why?
>
> If you are modeling this as a customer level,  then why is this slide (which you claim is "clear") is modeling this as dependent on a link rather than connecting as a customer connection from an upper logical layer (connecting multiple connections) to one of possible links.
>
>
>
> If you are modeling this as a customer level slides,  13 and 14 also seems to misaligned.  You are on top of these models utilizing what portions you wish.
>
> [Bo] This draft has been discussed several times at DT. During the discussion, some members suggested to reuse the existing IETF topology definition since the definition draft defines TS as a logical topology connecting a number of endpoints.
>
>
>
>
>
> Question 4:  Are these models ephemeral?
>
> [Bo] No, the slice model is an abstraction of resources that are dedicated allocated or shared in the Underlay layer. For example, a Transport slice could be the aggregation of interfaces, VPNs, and tunnels from entry to exit endpoint.
>
>
>
> Again - thank you for answering these questions.
>
>
>
>
>
>
>
> -----Original Message-----
>
> From: Rokui, Reza (Nokia - CA/Ottawa) [mailto:[e-mail]]
>
> Sent: Thursday, April 23, 2020 1:01 PM
>
> To: Dhruv Dhody; Susan Hares; Teas-ns-dt; TEAS WG ([e-mail])
>
> Cc: Rokui, Reza (Nokia - CA/Ottawa)
>
> Subject: Re: [Teas] draft-wd-teas-transport-slice-yang-01 - Mike question
>
>
>
> Thanks Sue for you comment and Dhruv for your response. We prepared a good set of slides to capture the rational behind our model and why we did not use VN or RFC 8345 models although we used the design concept from both yang models.
>
> As Dhruv pointed out, we add them to appendix since they are very important aspects.
>
>
>
> Cheers,
>
> Reza
>
>
>
>
>
> On 2020-04-23, 12:22 PM, "Teas on behalf of Dhruv Dhody" <[e-mail] on behalf of [e-mail]> wrote:
>
>
>
>     Hi Sue,
>
>
>
>     Thanks for your email. Yes, our work for TS-NBI is closer to the
>
>     customer service models and in fact uses the same design philosophy by
>
>     creating an independent model with a customer view (of the slice)
>
>     rather than the network view. The network view would be useful for the
>
>     slice realization by the TS-controller as described in the framework
>
>     draft.
>
>
>
>     It would be good idea to capture this discussion in the Appendix of
>
>     our I-D. Further, there are some technical challenges such as modeling
>
>     TS-endoint as an augmentation of a termination point in RFC8345; our
>
>     preference is to maintain TS-endpoint to be a logical identifier with
>
>     either CE-side details or PE-side details or both.
>
>
>
>     Thanks!
>
>     Dhruv
>
>
>
>     On Thu, Apr 23, 2020 at 9:16 PM Susan Hares <[e-mail]> wrote:
>
>     >
>
>     > Bo Wu, Dhruv, Reza, and Liuyan:
>
>     >
>
>     >
>
>     >
>
>     > Thank you for your presentation in TEAS on the draft-wd-teas-transport-slice-yang-01.    I had hoped to ask this question on the mike:
>
>     >
>
>     >
>
>     >
>
>     > “Would you provide more details on why you felt the base model (RFC8345) was not appropriate to utilize? “
>
>     >
>
>     >
>
>     >
>
>     > It seems to me that you are proposing a customer level model  to monitor and set-up the traffic slicing?    RFC8345 provides a base model with a customer level.   The models L2SM and L3SM provided a customer level for general VPNs.   You seem to be providing the equivalent for a traffic slicing.
>
>     >
>
>     >
>
>     >
>
>     > If you are looking to utilize the base model then providing a customer level model is a good idea.  It is much cleaner than mixing it with the network layer.  When network slicing was starting its work, I prepared this suggestion as part of the first BOF.
>
>     >
>
>     >
>
>     >
>
>     > Would you do me a favor in your presentation of “customer level”,  would you careful distinguish between the following customer levels?
>
>     >
>
>     >
>
>     >
>
>     > End –customer ---
>
>     >
>
>     >         |
>
>     >
>
>     > VPN customer (person/tools configuring)
>
>     >
>
>     > Service
>
>     >
>
>     >     |
>
>     >
>
>     > VPN of network
>
>     >
>
>     >     |
>
>     >
>
>     > Base network
>
>     >
>
>     >
>
>     >
>
>     > Thank you!
>
>     >
>
>     >
>
>     >
>
>     > The I2RS WG (which chair) standardized RFC8345.   Your application was one of the ones that caused us to work through the model and the issues with yang.
>
>     >
>
>     >
>
>     >
>
>     > I’m excited to see your work in TEAS.
>
>     >
>
>     >
>
>     >
>
>     > Sue
>
>     >
>
>     >
>
>     >
>
>     >
>
>     >
>
>     >
>
>     >
>
>     > _______________________________________________
>
>     > Teas mailing list
>
>     > [e-mail]
>
>     > https://www.ietf.org/mailman/listinfo/teas
>
>
>
>     _______________________________________________
>
>     Teas mailing list
>
>     [e-mail]
>
>     https://www.ietf.org/mailman/listinfo/teas
>
>
>
>
>
> _______________________________________________
>
> Teas mailing list
>
> [e-mail]
>
> https://www.ietf.org/mailman/listinfo/teas
>
> _______________________________________________
> Teas mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/teas