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

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:dhruv.ietf@gmail.com] 
Sent: Thursday, April 23, 2020 12:23 PM
To: Susan Hares
Cc: TEAS WG (teas@ietf.org)
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 <shares@ndzh.com> 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
> Teas@ietf.org
> https://www.ietf.org/mailman/listinfo/teas