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

[Dhruv Dhody <[e-mail]>]

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/xJx323vJbcqVY7eZKuBOEDswFzk/ ,
>
> >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-mapping-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