[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 [127.0.0.1]) 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-Level:
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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WWA9g1bdga8i; Tue, 4 Aug 2020 02:59:50 -0700 (PDT)
Received: from kddi.com (athena3.kddi.com [27.90.165.196]) 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 [10.206.2.120]) by kddi.com (KDDI Mail) with ESMTP id 79B1CE0054; Tue, 4 Aug 2020 18:59:45 +0900 (JST)
Received: from LTMC2145.kddi.com ([10.206.0.236] [10.206.0.236]) by LTMC2121.kddi.com with ESMTP; Tue, 4 Aug 2020 18:59:45 +0900
Received: from LTMC2145.kddi.com (localhost [127.0.0.1]) 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 [10.206.0.239]) 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 [127.0.0.1]) 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 [127.0.0.1]) by LTMC2151.kddi.com with ESMTP id 0749nhxj040160; Tue, 4 Aug 2020 18:49:44 +0900
X-SA-MID: 103909657
Received: from KDDI1801PC1319 ([10.211.4.86] [10.211.4.86]) 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>, =?iso-2022-jp?B?GyRCNVw6ZBsoQiAbJEJCc0xpGyhC?= <ta-miyasaka@kddi.com>, =?iso-2022-jp?B?GyRCQzAxKRsoQiAbJEJEKz8uGyhC?= <to-niwa@kddi.com>
Date: Tue, 4 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
X-TM-AS-GCONF: 00
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 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