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

From: "Wubo (lana)" <[email-masked]>
Date: Fri, 24 Apr 2020 09:32:32 +0000

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:[email-masked]] 代表 Susan Hares
发送时间: 2020年4月24日 2:02
收件人: 'Rokui, Reza (Nokia - CA/Ottawa)' <[email-masked]>; 'Dhruv Dhody' <[email-masked]>; 'Teas-ns-dt' <[email-masked]>; 'TEAS WG' <[email-masked]>
主题: 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:[email-masked]]

Sent: Thursday, April 23, 2020 1:01 PM

To: Dhruv Dhody; Susan Hares; Teas-ns-dt; TEAS WG ([email-masked]<mailto:[email-masked]>)

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" <[email-masked] on behalf of [email-masked]<mailto:[email-masked][email-masked]>> 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 <[email-masked]<mailto:[email-masked]>> 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

    > [email-masked]<mailto:[email-masked]>

    > https://www.ietf.org/mailman/listinfo/teas

    _______________________________________________

    Teas mailing list

    [email-masked]<mailto:[email-masked]>

    https://www.ietf.org/mailman/listinfo/teas

_______________________________________________

Teas mailing list

[email-masked]<mailto:[email-masked]>

https://www.ietf.org/mailman/listinfo/teas

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 24 Apr 2020 07:32:41 -0400

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

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

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

         b) decided the ACTN model is just one model 

         c) TE topology model does not fit because it has too much _____ ( I still cannot tell)  

        d) you answered the question about ephemeral  - that is allocated resources 

            I assume you mean required resources that must always be configured. 

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

Thank you responding to my  email, 

Sue 

Your answers from below – in case I missed something. 

[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] 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:[email-masked]] 
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,

Please see inline below.

Thanks,

Bo

-----邮件原件-----
发件人: Teas [mailto:[email-masked]] 代表 Susan Hares
发送时间: 2020年4月24日 2:02
收件人: 'Rokui, Reza (Nokia - CA/Ottawa)' <[email-masked]>; 'Dhruv Dhody' <[email-masked]>; 'Teas-ns-dt' <[email-masked]>; 'TEAS WG' <[email-masked]>
主题: Re: [Teas] draft-wd-teas-transport-slice-yang-01 - Mike question

Reza:

(smile)

Sue

----------------

Customer level 

    |

Higher level systems

  |  (your model is here)

|

Network controllers

On slide 2,

a) who is the customer? 

[Bo] 

+------+

|CE  TS1EP--+

+------+      |

            |

            |   +--------------+

+------+      +-----+         |

|CE  TS2EP      |     PE  |

|    +----------------+         |

|    TS3EP      |         |

+------+          +-------------+

+------+

|CE  +--------+

+------+      |

            |

            |  +----------------+

+------+      +-TS1EP       |

|CE  |        TS2EP  PE   |

|    +----------+             |

|    |        TS3EP       |

Is this correct? 

 

 

-----Original Message-----

From: Rokui, Reza (Nokia - CA/Ottawa) [ <mailto:[email-masked]> mailto:[email-masked]]

To: Dhruv Dhody; Susan Hares; Teas-ns-dt; TEAS WG ( <mailto:[email-masked]> [email-masked])

Cheers,

Reza

On 2020-04-23, 12:22 PM, "Teas on behalf of Dhruv Dhody" < <mailto:[email-masked][email-masked]> [email-masked] on behalf of [email-masked]> wrote:

    Hi Sue,

    draft.

    Thanks!

    Dhruv

    On Thu, Apr 23, 2020 at 9:16 PM Susan Hares < <mailto:[email-masked]> [email-masked]> wrote:

    >  <mailto:[email-masked]> [email-masked]

    >  <https://www.ietf.org/mailman/listinfo/teas> https://www.ietf.org/mailman/listinfo/teas

    Teas mailing list

     <mailto:[email-masked]> [email-masked]

     <https://www.ietf.org/mailman/listinfo/teas> https://www.ietf.org/mailman/listinfo/teas

Teas mailing list

 <mailto:[email-masked]> [email-masked]

 <https://www.ietf.org/mailman/listinfo/teas> https://www.ietf.org/mailman/listinfo/teas

---

From: Dhruv Dhody <[email-masked]>
Date: Fri, 24 Apr 2020 23:12:43 +0530

Hi Sue,

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

>             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

> To: Dhruv Dhody; Susan Hares; Teas-ns-dt; TEAS WG ([email-masked])
>
> On 2020-04-23, 12:22 PM, "Teas on behalf of Dhruv Dhody" <[email-masked] on behalf of [email-masked]> wrote:
>
>
>
>     Hi Sue,
>
>
>
>     On Thu, Apr 23, 2020 at 9:16 PM Susan Hares <[email-masked]> wrote:
>
>     >
>
>     > [email-masked]
>     [email-masked]
> [email-masked]
> [email-masked]

---

From: "Rokui, Reza (Nokia - CA/Ottawa)" <[email-masked]>
Date: Sun, 26 Apr 2020 04:36:07 +0000

Hi Sue,

In addition of Bo’s answers, see my comments in line.

Reza

From: "Wubo (lana)" <[email-masked]>
Date: Friday, April 24, 2020 at 5:32 AM
To: Susan Hares <[email-masked]>, Reza Rokui <[email-masked]>, 'Dhruv Dhody' <[email-masked]>, 'Teas-ns-dt' <[email-masked]>, 'TEAS WG' <[email-masked]>
Subject: Re: [Teas] draft-wd-teas-transport-slice-yang-01 - Mike question

Hi Sue,

Please see inline below.

Thanks,

Bo

-----邮件原件-----
发件人: Teas [mailto:[email-masked]] 代表 Susan Hares
发送时间: 2020年4月24日 2:02
收件人: 'Rokui, Reza (Nokia - CA/Ottawa)' <[email-masked]>; 'Dhruv Dhody' <[email-masked]>; 'Teas-ns-dt' <[email-masked]>; 'TEAS WG' <[email-masked]>
主题: Re: [Teas] draft-wd-teas-transport-slice-yang-01 - Mike question

Reza:

(smile)

Sue

----------------

Customer level

    |

Higher level systems

  |  (your model is here)

|

Network controllers

On slide 2,

a) who is the customer?

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

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

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

[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

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

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

Is this correct?

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

-----Original Message-----

Cheers,

Reza

    Hi Sue,

    draft.

    Thanks!

    Dhruv

    On Thu, Apr 23, 2020 at 9:16 PM Susan Hares <[email-masked]<mailto:[email-masked]>> wrote:

    Teas mailing list

Teas mailing list

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 26 Apr 2020 00:54:58 -0400

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:
> *From: *"Wubo (lana)" <[email-masked]>
> *Date: *Friday, April 24, 2020 at 5:32 AM
> *To: *Susan Hares <[email-masked]>, Reza Rokui <[email-masked]>, 
> 'Dhruv Dhody' <[email-masked]>, 'Teas-ns-dt' 
> <[email-masked]>, 'TEAS WG' <[email-masked]>
> *Subject: *Re: [Teas] draft-wd-teas-transport-slice-yang-01 - Mike question
> 
> Hi Sue,
> 
> 发件人: Teas [mailto:[email-masked]] 代表Susan Hares
> 发送时间: 2020年4月24日2:02
> 收件人: 'Rokui, Reza (Nokia - CA/Ottawa)' <[email-masked]>; 'Dhruv 
> Dhody' <[email-masked]>; 'Teas-ns-dt' 
> <[email-masked]>; 'TEAS WG' <[email-masked]>
> /[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?
> 
> [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.
> 
> [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).
> 
> /[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.
> 
> [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.
> 
> [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
> 
> /[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       |
> 
> /[Bo] No, the authors prefer /TS-NBI as a customer-view connection for 
> Higher level systems.
> 
> 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.
> 
> /[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./
> 
> 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.
> 
> On 2020-04-23, 12:22 PM, "Teas on behalf of Dhruv Dhody" 
> <[email-masked] on behalf of [email-masked] 
> <mailto:[email-masked][email-masked]>> wrote:
> 
>      Hi Sue,
> 
>      >
>      > 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
> 
>      > [email-masked] <mailto:[email-masked]>
> 
>      > https://www.ietf.org/mailman/listinfo/teas
> 
> [email-masked] <mailto:[email-masked]>
> 
> [email-masked] <mailto:[email-masked]>
>

---

From: "Susan Hares" <[email-masked]>
Date: Sun, 26 Apr 2020 11:58:29 -0400

Reza: 

Please  see my comments below – inline.   Here’s the important part from of all your responses. 

[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 multiple Sites which might be different from Transport Slice Endpoints.

Here you describe using l2SM and L3SM as a customer at a high layer.  

It is fine to build layers of customer or transport models, just define the interactions.  

In defining RFC8345 – the authors knew the customer layer might take refining. 

If this is what you are doing, then please define it  carefully and cleanly. 

If you are defining layers within RFC8345 customer layer, please define what you are doing. 

Joel and I are commenting on this work because we wish to see you succeed. 

Sue 

 

From: Rokui, Reza (Nokia - CA/Ottawa) [mailto:[email-masked]] 
Sent: Sunday, April 26, 2020 12:36 AM
To: Wubo (lana); Susan Hares; 'Dhruv Dhody'; 'Teas-ns-dt'; 'TEAS WG'
Cc: Rokui, Reza (Nokia - CA/Ottawa)
Subject: Re: [Teas] draft-wd-teas-transport-slice-yang-01 - Mike question

Hi Sue,

Reza

Hi Sue,

Please see inline below.

Thanks,

Bo

-----邮件原件-----
发件人: Teas [mailto:[email-masked]] 代表 Susan Hares
发送时间: 2020年4月24日 2:02
收件人: 'Rokui, Reza (Nokia - CA/Ottawa)' <[email-masked]>; 'Dhruv Dhody' <[email-masked]>; 'Teas-ns-dt' <[email-masked]>; 'TEAS WG' <[email-masked]>
主题: Re: [Teas] draft-wd-teas-transport-slice-yang-01 - Mike question

Reza:

(smile)

Sue

----------------

Customer level 

    |

Higher level systems

  |  (your model is here)

|

Network controllers

On slide 2,

a) who is the customer? 

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

RFC8345 provides an architecture that allows many types 

of service models above the network layer.  As far as I 

can tell, you are defining a model that uses the 

services of network controllers.   Theory behind the model 

is to provide clean service points based on a common model.  

To state  ACTN could do this but it is only one model

Implies that you are building a model that combines with other 

Models.  If so, your definitions need to clearly state:

1) who uses each level  

2) how the level above connects to the level below 

3) how you interact with existing models

[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).

You need to have enough details to define the characteristics 

of each layer of the model.   

Saying the “details” are out of  scope is insufficient for 

Building a model that is going to combine other models. 

You are proposing an alternative to RFC8345 – then 

You must come up to its standard. 

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.

I am assuming by your slides and by your response that 

Your yang data model is for the Transport slice controller. 

All data models have profiles for implementation:

(MUST implement, May implement, etc). 

If the connection to your yang model exists across a 

Administrative boundary, the access permissions in the 

Data model need to be defined with that in mind.  

The basic NETCONF/RESTCONF data models will take 

care of access permissions.   

Are you saying additional work needs to be done here? 

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

          |    .--.             .--.                .--.         |

          |   (    )--.        (    )--.           (    )--.     |

          |   .'         '     .'         '        .'        '   |

          |                                                      |

          |                      Operator-z                      |

   Legend:

     TSn: Transport Slice n

     OSm: Other Slice m

     EU-x: End User-x

     EU-y: End User-y

I realize you believe your Uber drive scenario is very different than 

the VPN case.  Your argument simply points out more layered

VPNs with different means of setting these VPNs up. 

Building a new type of VPN is fine, but your comparison

fail to delve into the complexities of the L2SM and L3SM. 

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

Thank you for the clarification. 

[Bo] No to the above questions, The TSC is unaware of slice customers. 

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

[Bo] 

In the context of transport slices, it is assumed that the connection 

between the customer site and transport network has been established, 

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.

This text is a very useful point.  You are combining L2SM and L3SM at a higher level. 

 This is the answer I am seeking. 

+------+

|CE  TS1EP--+

+------+      |

            |

            |   +--------------+

+------+      +-----+         |

|CE  TS2EP      |     PE  |

|    +----------------+         |

|    TS3EP      |         |

+------+          +-------------+

+------+

|CE  +--------+

+------+      |

            |

            |  +----------------+

+------+      +-TS1EP       |

|CE  |        TS2EP  PE   |

|    +----------+             |

|    |        TS3EP       |

Is this correct? 

Your slide 15 was unclear and logically specious. 

 

-----Original Message-----

Cheers,

Reza

    Hi Sue,

    draft.

    Thanks!

    Dhruv

    On Thu, Apr 23, 2020 at 9:16 PM Susan Hares < <mailto:[email-masked]> [email-masked]> wrote:

    Teas mailing list

 

Teas mailing list

---

From: "Rokui, Reza (Nokia - CA/Ottawa)" <[email-masked]>
Date: Mon, 27 Apr 2020 12:28:14 +0000

Sue,
Please see inline.

Reza

From: Susan Hares <[email-masked]>
Date: Sunday, April 26, 2020 at 11:58 AM
To: Reza Rokui <[email-masked]>, "'Wubo (lana)'" <[email-masked]>, 'Dhruv Dhody' <[email-masked]>, 'Teas-ns-dt' <[email-masked]>, 'TEAS WG' <[email-masked]>
Subject: RE: [Teas] draft-wd-teas-transport-slice-yang-01 - Mike question

Reza:

In defining RFC8345 – the authors knew the customer layer might take refining.
If this is what you are doing, then please define it  carefully and cleanly.
 [Reza] Please elaborate on this.
In summary as shown in following slide, augmenting RFC 8345 is a potential option to define TSC NBI. However, the authors feel that it is not a good option. The reasons are also shown below.

Joel and I are commenting on this work because we wish to see you succeed.
[Reza] Great to hear this.

Sue

Hi Sue,

Reza

Hi Sue,

Please see inline below.

Thanks,

Bo

-----邮件原件-----
发件人: Teas [mailto:[email-masked]] 代表 Susan Hares
发送时间: 2020年4月24日 2:02
收件人: 'Rokui, Reza (Nokia - CA/Ottawa)' <[email-masked]>; 'Dhruv Dhody' <[email-masked]>; 'Teas-ns-dt' <[email-masked]>; 'TEAS WG' <[email-masked]>
主题: Re: [Teas] draft-wd-teas-transport-slice-yang-01 - Mike question

Reza:

(smile)

Sue

----------------

Customer level

    |

Higher level systems

  |  (your model is here)

|

Network controllers

On slide 2,

a) who is the customer?

1) who uses each level

[Bo]

+------+

|CE  TS1EP--+

+------+      |

            |

            |   +--------------+

+------+      +-----+         |

|CE  TS2EP      |     PE  |

|    +----------------+         |

|    TS3EP      |         |

+------+          +-------------+

+------+

|CE  +--------+

+------+      |

            |

            |  +----------------+

+------+      +-TS1EP       |

|CE  |        TS2EP  PE   |

|    +----------+             |

|    |        TS3EP       |

Is this correct?

-----Original Message-----

Cheers,

Reza

    Hi Sue,

    draft.

    Thanks!

    Dhruv

    On Thu, Apr 23, 2020 at 9:16 PM Susan Hares <[email-masked]<mailto:[email-masked]>> wrote:

    Teas mailing list

Teas mailing list

---

From: "Rokui, Reza (Nokia - CA/Ottawa)" <[email-masked]>
Date: Mon, 27 Apr 2020 12:43:38 +0000

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" <[email-masked]> wrote:

    Yours,

    Joel

    > 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

    > Or is the customer really the person on the inside of the 5G provider

    > configuring it.

    > To: Dhruv Dhody; Susan Hares; Teas-ns-dt; TEAS WG ([email-masked]

    > <mailto:[email-masked]>)

    > As Dhruv pointed out, we add them to appendix since they are very

    > important aspects.

    >      On Thu, Apr 23, 2020 at 9:16 PM Susan Hares <[email-masked]

    > <mailto:[email-masked]>> wrote:

    >      > Thank you for your presentation in TEAS on the

    >      > “Would you provide more details on why you felt the base model

    >      > It seems to me that you are proposing a customer level model  to

    >      > If you are looking to utilize the base model then providing a

    >      > Would you do me a favor in your presentation of “customer

    >      > The I2RS WG (which chair) standardized RFC8345.   Your

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 27 Apr 2020 09:27:51 -0400

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:
> 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.
> 
>      > Hi Sue,
>      > In addition of Bo’s answers, see my comments in line.
> 
>      >
> 
>      > Reza
> 
>      >
> 
>      > *From: *"Wubo (lana)" <[email-masked]>
> 
>      > *Date: *Friday, April 24, 2020 at 5:32 AM
> 
>      > *To: *Susan Hares <[email-masked]>, Reza Rokui 
> <[email-masked]>,
> 
>      > 'Dhruv Dhody' <[email-masked]>, 'Teas-ns-dt'
> 
>      > <[email-masked]>, 'TEAS WG' <[email-masked]>
> 
>      > *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:[email-masked]] 代表Susan Hares
> 
>      > 发送时间: 2020年4月24日2:02
> 
>      > 收件人: 'Rokui, Reza (Nokia - CA/Ottawa)' <[email-masked]>; 
> 'Dhruv
> 
>      > Dhody' <[email-masked]>; 'Teas-ns-dt'
> 
>      > <[email-masked]>; 'TEAS WG' <[email-masked]>
> 
>      > 主题: 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:[email-masked]]
> 
>      >
> 
>      > Sent: Thursday, April 23, 2020 1:01 PM
> 
>      >
> 
>      > To: Dhruv Dhody; Susan Hares; Teas-ns-dt; TEAS WG ([email-masked]
> 
>      > <mailto:[email-masked]>)
> 
>      >
> 
>      > 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"
> 
>      > <[email-masked] on behalf of [email-masked]
> 
>      > 
>      >      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 <[email-masked]
> 
>      > <mailto:[email-masked]>> 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
> 
>      >
> 
>      >      > [email-masked] <mailto:[email-masked]>
> 
>      >
> 
>      >      > https://www.ietf.org/mailman/listinfo/teas
> 
>      >
> 
>      > [email-masked]

---

From: "Susan Hares" <[email-masked]>
Date: Mon, 27 Apr 2020 10:44:10 -0400

Reza: 

You stated slide 15 gives the reasons why we decided to build our own model. 

Slide 15 is the question I started asking questions about.   

[Slide 15]

1) [left side] You state the network hierarchy is useful for the network provider, 

but not as a customer view. 

[Sue] 

In this you misunderstand the purpose of RFC8345 of the customer layer. 

The customer layer exists as a view to itself.  All customer layers must link to 

network points through layers.  You model does through the 

Higher-systems-layer and the transport controller.  

And how do you characterize the  higher-systems-layer and transport controller? 

Are they  layers within the customer model (RFC8345) or 

something different?  If it is something different how do you define it? 

[your comment:] 

2) [right side] Augmenting the TP via the TS-Endpoint loses 

the logical  nature of the endpoint and require one to

maintain abstract nodes for the customer site (CE) and PE even when 

unknown. 

[Sue] 

This reasoning does not define: 

a) what endpoint you are speaking about 

b) Why augmenting TP via TS-Endpoint is necessary 

c) Why CE and PE endpoints are required to link to? 

I can find no substance in the second comment on the slides 15

to debate or discuss unless you add information. 

This is why I call slide 15’s argument logically specious. 

I continue to send email to listen to your logical reason for casting 

RFC8345 aside. 

Sue 

From: Teas [mailto:[email-masked]] On Behalf Of Rokui, Reza (Nokia - CA/Ottawa)
Sent: Monday, April 27, 2020 8:28 AM
To: Susan Hares; 'Wubo (lana)'; 'Dhruv Dhody'; 'Teas-ns-dt'; 'TEAS WG'
Cc: Rokui, Reza (Nokia - CA/Ottawa)
Subject: Re: [Teas] draft-wd-teas-transport-slice-yang-01 - Mike question

Sue,

Please see inline.

Reza

Reza: 

 

Sue 

 

Hi Sue,

Reza

Hi Sue,

Please see inline below.

Thanks,

Bo

-----邮件原件-----
发件人: Teas [mailto:[email-masked]] 代表 Susan Hares
发送时间: 2020年4月24日 2:02
收件人: 'Rokui, Reza (Nokia - CA/Ottawa)' <[email-masked]>; 'Dhruv Dhody' <[email-masked]>; 'Teas-ns-dt' <[email-masked]>; 'TEAS WG' <[email-masked]>
主题: Re: [Teas] draft-wd-teas-transport-slice-yang-01 - Mike question

Reza:

(smile)

Sue

----------------

Customer level 

    |

Higher level systems

  |  (your model is here)

|

Network controllers

On slide 2,

a) who is the customer? 

1) who uses each level  

 

          |    .--.             .--.                .--.         |

          |   (    )--.        (    )--.           (    )--.     |

          |   .'         '     .'         '        .'        '   |

          |                                                      |

          |                      Operator-z                      |

   Legend:

     TSn: Transport Slice n

     OSm: Other Slice m

     EU-x: End User-x

     EU-y: End User-y

[Bo] 

+------+

|CE  TS1EP--+

+------+      |

            |

            |   +--------------+

+------+      +-----+         |

|CE  TS2EP      |     PE  |

|    +----------------+         |

|    TS3EP      |         |

+------+          +-------------+

+------+

|CE  +--------+

+------+      |

            |

            |  +----------------+

+------+      +-TS1EP       |

|CE  |        TS2EP  PE   |

|    +----------+             |

|    |        TS3EP       |

Is this correct? 

 

-----Original Message-----

Cheers,

Reza

    Hi Sue,

    draft.

    Thanks!

    Dhruv

    On Thu, Apr 23, 2020 at 9:16 PM Susan Hares < <mailto:[email-masked]> [email-masked]> wrote:

    Teas mailing list

 

Teas mailing list

---

From: "Rokui, Reza (Nokia - CA/Ottawa)" <[email-masked]>
Date: Mon, 27 Apr 2020 16:33:05 +0000

OK great.
Reza

On 2020-04-27, 9:27 AM, "Joel M. Halpern" <[email-masked]> wrote:

    Yours,
    Joel