Re: [Teas] consideration of 1 VPN to N VNs mapping

"Ogaki, Kenichi" <ke-oogaki@kddi.com> Thu, 06 August 2020 00:59 UTC

Return-Path: <ke-oogaki@kddi.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 4F41D3A0AE8; Wed, 5 Aug 2020 17:59:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 GgAUVRMCUlvr; Wed, 5 Aug 2020 17:59:40 -0700 (PDT)
Received: from kddi.com (athena4.kddi.com [27.90.165.197]) by ietfa.amsl.com (Postfix) with ESMTP id 98A0E3A0AD9; Wed, 5 Aug 2020 17:59:39 -0700 (PDT)
Received: from LTMC2123.kddi.com (post-send [10.206.2.120]) by kddi.com (KDDI Mail) with ESMTP id A0EB012018E; Thu, 6 Aug 2020 09:59:38 +0900 (JST)
Received: from LTMC2144.kddi.com ([10.206.0.236] [10.206.0.236]) by LTMC2123.kddi.com with ESMTP; Thu, 6 Aug 2020 09:59:38 +0900
Received: from LTMC2144.kddi.com (localhost [127.0.0.1]) by localhost.kddi.com (Postfix) with ESMTP id 7FA894C005E; Thu, 6 Aug 2020 09:59:38 +0900 (JST)
Received: from LTMC2154.kddi.com (post-incheck [10.206.0.239]) by LTMC2144.kddi.com (Postfix) with ESMTP id 74E5B4C005C; Thu, 6 Aug 2020 09:59:38 +0900 (JST)
Received: from LTMC2154.kddi.com (localhost.localdomain [127.0.0.1]) by LTMC2154.kddi.com with ESMTP id 0760xcRA149170; Thu, 6 Aug 2020 09:59:38 +0900
Received: from LTMC2154.kddi.com.mid_89031732 (localhost.localdomain [127.0.0.1]) by LTMC2154.kddi.com with ESMTP id 0760nXHb133488; Thu, 6 Aug 2020 09:49:33 +0900
X-SA-MID: 89031732
Received: from KDDI1801PC1319 ([10.211.4.86] [10.211.4.86]) by post-smtp2.kddi.com with ESMTPA; Thu, 6 Aug 2020 09:49:33 +0900
From: "Ogaki, Kenichi" <ke-oogaki@kddi.com>
To: "'Qin Wu'" <bill.wu@huawei.com>, "'Dhruv Dhody'" <dhruv.ietf@gmail.com>
Cc: =?utf-8?B?J+S4uee+vSDmnJ3kv6En?= <to-niwa@kddi.com>, =?utf-8?B?J+WuruWdgiDmi5PkuZ8n?= <ta-miyasaka@kddi.com>, "'TEAS WG'" <teas@ietf.org>, <draft-ietf-teas-te-service-mapping-yang@ietf.org>
References: <B8F9A780D330094D99AF023C5877DABAAD8CEDBD@dggeml531-mbs.china.huawei.com>
In-Reply-To: <B8F9A780D330094D99AF023C5877DABAAD8CEDBD@dggeml531-mbs.china.huawei.com>
Date: Thu, 6 Aug 2020 09:49:33 +0900
Message-ID: <004c01d66b8b$734a1770$59de4650$@kddi.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQIN7BuY77+tLZglNHdTDcyV88joU6i7OvWw
Content-Language: ja
X-TM-AS-GCONF: 00
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/8e_BZNPq-2MsrQw4ePHDH7h8Msw>
Subject: Re: [Teas] consideration of 1 VPN to N VNs mapping
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: Thu, 06 Aug 2020 00:59:42 -0000

Hi Qin,

Thanks for your comments.

See comments [KO] inline, please.

Thanks,
Kenichi

-----Original Message-----
From: Teas <teas-bounces@ietf.org> On Behalf Of Qin Wu
Sent: Wednesday, August 5, 2020 10:15 PM
To: Ogaki, Kenichi <ke-oogaki@kddi.com>om>; 'Dhruv Dhody' <dhruv.ietf@gmail.com>
Cc: '丹羽 朝信' <to-niwa@kddi.com>om>; '宮坂 拓也' <ta-miyasaka@kddi.com>om>; 'TEAS WG' <teas@ietf.org>rg>; draft-ietf-teas-te-service-mapping-yang@ietf.org
Subject: Re: [Teas] consideration of 1 VPN to N VNs mapping

Hi,
-----邮件原件-----
发件人: Ogaki, Kenichi [mailto:ke-oogaki@kddi.com] 
发送时间: 2020年8月5日 8:59
收件人: 'Dhruv Dhody' <dhruv.ietf@gmail.com>
抄送: '宮坂 拓也' <ta-miyasaka@kddi.com>om>; '丹羽 朝信' <to-niwa@kddi.com>om>; draft-ietf-teas-te-service-mapping-yang@ietf.org; 'TEAS WG' <teas@ietf.org>
主题: RE: [Teas] consideration of 1 VPN to N VNs mapping

Hi Dhruv,

Thanks for the prompt reply.

>There is an 'end-to-end leaf' that says bandwidth reservation needs to be done in MPLS network but I did not interpret that it requires maintaining a separate VN, the consolidated requirements from all classes can be mapped to a single VN and the QoS is applied at the edges as per the L3SM YANG.

As you saw in section 6.12.3.2, the properties of custom qos-profile include latency, and we honestly want the per-flow, classification rule, based VN mapping mechanism.

[Qin]: Kenichi, thanks for heads up.
RFC8299 allow you specify site level QoS parameters and site-network-access level QoS parameters. Each site-nework-access can support different QoS parameters matching one or multiple traffic flows.
These QoS parameters don't need to tie with specific CE-PE connectivity. It could be used to describe end to end QoS requirements from one site to another site or one site to multiple destination sites using target-site leaf-list under match-flow definition.
However RFC8299 doesn't describe 1 to 1 relation between target-class-id and standard-profile, it could be N to 1 relation.

[KO] What do you want to mean by? I believe that a target-class-id has 1:1 relationship to a standard-profile or a custom qos-profile.


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.

[KO] We understand these definitions are not identical. However, from a (customer facing) service model level, we, operator, must choose and define SLA and network performance constraints to be mappable/translatable. If not so, we cannot provision the network lower than network model level to meet the SLA.
So, we need this mapping mechanism.


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?

[KO] I see. If you mean that different VN member is set to different QoS profile even in the same site-network-access, our latter change request under site-network-access must be considered.
Also, our requirement to add the following groupings to vn-compute in actn-vn-yang presented? by Dhruv during 108th meeting must be slightly changed. These groupings are not added directly under vn-compute/input, but under each vn-compute/input/vn-member-list/vn-member.
uses te-types:generic-path-constraints
uses te-types:generic-path-optimization


>Anyways, let me get this verified from L3SM experts and come back to you.

Your colleague and one of co-editors of both te-service-mapping and RFC8299, Qin Wu, is familiar with this discussion like this:
https://mailarchive.ietf.org/arch/msg/l3sm/i5srx8YpD9296bu3VuIkHgAEi3g/
Q.12 from David Ball

Thanks,
Kenichi

-----Original Message-----
From: Teas <teas-bounces@ietf.org> On Behalf Of Dhruv Dhody
Sent: Tuesday, August 4, 2020 7:54 PM
To: Ogaki, Kenichi <ke-oogaki@kddi.com>
Cc: 宮坂 拓也 <ta-miyasaka@kddi.com>om>; 丹羽 朝信 <to-niwa@kddi.com>om>; draft-ietf-teas-te-service-mapping-yang@ietf.org; TEAS WG (teas@ietf.org) <teas@ietf.org>
Subject: Re: [Teas] consideration of 1 VPN to N VNs mapping

Hi Kenichi,

I have not looked into it in detail but my understanding of the classes in the custom qos-profile is that they are about the access CE-PE link and thus would not lead to the creation of a separate VN per class.

Even in the example
https://tools.ietf.org/html/rfc8299#section-6.12.3.2 it says how the
100 Mbps on the access link is shared between the 3 classes.

There is an 'end-to-end leaf' that says bandwidth reservation needs to be done in MPLS network but I did not interpret that it requires maintaining a separate VN, the consolidated requirements from all classes can be mapped to a single VN and the QoS is applied at the edges as per the L3SM YANG.

Anyways, let me get this verified from L3SM experts and come back to you.

Thanks!
Dhruv

On Tue, Aug 4, 2020 at 3:29 PM Ogaki, Kenichi <ke-oogaki@kddi.com> wrote:
>
> Hi draft-ietf-teas-te-service-mapping-yang authors,
>
> Could you consider 1 to N mapping for the L3VPN to VN mapping?
>
> As we required some changes to actn-vn-yang before/during 108th meeting, we would like to also discuss an additional requirement to te-service-mapping-yang. Sorry, late for 108th meeting.
>
> If we correctly understand the current definition, only one VN is allowed to be mapped to a VPN as described in section 4.1 and the model in section 6.1.1.
> However, L3SM expects to differentiate traffic handling per qos-profile which corresponds to key network performance constraints including bandwidth and latency, etc. as described in section 6.12.3.2 of RFC8299.
> As an operator, we believe this means that a qos-profile should be mapped to a VN like this:
>
>    module: ietf-l3sm-te-service-mapping
>      augment /l3vpn-svc:l3vpn-svc/l3vpn-svc:vpn-services
>                /l3vpn-svc:vpn-service:
>        +--rw te-service-mapping!
>           +--rw te-mapping
>              +--rw mapping* [mapping-id]
>                 +--rw mapping-id
>                 +--rw target-class-id?        -> /l3vpn-svc:l3vpn-svc/vpn-profiles
>                 |                                  /valid-provider-identifiers/qos-profile-identifier
>                 |                                  /id
>                 +--rw map-type?               identityref
>                 +--rw availability-type?      identityref
>                 +--rw (te)?
>                    +--:(vn)
>                    |  +--rw vn-ref?           -> /vn:vn/vn-list/vn-id
>                    +--:(te-topo)
>                    |  +--rw vn-topology-id?   te-types:te-topology-id
>                    |  +--rw abstract-node?
>                    |          -> /nw:networks/network/node/node-id
>                    +--:(te-tunnel)
>                       +--rw te-tunnel-list*   te:tunnel-ref
>
>
> Also, in L3SM, qos-profile can be locally defined under site-network-access and also mapped to classification rules defined there as described in 6.12.3.2/6.12.3.1. Then, te-service-mapping-yang should also map a VNAP to the local qos-profile even without vpn-service level mapping like this:
>
>      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:profile:
>        +--rw (te)?
>           +--:(vn)
>              +--rw vn-ap-ref?
>                      -> /vn:ap/access-point-list/vn-ap/vn-ap-id
>
>      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-ref?
>                      -> /vn:ap/access-point-list/vn-ap/vn-ap-id
>
> Although we may consider the same requirement to L2SM mapping, from our service objectives, the current definition is enough for now.
>
> How do you think?
>
> Thanks in advance,
> Kenichi
>
> --
> Kenichi Ogaki
> KDDI Corp. | Operation Automation Promotion Dept.
> +81-(0)80-5945-9138 | www.kddi.com
>
>
>

_______________________________________________
Teas mailing list
Teas@ietf.org
https://www.ietf.org/mailman/listinfo/teas