Re: [Teas] Definitions of VTN and Slice Aggregate in the drafts

Young Lee <younglee.tx@gmail.com> Tue, 16 March 2021 01:40 UTC

Return-Path: <younglee.tx@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 888243A16A7 for <teas@ietfa.amsl.com>; Mon, 15 Mar 2021 18:40:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, HTML_MESSAGE=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 pDIBu6wG-t1n for <teas@ietfa.amsl.com>; Mon, 15 Mar 2021 18:40:31 -0700 (PDT)
Received: from mail-oi1-x232.google.com (mail-oi1-x232.google.com [IPv6:2607:f8b0:4864:20::232]) (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 7BFD73A16AA for <teas@ietf.org>; Mon, 15 Mar 2021 18:40:31 -0700 (PDT)
Received: by mail-oi1-x232.google.com with SMTP id u62so20726145oib.6 for <teas@ietf.org>; Mon, 15 Mar 2021 18:40:31 -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; bh=Y28J4iqtnzVIF5nAMkbp+rAa8k92AbESPcWLZy9WK2U=; b=svBzfc/5OIoCNqwuwm5qX1zNZQDwSX2G9X0BpPlKT4wPBj+x8LrBt6TeWoBZzyFKTW lsEkMHWXbNBISaZdOxGm16IRbc54J/o87qu/0RG7R4qCEt6I6JFDCaYa0DeCmMQgPfE6 ybfnY+m6G4c8z3oNKAKlejPlea9Z0gngMEUy3zWUJAvDweidCehuln3yR6PjcpqiIH7D QHXedZU350oTu0/pDayw0urBlpHgxvQ/v7160mIssYlyhnMhApoHsbQg0pEQ/1mCk0Ou FL62bKPPoG+cwl3JMCR/JrCB4zZDlHwLtFBdPQ1A9sIMhAN5kQUtnckP4zC8JCh/UaNM yMyw==
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=Y28J4iqtnzVIF5nAMkbp+rAa8k92AbESPcWLZy9WK2U=; b=aQtFjfsXxNvmvCvlFtVWzrCboajXHXEZP8/p1eXQ38z/Fx10bwSVzMK1kyoKVTlC3k D7SfzZXTODspN8cWI0tS15LdrrVDGYJD/76c/DUkV8wnVFocE/+Cq/oj6KfGCL1p4ljp 5FjGHfUgfKcwje1Nc4cKXi6ZSWz0RFBUZ/T2cBs62MILuEzndUKzwf/l2UKtc0tKOwWD bmkDh37LKA+Bhtq78WxKU0pCLDTvbmxLYixJ1gJ67qkqho43rT3MJ4CTnOZY8ROplUGI lBiKpxDda9eZxdA6KyB/LQ5AYD2sJ7xEjzOYYxm9WJrA8wvDIBcV+XRXI92iSiR3lnWa KrUg==
X-Gm-Message-State: AOAM53040HuyqzU0NJf5ZCccVVt01074iQypze4KTc89qlbliFYp+d3J J7oEQMwCzBoZkCoUAiB6nByAg16x4duiCKG3M2M=
X-Google-Smtp-Source: ABdhPJw4+p0V6PtT10VLFKZWHRptP/BjFp3DSx22emZNFjhnZ/2hxKZBEa90ireN0MMI/TKkYKFAGoW8SuRG8nl2FlE=
X-Received: by 2002:aca:4c48:: with SMTP id z69mr1582889oia.61.1615858829156; Mon, 15 Mar 2021 18:40:29 -0700 (PDT)
MIME-Version: 1.0
References: <f1ca882deea4405981067c6d16a46d19@huawei.com> <AM0PR07MB549027D23F3542C55306E3E391919@AM0PR07MB5490.eurprd07.prod.outlook.com> <b3803b28b4064a78bc78c7b727dd937e@huawei.com> <0c5801d7167c$4b700fb0$e2502f10$@olddog.co.uk> <AM0PR07MB5490BB193E704133CF1E7776916C9@AM0PR07MB5490.eurprd07.prod.outlook.com>
In-Reply-To: <AM0PR07MB5490BB193E704133CF1E7776916C9@AM0PR07MB5490.eurprd07.prod.outlook.com>
From: Young Lee <younglee.tx@gmail.com>
Date: Tue, 16 Mar 2021 10:40:18 +0900
Message-ID: <CAGHSPWNb2uEGXkL8Os=eXscCz8UMVj6Lt9YzmCGtEkx06Yx9CQ@mail.gmail.com>
To: "Belotti, Sergio (Nokia - IT/Vimercate)" <sergio.belotti@nokia.com>
Cc: adrian@olddog.co.uk, "Dongjie (Jimmy)" <jie.dong@huawei.com>, Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>, TEAS WG <teas@ietf.org>, Young Lee <younglee.tx@gmail.com>
Content-Type: multipart/alternative; boundary="00000000000084e41b05bd9d7375"
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/9RaTLvETxZ0ZuYoZmgxk-4HRLGM>
Subject: Re: [Teas] Definitions of VTN and Slice Aggregate in the drafts
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, 16 Mar 2021 01:40:35 -0000

Hi all,

I concur with Sergio in this thread. VN has different levels of granularity
such that it can be at the same level as VTN. As Sergio well pointed out,
VN type 2 is a type of Virtual Network "topology" from which operators can
make use of it for its network operation such as mpls, SR, etc.

>From a modeling standpoint, all yang models pertaining to VN (such as VN
yang, TE service mapping, etc.) can be used for VTN contexts as is or can
be augmented for VTN use from existing VN models if need be.

Thanks.
Young

2021년 3월 15일 (월) 오후 9:44, Belotti, Sergio (Nokia - IT/Vimercate) <
sergio.belotti@nokia.com>님이 작성:

> Hi Adrian, Jie,
>
>
>
> Thanks for your replies.
>
> Sincerely , while I agree on the fact that VN and VTN are introduced for
> different purpose, nothing prevent to use the “same” concept for different
> context as soon as the concept is covering multiple requirement!
>
> So question is again what in VN is preventing to be used in an enhanced
> VPN.
>
> Adrian underlined that ACTN tool/mechanism is able to provide a network
> slice and then an enhanced VPN, and so I do not understand why a VN type 2
> for example should be different to what Jie described as VTN.
>
> Moreover , for VN, exists already a YANG to create a VN and in parallel a
> VN service mapping as well, so question is : is this model able to support
> a VTN as well or, even if for a similar concept , we need to have a
> separate YANG model ?
>
> A proliferation of different models are not good in my view without real
> needs.
>
>
>
> Thanks in advance
>
>
>
> Sergio
>
>
>
>
>
> *From:* Adrian Farrel <adrian@olddog.co.uk>
> *Sent:* Thursday, March 11, 2021 2:42 PM
> *To:* 'Dongjie (Jimmy)' <jie.dong@huawei.com>om>; Belotti, Sergio (Nokia -
> IT/Vimercate) <sergio.belotti@nokia.com>
> *Cc:* younglee.tx@gmail.com; 'Daniele Ceccarelli' <
> daniele.ceccarelli@ericsson.com>gt;; teas@ietf.org
> *Subject:* RE: [Teas] Definitions of VTN and Slice Aggregate in the drafts
>
>
>
> The line that stand out from this conversation for me is:
>
>
>
> > As for the VN concept defined in RFC 8453, to me the concept of VN and
> VTN looks similar, while they are introduced for different purposes.
>
>
>
> From my perspective, a VN (ACTN) is a topology carved out of the network
> and presented to the ACTN consumer, while a VTN (VPN+) is a topology carved
> out of the network for its own use in delivering enhanced VPNs. That looks
> pretty much what Jie said: same concept but for different purposes.
>
>
>
> FWIW, in draft-king-teas-applicability-actn-slicing we saw ACTN as a
> tool/mechanism that could be used to realise a network slice or an enhanced
> VPN. That is, it can build the virtual topology that underpins a network
> slice.
>
>
>
>
>
> I think a number of concepts are converging within TEAS. This should be
> cause for celebration, although it is not always easy to get full
> convergence.
>
>
>
> What we found when writing draft-king-teas-applicability-actn-slicing was
> that the terminology was not consistent. That, sadly, led us to have to
> define some of our own terms. I fully expect that as time progresses we
> will see continued convergence on terminology that will cause a number of
> us to have to update our drafts.
>
>
>
> Cheers,
>
> Adrian
>
>
>
> *From:* Teas <teas-bounces@ietf.org> *On Behalf Of *Dongjie (Jimmy)
> *Sent:* 11 March 2021 09:57
> *To:* Belotti, Sergio (Nokia - IT/Vimercate) <sergio.belotti@nokia.com>
> *Cc:* younglee.tx@gmail.com; Daniele Ceccarelli <
> daniele.ceccarelli@ericsson.com>gt;; teas@ietf.org
> *Subject:* Re: [Teas] Definitions of VTN and Slice Aggregate in the drafts
>
>
>
> Hi Sergio,
>
>
>
> Thanks for your support on the terminology clarification. It is important
> to have consistent understanding about the terminology before we could
> understand the relationship between different proposals.
>
>
>
> As for the VN concept defined in RFC 8453, to me the concept of VN and VTN
> looks similar, while they are introduced for different purposes.
>
>
>
> VN in RFC 8453 is to provide the customer with an abstracted view of the
> network based on YANG models. There are two modes to provide such view to
> customer: abstracted as a set of edge-to-edge links, or abstracted as a
> topology or virtual nodes and virtual links.
>
>
>
> While the term VTN was introduced to refer to the virtual underlay network
> in the layered architecture as described in draft-ietf-teas-enhanced-vpn,
> it is used to organize a subset of the network nodes and links, and
> allocate a set of network resources on these nodes and links to build a
> customized underlay network. Operator can instantiate multiple VTNs to
> carry different types of services, or the traffic of different customers.
> The customers does not necessarily need to be provided with the information
> of VTN.
>
>
>
> Another consideration was that the term VN is generic (not only defined in
> RFC 8453), thus could mean different things in different context. Thus we
> choose to use a dedicated term for the virtual underlay network.
>
>
>
> Hope this helps.
>
>
>
> Best regards,
>
> Jie
>
>
>
> *From:* Belotti, Sergio (Nokia - IT/Vimercate) [
> mailto:sergio.belotti@nokia.com <sergio.belotti@nokia.com>]
> *Sent:* Wednesday, March 10, 2021 5:18 PM
> *To:* Dongjie (Jimmy) <jie.dong@huawei.com>
> *Cc:* teas@ietf.org; Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>om>;
> younglee.tx@gmail.com
> *Subject:* RE: Definitions of VTN and Slice Aggregate in the drafts
>
>
>
> Hi Jie,
>
> Clarification on terminology is always a good effort to do  thanks for
> that.
>
> On the other hand I’d like to understand , about “VTN”, what is the
> difference in your VTN concept with respect what already defined in RFC
> 8453 in section 2.1?
>
> In that section there is a description also of the two types of VN ,
> customer can manage.
>
> A parallel effort with draft-ietf-teas-actn-vn-yang permits to “create”
> VN of the desired type.
>
> So my question is : what in your “new” VTN is different with respect what
> already defined related to VN to force using another term ?
>
>
>
> Thanks
>
> Sergio
>
>
>
>
>
>
>
>
>
>
>
> *From:* Teas <teas-bounces@ietf.org> *On Behalf Of *Dongjie (Jimmy)
> *Sent:* Tuesday, March 9, 2021 7:38 PM
> *To:* teas@ietf.org
> *Subject:* [Teas] Definitions of VTN and Slice Aggregate in the drafts
>
>
>
> Hi all,
>
>
>
> In today’s meeting, some people raised comments about the confusions
> caused by the multiple terms. To help the understanding with the term “VTN”
> and “Slice Aggregate”, I reread the text about their definitions and
> descriptions in each draft.
>
>
>
> Although the terminologies are described in different ways, IMO the
> essential information behind is the same: a logical network construct
> consists of the topology attribute and the network resources attributes.
>
>
>
> Some effort to resolve the terminology overlap could help to reduce the
> confusions and provide a consistent view on the framework and technologies
> for network slice realization.
>
>
>
>
>
> Here are the text about the terms quoted from each draft:
>
>
>
> - VTN (in draft-ietf-teas-enhanced-vpn-07):
>
>
>
> VPN+ is built from a VPN overlay and an underlying Virtual Transport
> Network (VTN) which has a customized network topology and a set of
> dedicated or shared resources in the underlay network.
>
>
>
> A VTN is a virtual underlay network that connects customer edge points.
> The VTN has the capability to deliver the performance characteristics
> required by an enhanced VPN customer and to provide isolation between
> separate VPN+ instances.
>
>
>
>
>
> - Slice Aggregate (in draft-bestbar-teas-ns-packet-02)
>
>
>
> This document introduces the notion of a slice aggregate which comprises
> of one of more IETF network slice traffic streams. It describes how a slice
> policy can be used to realize a slice aggregate by instantiating specific
> control and data plane behaviors on select topological elements in IP/MPLS
> networks.
>
>
>
> When logical networks representing slice aggregates are realized on top of
> a shared physical network infrastructure, it is important to steer traffic
> on the specific network resources allocated for the slice aggregate.
>
>
>
> Slice aggregate: a collection of packets that match a slice policy
> selection criteria and are given the same forwarding treatment; a slice
> aggregate comprises of one or more IETF network slice traffic streams; the
> mapping of one or more IETF network slices to a slice aggregate is
> maintained by the IETF Network Slice Controller.
>
>
>
>
>
> - Slice policy (in draft-bestbar-teas-ns-packet-02, to help the
> understanding of Slice Aggregate)
>
>
>
> Slice policy: a policy construct that enables instantiation of mechanisms
> in support of IETF network slice specific control and data plane behaviors
> on select topological elements; the enforcement of a slice policy results
> in the creation of a slice aggregate.
>
>
>
> A slice policy topology may include all or a sub-set of the physical nodes
> and links of an IP/MPLS network; it may be comprised of dedicated and/or
> shared network resources (e.g., in terms of processing power, storage, and
> bandwidth).
>
>
>
> Best regards,
>
> Jie
>
>
>