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

Dhruv Dhody <dhruv.ietf@gmail.com> Sun, 08 November 2020 15:19 UTC

Return-Path: <dhruv.ietf@gmail.com>
X-Original-To: teas@ietfa.amsl.com
Delivered-To: teas@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D6C63A0829 for <teas@ietfa.amsl.com>; Sun, 8 Nov 2020 07:19:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 206F5dh0DV2c for <teas@ietfa.amsl.com>; Sun, 8 Nov 2020 07:19:42 -0800 (PST)
Received: from mail-io1-xd2a.google.com (mail-io1-xd2a.google.com [IPv6:2607:f8b0:4864:20::d2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CE173A083F for <teas@ietf.org>; Sun, 8 Nov 2020 07:19:41 -0800 (PST)
Received: by mail-io1-xd2a.google.com with SMTP id u19so7315921ion.3 for <teas@ietf.org>; Sun, 08 Nov 2020 07:19:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=OhnlGGk1EGivSPzabm4mQq9j1qTp0iAH2ij4wdMNgdY=; b=PsGRNgk5zpyOYuG9Wvy/AcwWb90vYcuP9Jg8EfsZRF3Ze+40S7qxVAid4qsEneBTQC fGZKzz9xnrzTzKg/FMgVUTmHjGPSXIf7f6hiWv4FOpg4wSqr4iX+sSM8h4s8VG2LbTXx 5lerHR+OKoCt3NpHRHCTnsnnrhUYYl67cZjnvKa0B6S88Sb9Qran81h7/PaF8UCaO2oO tfmuZ+dumNSxD8F+xWz25bShcsu34IXNoWcSlZh7IFPWVfY+OHhWh9+rwF8ou3OdUkRp QyUKJo7xuv/CtM+frWyhnhlDcGwCz4mQRrHyOxXHzLUdxQ+XP7wWxMAKeb21sdVv5/hx eCuQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=OhnlGGk1EGivSPzabm4mQq9j1qTp0iAH2ij4wdMNgdY=; b=HEZ9sb3CGZOTWVqYHidOlh3h1v7bbV72Ga380r9HZVj0ztuA4GXron9ng8OwXCO+i8 /tk9YfcQci9UOD5uVOo42vsUgw2db0YUDtMDbBuPbrgN2lIsKhT/mxKPgjUtPrUqAm0N NZvAFao9pVt6kg2mBQCxkkPr/bHFjyh6+tQEIOlVYSRmgwMm4SbG+Y6HJyo/TK8ImCgs z4Kk8jtyyfX8lVZ33sjdZD4N0Rp7PGREHicph7FtLk4A6bw0oQ6Nfzpt1HExVitbwZTb KTVsubXVkXrYB/BIPmfmocNKEmJx9+qkAPdlPesjbwhyJ5K7bvZyRWwtmkfb9qvyBwA8 8Yew==
X-Gm-Message-State: AOAM532oF5P/eZDWIMs3IjDoJ4GDrCiHyIDNI7ZjD8SgfbLpS/OOdCAS CZZMeLpZqjP3hhA+Dstuj1iK/a67LdWQEehKcKQ=
X-Google-Smtp-Source: ABdhPJz5pJgsRgL8nwS2NlTo2VUzatyNLkdl58tHeNKeDIDzbrlLu4fblu3j82pEvXpLmg/jGsTgEqwJuL+D4p8zlNg=
X-Received: by 2002:a6b:7947:: with SMTP id j7mr7242215iop.143.1604848781006; Sun, 08 Nov 2020 07:19:41 -0800 (PST)
MIME-Version: 1.0
References: <160431162330.17186.15934825204635930430@ietfa.amsl.com> <TY2PR01MB3562E929B653EE1691123E6490110@TY2PR01MB3562.jpnprd01.prod.outlook.com> <CAB75xn6RcgS3w0-GPXoH_Xz_D2R-N+SToeeGoJQEfz5BHR57Dg@mail.gmail.com> <TY2PR01MB3562099C3AEE6F87EE255DEB90EC0@TY2PR01MB3562.jpnprd01.prod.outlook.com>
In-Reply-To: <TY2PR01MB3562099C3AEE6F87EE255DEB90EC0@TY2PR01MB3562.jpnprd01.prod.outlook.com>
From: Dhruv Dhody <dhruv.ietf@gmail.com>
Date: Sun, 08 Nov 2020 20:49:04 +0530
Message-ID: <CAB75xn7nC34ow1-J1t1t5cnaB157pOsMyVkq5pR2YcLAEexzEw@mail.gmail.com>
To: "ke-oogaki@kddi.com" <ke-oogaki@kddi.com>
Cc: "teas@ietf.org" <teas@ietf.org>, "ta-miyasaka@kddi.com" <ta-miyasaka@kddi.com>, "ry-fukui@kddi.com" <ry-fukui@kddi.com>, Qin Wu <bill.wu@huawei.com>
Content-Type: multipart/mixed; boundary="00000000000082b40505b399f905"
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/C5HyR701gynAq8f_mZdl7XOZNew>
Subject: Re: [Teas] ***フリーメール*** Re: I-D Action: draft-ietf-teas-te-service-mapping-yang-05.txt
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <teas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/teas>, <mailto:teas-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teas/>
List-Post: <mailto:teas@ietf.org>
List-Help: <mailto:teas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/teas>, <mailto:teas-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 08 Nov 2020 15:19:44 -0000

Hi Kenichi,

On Sat, Nov 7, 2020 at 12:41 PM ke-oogaki@kddi.com <ke-oogaki@kddi.com> 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 <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
> >
> >
> > ________________________________
> > 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