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

Adrian Farrel <adrian@olddog.co.uk> Thu, 11 March 2021 13:43 UTC

Return-Path: <adrian@olddog.co.uk>
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 978D43A0C8F for <teas@ietfa.amsl.com>; Thu, 11 Mar 2021 05:43:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.916
X-Spam-Level:
X-Spam-Status: No, score=-1.916 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_NONE=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 Fqf5UGkq-6wz for <teas@ietfa.amsl.com>; Thu, 11 Mar 2021 05:43:43 -0800 (PST)
Received: from mta7.iomartmail.com (mta7.iomartmail.com [62.128.193.157]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 550E93A0C49 for <teas@ietf.org>; Thu, 11 Mar 2021 05:43:43 -0800 (PST)
Received: from vs3.iomartmail.com (vs3.iomartmail.com [10.12.10.124]) by mta7.iomartmail.com (8.14.4/8.14.4) with ESMTP id 12BDfsjL030105; Thu, 11 Mar 2021 13:41:54 GMT
Received: from vs3.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 0EB2D22040; Thu, 11 Mar 2021 13:41:54 +0000 (GMT)
Received: from asmtp1.iomartmail.com (unknown [10.12.10.248]) by vs3.iomartmail.com (Postfix) with ESMTPS id 00C7822032; Thu, 11 Mar 2021 13:41:53 +0000 (GMT)
Received: from LAPTOPK7AS653V ([84.93.2.123]) (authenticated bits=0) by asmtp1.iomartmail.com (8.14.4/8.14.4) with ESMTP id 12BDfqS6025282 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 11 Mar 2021 13:41:52 GMT
Reply-To: <adrian@olddog.co.uk>
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: "'Dongjie \(Jimmy\)'" <jie.dong@huawei.com>, "'Belotti, Sergio \(Nokia - IT/Vimercate\)'" <sergio.belotti@nokia.com>
Cc: <younglee.tx@gmail.com>, "'Daniele Ceccarelli'" <daniele.ceccarelli@ericsson.com>, <teas@ietf.org>
References: <f1ca882deea4405981067c6d16a46d19@huawei.com> <AM0PR07MB549027D23F3542C55306E3E391919@AM0PR07MB5490.eurprd07.prod.outlook.com> <b3803b28b4064a78bc78c7b727dd937e@huawei.com>
In-Reply-To: <b3803b28b4064a78bc78c7b727dd937e@huawei.com>
Date: Thu, 11 Mar 2021 13:41:51 -0000
Organization: Old Dog Consulting
Message-ID: <0c5801d7167c$4b700fb0$e2502f10$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0C59_01D7167C.4B720B80"
X-Mailer: Microsoft Outlook 16.0
Content-Language: en-gb
Thread-Index: AQMKAe1H/rgSJ2gm/ueP3hfWa5RKNgGPWLl8AnmrO6mn+JFA8A==
X-Originating-IP: 84.93.2.123
X-Thinkmail-Auth: adrian@olddog.co.uk
X-TM-AS-GCONF: 00
X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-26022.007
X-TM-AS-Result: No--12.237-10.0-31-10
X-imss-scan-details: No--12.237-10.0-31-10
X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-26022.007
X-TMASE-Result: 10--12.237300-10.000000
X-TMASE-MatchedRID: 8HTFlOrbAtHxIbpQ8BhdbKFZVq54FlNtC/ExpXrHizzXLRpcXl5f6Bfo +oVE2PIvTh+E4yDwGZGvvsgXtIcLUPw6RJrswLb7F+qQpCWTUjnNUTeBBPKQKgbYcy9YQl6elBO SDMO8djZDCZtXRqGp/F9lT2CKLCMprtKweE8yi74ZSUX8zcPGn0pFpc3bJiMeUNzg/KvQ9bCFtY 9TIRKBBAiJz1fDMs22VqLfJbU97vFJH11OOVB0yRHJWwDGGGOsgo5TZBCwajQL9Tj77wy87A5dN gvJ7+7bHfL0dHEYEEr21ZTKBNQQO5piU2kgoGALiH95tLFH8eelGCIMbr7g/ivFSzw3D/Z+6xA6 W+g6jMbXfpUWgdmCb7pY0oZieZ+maK3mKGuKez3ece0aRiX9WhPODiE0SGEzn5WqE8nKuIwF17c PlENBU9L/LCOAVoMfW5JV7BRZSoZ/wY3UEtU7dkAvdL4TzpZNOAqrFEqWlRvHkH7uosEn7OSdyJ Wu1BTvUns8NUv15w/ol/g2J9L5PIQR9kPVE+jna0FTUMKjrmseRZr2cxRELg34XnXcobKr5Uqmw lidH3QiNSLNAwC4lXxyUvGGcNK1R820eGH8bXrIAZuQZThlLi58R61qYYYElxFltl7liQd9DbxP ux6UnO4Gf3TQ+IfTAecn0+sCgGPybSXiGX6jIuqDKkj02EZ1yeUl7aCTy8ivcOJbZ17mD7NtCD9 U3Mz4kkIrx6iwQjvj2hhsFJdmFcBzhcxULSkYXK5keCa+bmjRU0epp2zeCzXSEULATMS5eWVDzK c/sptgBsHA1L8d7Y5Gyml5vOdN1N8SX/hfsySeAiCmPx4NwGmRqNBHmBvevqq8s2MNhPAL4KbF8 qbADGF5X5yuwToh9kZRY1gbk4Ue4VQzrBShC6m///xCZsaD/iVhbGdPW9oMpP58CZkNzBJ+oKAf s1lHDa5/wZNeZ8L7NW0y6vSN4jYbw5UoGfxbxiN4Dw7zBhs=
X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/MQDUe5NMkkB_LSinzLgzogTuH6g>
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: Thu, 11 Mar 2021 13:43:47 -0000

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>om>; 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] 
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 <mailto:teas-bounces@ietf.org> > On Behalf
Of Dongjie (Jimmy)
Sent: Tuesday, March 9, 2021 7:38 PM
To: teas@ietf.org <mailto: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