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

From: "Susan Hares" <[email-masked]>
Date: Thu, 23 Apr 2020 11:46:05 -0400

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

---

From: Dhruv Dhody <[email-masked]>
Date: Thu, 23 Apr 2020 21:52:39 +0530

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]> wrote:
> 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 ---
>
>         |
>
> 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]
> https://www.ietf.org/mailman/listinfo/teas

---

From: "Rokui, Reza (Nokia - CA/Ottawa)" <[email-masked]>
Date: Thu, 23 Apr 2020 17:00:57 +0000

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]> wrote:

    Hi Sue,

    Thanks!
    Dhruv

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 23 Apr 2020 13:51:29 -0400

Dhruv: 

Thanks for the quick response.     I'll consider your model as a customer model
per RFC8345. 

The L2SM Yang model (RFC8466) and the L3SM Yang Model
 spend a great deal of time talking about connections to sites 
from different perspectives.  See section 5.6 in RFC8466. 
See section 6.6 in section 8049.  
Your draft does not provide the same level of detail.    

Perhaps this is coming. 

The issue I find unclear is exactly how the TS End point 
is indicated based on  RFC8345 (slide 15 your presentation) 

Your draft states in Section 5: 

  "A TS End Point is a logical entity at an external Interface of the
   transport network to a customer site. " 

And section 5.1 you indicate this logical entity can be:  
distinct physical connection, L2 logical connection, tunnel 

Then you state:   "Based on this, the end point 
in this model could represents the following options:" 

   o  A slice interface of a customer site: the "node-id" and "tp-id"
      under the "ts-endpoint" can be specified

   o  A slice interface of the transport network: the "node-id" and "tp-
      id" under the "ts-endpoint" can be specified, and "site-access-
      parameters" can be used to specify the attached customer site.

   o  The subset of traffic through the particular interface connected to
      the transport network, either at the customer site or the
      transport network: besides the "node-id" and "tp-id", the "ts-
      traffic-criteria" is needed
 
If you are a customer model,  does this model that the 
end-point definition covers all these cases by 
providing more details depending to indicate the
 logical connection underneath?  

Is this simply a way of stating you use 
RFC8345's logical links through to a different layer? 
(see figure 2 and 3 in RFC8345). 

Thank you,  Susan Hares 

-----Original Message-----
From: Dhruv Dhody [mailto:[email-masked]] 
Sent: Thursday, April 23, 2020 12:23 PM
To: Susan Hares
Cc: TEAS WG ([email-masked])
Subject: Re: [Teas] draft-wd-teas-transport-slice-yang-01 - Mike question

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]> wrote:
> “Would you provide more details on why you felt the base model 
> (RFC8345) was not appropriate to utilize? “
>
>
>

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 23 Apr 2020 14:02:15 -0400

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

 On slide 2, 
a) who is the customer? 
b) who is running the higher level systems? 
c) who is running transport slide controller 

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. 

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) 

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? 

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. 

Question 4:  Are these models ephemeral? 

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])
Cc: Rokui, Reza (Nokia - CA/Ottawa)
Subject: Re: [Teas] draft-wd-teas-transport-slice-yang-01 - Mike question

Cheers,
Reza

    Hi Sue,

    Thanks!
    Dhruv

---

From: Dhruv Dhody <[email-masked]>
Date: Fri, 24 Apr 2020 10:00:12 +0000

Hi Sue, 

I wanted to clear up that our approach in this I-D is an independent yang model. We wanted to include some slides that also show how the model *would* have looked if we took other approaches such as augmenting ietf-vn and ietf-network. More inline - 

> From: Teas [mailto:[email-masked]] On Behalf Of Susan Hares
> Sent: 23 April 2020 23:21
> To: 'Dhruv Dhody' <[email-masked]>
> Cc: 'TEAS WG' <[email-masked]>
> The L2SM Yang model (RFC8466) and the L3SM Yang Model  spend a great deal
> of time talking about connections to sites from different perspectives.
> See section 5.6 in RFC8466.

[[Dhruv Dhody]]  Yes.

> 
> The issue I find unclear is exactly how the TS End point is indicated
> based on  RFC8345 (slide 15 your presentation)
> 
[[Dhruv Dhody]] Slide 13 and 15 is meant to show how the models would have looked, if we would have taken that route. We did not, our I-D is an independent model that does not augment RFC8345. In Slide 15 we note the issue if we were to augment termination point for TS-endpoint.  

> If you are a customer model,  does this model that the end-point
> definition covers all these cases by providing more details depending to
> indicate the  logical connection underneath?
> 
[[Dhruv Dhody]] Yes. 

> Is this simply a way of stating you use RFC8345's logical links through to
> a different layer?
[[Dhruv Dhody]] No. We do not use RFC 8345 in our model. 

Thanks! 
Dhruv 

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