Re: [Teas] ***フリーメール*** Re: I-D Action: draft-ietf-teas-te-service-mapping-yang-05.txt

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.

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?

Thanks,
Kenichi

________________________________
From: Dhruv Dhody <dhruv.ietf@gmail.com>
Sent: Friday, November 6, 2020 5:32 PM
To: 大垣 健一
Cc: teas@ietf.org; 宮坂 拓也; 福井 良平; 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 ke-oogaki@kddi.com <ke-oogaki@kddi.com> 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.
> +81-(0)80-5945-9138 | www.kddi.com<http://www.kddi.com>
>
>
> ________________________________
> From: Teas <teas-bounces@ietf.org> on behalf of internet-drafts@ietf.org <internet-drafts@ietf.org>
> Sent: Monday, November 2, 2020 7:07 PM
> To: i-d-announce@ietf.org
> Cc: teas@ietf.org
> 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
> Teas@ietf.org
> https://www.ietf.org/mailman/listinfo/teas
> _______________________________________________
> Teas mailing list
> Teas@ietf.org
> https://www.ietf.org/mailman/listinfo/teas