[Teas] consideration of 1 VPN to N VNs mapping

"Ogaki, Kenichi" <ke-oogaki@kddi.com> Tue, 04 August 2020 09: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 []) by ietfa.amsl.com (Postfix) with ESMTP id B3D0F3A1051; Tue, 4 Aug 2020 02:59:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0
X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id WWA9g1bdga8i; Tue, 4 Aug 2020 02:59:50 -0700 (PDT)
Received: from kddi.com (athena3.kddi.com []) by ietfa.amsl.com (Postfix) with ESMTP id B0DE93A104D; Tue, 4 Aug 2020 02:59:46 -0700 (PDT)
Received: from LTMC2121.kddi.com (post-send []) by kddi.com (KDDI Mail) with ESMTP id 79B1CE0054; Tue, 4 Aug 2020 18:59:45 +0900 (JST)
Received: from LTMC2145.kddi.com ([] []) by LTMC2121.kddi.com with ESMTP; Tue, 4 Aug 2020 18:59:45 +0900
Received: from LTMC2145.kddi.com (localhost []) by localhost.kddi.com (Postfix) with ESMTP id 504AD3A006B; Tue, 4 Aug 2020 18:59:45 +0900 (JST)
Received: from LTMC2151.kddi.com (post-incheck []) by LTMC2145.kddi.com (Postfix) with ESMTP id 4529F3A0065; Tue, 4 Aug 2020 18:59:45 +0900 (JST)
Received: from LTMC2151.kddi.com (localhost.localdomain []) by LTMC2151.kddi.com with ESMTP id 0749xiNQ002199; Tue, 4 Aug 2020 18:59:45 +0900
Received: from LTMC2151.kddi.com.mid_103909657 (localhost.localdomain []) by LTMC2151.kddi.com with ESMTP id 0749nhxj040160; Tue, 4 Aug 2020 18:49:44 +0900
X-SA-MID: 103909657
Received: from KDDI1801PC1319 ([] []) by post-smtp2.kddi.com with ESMTPA; Tue, 4 Aug 2020 18:49:43 +0900
From: "Ogaki, Kenichi" <ke-oogaki@kddi.com>
To: draft-ietf-teas-te-service-mapping-yang@ietf.org
Cc: teas@ietf.org, 宮坂 拓也 <ta-miyasaka@kddi.com>, 丹羽 朝信 <to-niwa@kddi.com>
Date: Tue, 04 Aug 2020 18:49:43 +0900
Message-ID: <003601d66a44$944a3560$bcdea020$@kddi.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-2022-jp"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AdZp751Do5Ui5IRiRIKW7ggpdXrXWg==
Content-Language: ja
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/U0oIjV0oTc8HtV2E_nWd8oJyahI>
Subject: [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: Tue, 04 Aug 2020 09:59:53 -0000

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 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
       +--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)?
                   |  +--rw vn-ref?           -> /vn:vn/vn-list/vn-id
                   |  +--rw vn-topology-id?   te-types:te-topology-id
                   |  +--rw abstract-node?
                   |          -> /nw:networks/network/node/node-id
                      +--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 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
       +--rw (te)?
             +--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
       +--rw (te)?
             +--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 Ogaki
KDDI Corp. | Operation Automation Promotion Dept.
+81-(0)80-5945-9138 | www.kddi.com