Re: [Teas] I-D Action: draft-ietf-teas-te-service-mapping-yang-05.txt

["[e-mail]" <[e-mail]>]

Hi Dhruv,

Thanks for accepting the proposed change.

>Ok, see the attached yang file.

Looks good when te-end-point-ref-vnap is defined in tsm-types.

Thanks,
Kenichi

-----Original Message-----
From: Dhruv Dhody <[e-mail]> 
Sent: Monday, November 9, 2020 12:19 AM
To: 大垣 健一 <[e-mail]>
Cc: [e-mail]; 宮坂 拓也 <[e-mail]>; 福井 良平 <[e-mail]>; Qin Wu <[e-mail]>
Subject: ***フリーメール*** Re: ***フリーメール*** Re: [Teas] I-D Action: draft-ietf-teas-te-service-mapping-yang-05.txt

Hi Kenichi,

On Sat, Nov 7, 2020 at 12:41 PM [e-mail] <[e-mail]> wrote:
>
> Hi Dhruv,
>
> Thank you for the reply.
>
> As you can see section 6.12.3.2, latency and jitter also imply end-to-end constraints.
> Then, if we do so, the when statement should connects the followings with 'or'.
> './l3vpn-svc:latency/l3vpn-svc:latency-boundary'
> './l3vpn-svc:jitter/l3vpn-svc:jitter-boundary'
> './l3vpn-svc:bandwidth/l3vpn-svc:end-to-end'
>
>
> Additionally, for the usability, if the user implicitly knows what latency, jitter or bandwidth is set to VN(-member) outside of L3SM and may not explicitly set them under l3vpn-svc:class, we should allow the when statement against l3vpn-svc:class.
>

In that case perhaps we can remove the when statement entirely.

>
> Also, L3SM can differentiate VPN per site-network-access. If te-service-mapping models to only map a VNAP to a site, any L3SM user cannot specify only a VPN or a site-network-access in a site to map a VN(-member). Then, we should also allow to map VNAP per site and site-network-access.
>
> augment /l3vpn-svc:l3vpn-svc/l3vpn-svc:sites/l3vpn-svc:site
>                   /l3vpn-svc:service/l3vpn-svc:qos/l3vpn-svc:qos-profile
>                   /l3vpn-svc:qos-profile/l3vpn-svc:custom/l3vpn-svc:classes
>                   /l3vpn-svc:class:
>     +--rw (te)?
>           +--:(vn)
>                +--rw vn-ap? leafref
>
> and
>
> augment /l3vpn-svc:l3vpn-svc/l3vpn-svc:sites/l3vpn-svc:site
>                   /l3vpn-svc:site-network-accesses/l3vpn-svc:site-network-access
>                   /l3vpn-svc:service/l3vpn-svc:qos/l3vpn-svc:qos-profile
>                   /l3vpn-svc:qos-profile/l3vpn-svc:custom/l3vpn-svc:classes
>                   /l3vpn-svc:class:
>     +--rw (te)?
>          +--:(vn)
>               +--rw vn-ap? leafref
>
> If a user wants to share a VN across the user's different VPNs, the user may set an identical custom profile across the VPNs(site-network-accesses). Then, the former one still works.
>
> How do you all think?
>

Ok, see the attached yang file.

Thanks!
Dhruv

> Thanks,
> Kenichi
>
> ________________________________
> From: Dhruv Dhody <[e-mail]>
> Sent: Friday, November 6, 2020 5:32 PM
> To: 大垣 健一
> Cc: [e-mail]; 宮坂 拓也; 福井 良平; Qin Wu
> Subject: ***フリーメール*** Re: [Teas] I-D Action: 
> draft-ietf-teas-te-service-mapping-yang-05.txt
>
> Hi Kenichi,
>
> I feel the augmentation might be applicable only for the end-to-end 
> case, so if we do this, we could augment with the when statement -
>
>   augment "/l3vpn-svc:l3vpn-svc/l3vpn-svc:sites/l3vpn-svc:site"
>         + "/l3vpn-svc:service/l3vpn-svc:qos/l3vpn-svc:qos-profile"
>         + "/l3vpn-svc:qos-profile/l3vpn-svc:custom"
>         + "/l3vpn-svc:classes/l3vpn-svc:class" {
>     when './l3vpn-svc:bandwidth/l3vpn-svc:end-to-end' {
>       description
>         "applicable only with end-to-end";
>     }
>     description
>       "This augment is only valid for the custom qos-profile with 
> end-to-end set";
>     uses tsm-types:te-endpoint-ref-vnap;
>   }
>
>   augment /l3vpn-svc:l3vpn-svc/l3vpn-svc:sites/l3vpn-svc:site
>             /l3vpn-svc:service/l3vpn-svc:qos/l3vpn-svc:qos-profile
>             /l3vpn-svc:qos-profile/l3vpn-svc:custom/l3vpn-svc:classes
>             /l3vpn-svc:class:
>     +--rw (te)?
>        +--:(vn)
>           +--rw vn-ap?   leafref
>
> What does the WG think? Any opinion from those proficient in L3SM :)
>
> Thanks!
> Dhruv
>
> On Tue, Nov 3, 2020 at 10:13 AM [e-mail] <[e-mail]> wrote:
> >
> > Hi draft-ietf-teas-te-service-mapping-yang authors,
> >
> > Thanks for updating.
> >
> > In terms of our requirement discussed in "consideration of 1 VPN to 
> > N VNs mapping" thread, as Qin proposed the followings in 
> > https://mailarchive.ietf.org/arch/msg/teas/xJx323vJbcqVY7eZKuBOEDswF
> > zk/ ,
> >
> > >standard profile (such as golden, silver) can not be simply seen as network performance constraint. QoS parameters in custom profile (e.g., latency) should be seen as SLA contract set between customer and operator, which is still a little different from network performance constraints used for path computation.
> >
> > >target-class-id is used to identify each match flow and have one to one relationship with custom qos profile since class-id is defined under custom case for each class of data flow.
> >
> > >Secondly, we can map one VPN into one VN with multiple VN members, each VN member describe connective from one site to another destination site and can support different QoS requirement which is similar to using site-network-access to support different QoS requirements.
> > >Does this satisfy your use case?
> >
> >
> > How about the following changes in order to map vn-member(VNAP) to a customer profile corresponding to each match flow per site-network-access?
> >
> >      augment /l3vpn-svc:l3vpn-svc/l3vpn-svc:sites/l3vpn-svc:site
> >                /l3vpn-svc:site-network-accesses/l3vpn-svc:site-network-access
> >                /l3vpn-svc:service/l3vpn-svc:qos/l3vpn-svc:qos-profile/l3vpn-svc:classes
> >                /l3vpn-svc:class:
> >        +--rw (te)?
> >           +--:(vn)
> >              +--rw vn-ap
> >                      -> /vn:ap/access-point-list/vn-ap/vn-ap-id
> >
> > Thanks,
> > Kenichi
> >
> > --
> > Kenichi Ogaki
> > KDDI Corp. | Operation Automation Promotion Dept.
> > [phone] | www.kddi.com
> >
> >
> > ________________________________
> > From: Teas <[e-mail]> on behalf of 
> > [e-mail] <[e-mail]>
> > Sent: Monday, November 2, 2020 7:07 PM
> > To: [e-mail]
> > Cc: [e-mail]
> > Subject: [Teas] I-D Action: 
> > draft-ietf-teas-te-service-mapping-yang-05.txt
> >
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts directories.
> > This draft is a work item of the Traffic Engineering Architecture and Signaling WG of the IETF.
> >
> >         Title           : Traffic Engineering (TE) and Service Mapping Yang Model
> >         Authors         : Young Lee
> >                           Dhruv Dhody
> >                           Giuseppe Fioccola
> >                           Qin Wu
> >                           Daniele Ceccarelli
> >                           Jeff Tantsura
> >         Filename        : draft-ietf-teas-te-service-mapping-yang-05.txt
> >         Pages           : 47
> >         Date            : 2020-11-02
> >
> > Abstract:
> >    This document provides a YANG data model to map customer service
> >    models (e.g., the L3VPN Service Model (L3SM)) to Traffic Engineering
> >    (TE) models (e.g., the TE Tunnel or the Virtual Network (VN) model).
> >    This model is referred to as TE Service Mapping Model and is
> >    applicable generically to the operator's need for seamless control
> >    and management of their VPN services with TE tunnel support.
> >
> >    The model is principally used to allow monitoring and diagnostics of
> >    the management systems to show how the service requests are mapped
> >    onto underlying network resource and TE models.
> >
> >
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-ietf-teas-te-service-mapping-
> > yang/
> >
> > There are also htmlized versions available at:
> > https://tools.ietf.org/html/draft-ietf-teas-te-service-mapping-yang-
> > 05
> > https://datatracker.ietf.org/doc/html/draft-ietf-teas-te-service-map
> > ping-yang-05
> >
> > A diff from the previous version is available at:
> > https://www.ietf.org/rfcdiff?url2=draft-ietf-teas-te-service-mapping
> > -yang-05
> >
> >
> > Please note that it may take a couple of minutes from the time of 
> > submission until the htmlized version and diff are available at tools.ietf.org.
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >
> >
> > _______________________________________________
> > Teas mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/teas
> > _______________________________________________
> > Teas mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/teas