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

["Joel M. Halpern" <[e-mail]>]

What you describe here seems aligned with what I understand.
When I read your response to Sue, it seemed to say something different. 
Sorry I misunderstood you.

Yours,
Joel

On 4/27/2020 8:43 AM, Rokui, Reza (Nokia - CA/Ottawa) wrote:
> Joel,
> 
> If assume with “customer”, you mean the owner of the transport slice.
> 
> Let me clarify. Transport slice is meaningful in context of an e2e 
> network slice. The e2e network slice has an owner which requested the 
> creation of the e2e network slice.
> 
> For example, customer Uber asks the operator for an e2e network slice 
> for service “autonomous driving”. In addition of creating Other Slices 
> (OS), the Operator eventually creates one or many Transport Slices to 
> satisfy the original e2e network slice.
> 
> In this case, customer Uber is the owner of the e2e network slice (which 
> in turn means he is the owner of the many transport slices) in the network.
> 
> E2E network Slice Orchestrator and Transpot slice Controller provide the 
> full automation on both e2e network slice and transport slices.
> 
> I think the above clarification is aligned with you comment.
> 
> Cheers,
> 
> Reza
> 
> On 2020-04-26, 12:54 AM, "Joel M. Halpern" <[e-mail]> wrote:
> 
>      Reza, I am pretty sure that the custoemr of the Transport Network 
> Slice
> 
>      is not actually the orchestrator.  Yes, the orchestrator gave the
> 
>      orders.  But those orders were to meet someone else needs for the 
> slice.
> 
>        Pretending that the end-to-end slice is the customer of the 
> transport
> 
>      slice seems to be counter-productive.
> 
>      Yours,
> 
>      Joel
> 
>      On 4/26/2020 12:36 AM, Rokui, Reza (Nokia - CA/Ottawa) wrote:
> 
>      > Hi Sue,
> 
>      >
> 
>      > In addition of Bo’s answers, see my comments in line.
> 
>      >
> 
>      > Reza
> 
>      >
> 
>      > *From: *"Wubo (lana)" <[e-mail]>
> 
>      > *Date: *Friday, April 24, 2020 at 5:32 AM
> 
>      > *To: *Susan Hares <[e-mail]>, Reza Rokui 
> <[e-mail]>,
> 
>      > 'Dhruv Dhody' <[e-mail]>, 'Teas-ns-dt'
> 
>      > <[e-mail]>, 'TEAS WG' <[e-mail]>
> 
>      > *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.
> 
>      >
> 
>      > [Reza] The customer of the “Transport slices” is whoever wants to 
> create
> 
>      > the connectivity across transport network as part of e2e network 
> slice.
> 
>      > As an example, in 5G, the customer is called “5G network slice
> 
>      > Orchestrator”.
> 
>      >
> 
>      > Or for use-case of NFV connectivity between data centers, the higher
> 
>      > level system might be the OSS system or a customer portal.
> 
>      >
> 
>      > b) who is running the higher level systems?
> 
>      >
> 
>      > [Reza] It depends on the Transport Slice use-case. In 5G network
> 
>      > slicing, the high system is orchestrator runs by network slice 
> operator
> 
>      > (or customer himself).
> 
>      >
> 
>      > It all depends of the use-case. The details is out of scope of 
> our draft.
> 
>      >
> 
>      > 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./
> 
>      >
> 
>      > [Reza] Note that “Transport Slice Controller” is a FUNCTIONAL block.
> 
>      > Depends on the use-case and operator’s desire,  It might be part of
> 
>      > “Network Controller”. It might also be a separate box owns by 
> network
> 
>      > operator.
> 
>      >
> 
>      > It is possible that the owner of the “Transport Slice Controller” 
> and
> 
>      > “Network Controllers” as not the same network operator.
> 
>      >
> 
>      > 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?
> 
>      >
> 
>      > [Reza]  Referring to Figure-4 of the definition draft below, the
> 
>      > end-customer is the whoever owns the “E2E Network slice”. We call 
> him
> 
>      > the Customer (or Tenant).
> 
>      >
> 
>      > For example in 5G network slicing, an E2E network slice is 
> created for
> 
>      > customer “Uber” for service type “Autonomous Driving.”
> 
>      >
> 
>      > In this case the end-customer is “Uber” which can run and manage 
> its own
> 
>      > e2e network slice if they have agreement with network slice and
> 
>      > transport slice operators.
> 
>      >
> 
>      >             <======================= E2E NS ======================>
> 
>      >
> 
>      >             <-OS1-> <-TS1-> <-TS2-> <-OS2->   ...   <-TSn-> <-OSm->
> 
>      >
> 
>      >            |------------------------------------------------------|
> 
>      >
> 
>      >            |    .--.             .--.                .--.         |
> 
>      >
> 
>      >            |   (    )--.        (    )--.           (    )--.     |
> 
>      >
> 
>      >            |   .'         '     .'         '        .'        '   |
> 
>      >
> 
>      >     [EU-x] |  (  Network-1  )  (  Network-2  ) ... (  Network-p ) 
> |[EU-y]
> 
>      >
> 
>      >            |   `-----------'    `-----------'       `----------'  |
> 
>      >
> 
>      >            |                                                      |
> 
>      >
> 
>      >            |                      Operator-z                      |
> 
>      >
> 
>      >            |------------------------------------------------------|
> 
>      >
> 
>      >     Legend:
> 
>      >
> 
>      >       E2E NS: End-to-end network slice
> 
>      >
> 
>      >       TSn: Transport Slice n
> 
>      >
> 
>      >       OSm: Other Slice m
> 
>      >
> 
>      >       EU-x: End User-x
> 
>      >
> 
>      >       EU-y: End User-y
> 
>      >
> 
>      > 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.
> 
>      >
> 
>      > [Reza] Referring to the example above, if with “paying customer” you
> 
>      > means customer “Uber”, the answer is YES. But since Uber can sell 
> the
> 
>      > usage of this network slice to hundreds of drivers, if with “paying
> 
>      > customers” you means these drivers, the answer is NO.
> 
>      >
> 
>      > /[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.///
> 
>      >
> 
>      > [Reza] Endpoints of Transport slice are the abstract entities. They
> 
>      > could be the application software for example or a physical node, 
> the
> 
>      > logical node or interface or any other component which needs 
> connectivity.
> 
>      >
> 
>      > To realize the transport slice you can use for example L2SM or L3SM
> 
>      > between multiple Sites. For example if you want to create a 
> Transport
> 
>      > Slice between a VNF and application, you can realize it using 
> L2SM or
> 
>      > L3SM across IP network between multipole Sites which might be 
> different
> 
>      > from Transport Slice Endpoints.
> 
>      >
> 
>      > +------+
> 
>      >
> 
>      > |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.///
> 
>      >
> 
>      > [Reza] During multiple NSDT meetings, a few people asked why 
> authors of
> 
>      > NBI draft did not augment Network model yang (RFC 8345) . Slice 
> 15 is
> 
>      > included as completeness to outline the reasons and depict the 
> potential
> 
>      > augmentation. Note that authors desired is not to use this model. We
> 
>      > stated the reason in Slide 15.
> 
>      >
> 
>      > 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]
> 
>      > <mailto:[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]
> 
>      > 
> <mailto:[e-mail][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]
> 
>      > <mailto:[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] <mailto:[e-mail]>
> 
>      >
> 
>      >      > https://www.ietf.org/mailman/listinfo/teas
> 
>      >
> 
>      >      _______________________________________________
> 
>      >
> 
>      >      Teas mailing list
> 
>      >
> 
>      > [e-mail] <mailto:[e-mail]>
> 
>      >
> 
>      > https://www.ietf.org/mailman/listinfo/teas
> 
>      >
> 
>      > _______________________________________________
> 
>      >
> 
>      > Teas mailing list
> 
>      >
> 
>      > [e-mail] <mailto:[e-mail]>
> 
>      >
> 
>      > https://www.ietf.org/mailman/listinfo/teas
> 
>      >
> 
>      >
> 
>      > _______________________________________________
> 
>      > Teas mailing list
> 
>      > [e-mail]
> 
>      > https://www.ietf.org/mailman/listinfo/teas
> 
>      >
>