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

Dhruv Dhody <dhruv.ietf@gmail.com> Tue, 04 August 2020 10:54 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 C867A3A03EC; Tue, 4 Aug 2020 03:54:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.198
X-Spam-Level:
X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[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 iENtH5RuMnzy; Tue, 4 Aug 2020 03:54:40 -0700 (PDT)
Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com [IPv6:2607:f8b0:4864:20::d34]) (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 4AD393A03EA; Tue, 4 Aug 2020 03:54:40 -0700 (PDT)
Received: by mail-io1-xd34.google.com with SMTP id g14so4199303iom.0; Tue, 04 Aug 2020 03:54:40 -0700 (PDT)
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:content-transfer-encoding; bh=H7JUHzPwbsopeh/fCp4J/u6oQgy7JIUW281xyhPXRbo=; b=NNovq4KoW4/AMy02VfHE2IuMdbchaR9PujQt8wEPVTpuUppR3x/WacXwt+B+x3i4lH eWd+mG87y/WlZzDdpxIpM9e7aNBzW4fExI4DAzJXQVwPfq0++nEAOBu1xCYQ2iQwgQlN QHXhcaaQHJ95oGz646FlfeCzTlX5w+AcqP/nT/saBmI+l0i8X8OOm4xqpm1vGPSEe1o4 Xx5ihUIgYC322BKHWYp719HVMZ5DFWhbR65pwLOpvbVdQuDIFc1m4rGB8uiMcHmN90tm 76rlilyK9L44hMVjtQnOP4tq3pHD3YEqe2V+G65/6VENWGCWnZBClN4rZgkwY03gOGN7 Se1g==
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:content-transfer-encoding; bh=H7JUHzPwbsopeh/fCp4J/u6oQgy7JIUW281xyhPXRbo=; b=QIRku1u7pV8EaxXnffHzesA2PiCubYRTJmRK06+cwjmgpVdZ9dDueW52VC6o7REtda mrVvLTMbLLr+kZ8rMiKrxdZO7GuLkx38nPeyw211io57h8AH8g7mTL18pL5hWjYv9MyN CHlC18GFBc8Im87Ousa1tS+wI8/f+mXsll/zqTJJiCH9ZLLSjA2E/GFBJR8VyTQNfAEI JafOErFAL8rtH9YrdXI4XVmXJe56G24/NNH/YA60XmRc7EFJsLBNq1aD8P2e4sz1MHMi gZCbLEtm3LpbFXfFOwCqkFCTDBBGsyOdgOWa6IkLSf98XE/d32WURmlCAC9ryfkBMUK+ LFUQ==
X-Gm-Message-State: AOAM531ReK36YsvSCyDqTAqU+JEe/TsfgDLFgutKjrhHhC0EkRiz38og GMwqQG0eSvSK23PgXZrJbAs72rSQRM6ibeD9NJH2doZxewc=
X-Google-Smtp-Source: ABdhPJz811EcDZCgtKovs50ZdgZn6Dd/eyF5GRjWVtOqDzpqGiuxQiC9CBxuthvWS2FJDyFffwGWxYvHY/i+2SBDGUQ=
X-Received: by 2002:a02:ac4:: with SMTP id 187mr4925016jaw.71.1596538479175; Tue, 04 Aug 2020 03:54:39 -0700 (PDT)
MIME-Version: 1.0
References: <003601d66a44$944a3560$bcdea020$@kddi.com>
In-Reply-To: <003601d66a44$944a3560$bcdea020$@kddi.com>
From: Dhruv Dhody <dhruv.ietf@gmail.com>
Date: Tue, 4 Aug 2020 16:24:02 +0530
Message-ID: <CAB75xn5u4s8oypHH0px_JVhu4HeYCos5YdUS9eQ750cg4aYdYQ@mail.gmail.com>
To: "Ogaki, Kenichi" <ke-oogaki@kddi.com>
Cc: draft-ietf-teas-te-service-mapping-yang@ietf.org, "TEAS WG (teas@ietf.org)" <teas@ietf.org>, =?UTF-8?B?5a6u5Z2CIOaLk+S5nw==?= <ta-miyasaka@kddi.com>, =?UTF-8?B?5Li55769IOacneS/oQ==?= <to-niwa@kddi.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/my-NHJdbyuL-0-53cep9jksFa2k>
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: Tue, 04 Aug 2020 10:54:42 -0000

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
>
>
>