Re: [Teas] FW: The word "transport"

Adrian Farrel <adrian@olddog.co.uk> Fri, 01 May 2020 10:40 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 786E13A0E67 for <teas@ietfa.amsl.com>; Fri, 1 May 2020 03:40:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.107
X-Spam-Level: ***
X-Spam-Status: No, score=3.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_SUMOF=5, HTML_MESSAGE=0.001, MAY_BE_FORGED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no 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 gLgUvlZrt5Jb for <teas@ietfa.amsl.com>; Fri, 1 May 2020 03:40:05 -0700 (PDT)
Received: from mta8.iomartmail.com (mta8.iomartmail.com [62.128.193.158]) (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 C0FFA3A0E63 for <teas@ietf.org>; Fri, 1 May 2020 03:40:04 -0700 (PDT)
Received: from vs1.iomartmail.com (vs1.iomartmail.com [10.12.10.121]) by mta8.iomartmail.com (8.14.4/8.14.4) with ESMTP id 041AdwJt029732; Fri, 1 May 2020 11:39:58 +0100
Received: from vs1.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 9273B2203D; Fri, 1 May 2020 11:39:58 +0100 (BST)
Received: from asmtp2.iomartmail.com (unknown [10.12.10.249]) by vs1.iomartmail.com (Postfix) with ESMTPS id 7BEB32203C; Fri, 1 May 2020 11:39:58 +0100 (BST)
Received: from LAPTOPK7AS653V (81-174-202-163.bbplus.pte-ag2.dyn.plus.net [81.174.202.163] (may be forged)) (authenticated bits=0) by asmtp2.iomartmail.com (8.14.4/8.14.4) with ESMTP id 041AdvM3018267 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 1 May 2020 11:39:57 +0100
Reply-To: <adrian@olddog.co.uk>
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: "'Gyan Mishra'" <hayabusagsm@gmail.com>
Cc: "'Kiran Makhijani'" <kiranm@futurewei.com>, "'Rokui, Reza \(Nokia - CA/Ottawa\)'" <reza.rokui@nokia.com>, <teas@ietf.org>
References: <036501d61f26$01756f20$04604d60$@olddog.co.uk> <BYAPR13MB2437871D5E6BEF87D2625E93D9AA0@BYAPR13MB2437.namprd13.prod.outlook.com> <03b401d61f39$54b5dd10$fe219730$@olddog.co.uk> <CABNhwV3--ZHEXn4AUDnYK4nui30+Bdzg1O4tEVmyo26jcvvUVQ@mail.gmail.com>
In-Reply-To: <CABNhwV3--ZHEXn4AUDnYK4nui30+Bdzg1O4tEVmyo26jcvvUVQ@mail.gmail.com>
Date: Fri, 1 May 2020 11:39:56 +0100
Organization: Old Dog Consulting
Message-ID: <040301d61fa4$dbc18a00$93449e00$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0404_01D61FAD.3D8778A0"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQIMCNRaZu8YlTaDCQfeAjf3ZILbpAHx1utmAaryWbsB2GgLIaf7enGw
Content-Language: en-gb
X-Originating-IP: 81.174.202.163
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-25388.006
X-TM-AS-Result: No--19.244-10.0-31-10
X-imss-scan-details: No--19.244-10.0-31-10
X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-25388.006
X-TMASE-Result: 10--19.244400-10.000000
X-TMASE-MatchedRID: CxmI61mtwh/xIbpQ8BhdbPHkpkyUphL9cf2CPmeUCZIgVZAf8m502BI0 ePrNo/nEx/bXrtw1NMMd9VdYNF//TMBKr4imXqxdK38M2xNIED4GchEhVwJY36uPvo9L6iaI+yC s1rvYFxkaPgU4yxGLPY/u5k7ql+UrnDY0xTYUoiPkNIw8RlACQwXj39T+BEfAiiKPXbEds+4B72 Mq/WfuZbgZuKrMowN5DKFWFyH74EQQ2aZ0TW4Fs5JrW03DacWE+JzoxrXf65+fcVJ8cL8ZO7UKD HDysN3BExaX1SYY/Ljj24yk+tIzDiMHE9ficJn5uO128yD8AiakdO7TbvbzY6zG9MIKeG/GfMrd D3NIUvtt0RwPzMWcT6yDYF/RX6N8QGBjcDuzIXNT2G3xw+NXjrCouBF2/ACKb/1uHmr1Emrml4g WJwZxbGHUBKZY3HaYAnalUMYc0Au+KpxDEf1mdoR4m9rj7TBdKWPnYJ5Ay2qWkhVMjO7PJMB02e mAKhC/BE/SxjniJa01rrFxknkX8BGAnkzMqN/K73UEGh+e8carXHPgDIHtLbRIf4my3wrpZHArZ 0h7iz7eG4g/KMgj9Xz1N2UTHmwrGvrGmKKpCuxHgxQfODgFAPIK8gK4rjpyFFn/3AEyEaz8dUUy WFBKxzfXuOc9HGEQ/x6CKmJG+/uqyBpCcY/yE0sh+mzT1UnbQ8iUCoDj8MRWPcnrekBHfPUqYtl 6V4CkR7vEOuechPYwTAUA2KZx2ecLkvJgnAPfBi0Si9jXsY0WHdnAxY94IRHfiujuTbedsYX5Wj i8DDr0xfB7XAxSv/iuQHmnlKyFUkHjOEAPbq+eAiCmPx4NwGmRqNBHmBve1B0Hk1Q1KyKh5DOWG PdqWf306Q4zhC4D4kYXbobxJbLLLrRfL5Fh4ZAC+aCOH0oB410A+sSntyUBjYZcrgpYrw+G/eoV ik4Lb1dA6MRg27YZiw5Lvko8sHwoDbr0F4CUO9xv/JcBH8kdpTNyMpJhfw==
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/R-yRf0zyx-F_6Jdt5k2Lue4dk3I>
Subject: Re: [Teas] FW: The word "transport"
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: Fri, 01 May 2020 10:40:08 -0000

Hi Gyan,

 

> I agree with the confusion of just the word “VPN” by itself

> can mean many different things.  

 

Good, we start from a point of agreement 😊

 

> VPN by itself usually means the “vpn technology” client to

> net various flavors of a VPN tunnel such as IPSEC or SSL.

> 

> Also could be net to net router to router IPSEC tunnel P2P

> or P2MP MGRE DMVPN with the many flavors as well.

> 

> Usually when VPN is mentioned in the context of “service”

> it’s mentioned as Layer 3 vpn service overlay, which could

> be over any underlay MPLS, SR flavors SRv6 or SR-MPLS or

> MPLS-In-GRE or MPLS-in-UDP.

 

I think this is where I disagree. It seems to me that you are coming at this from the perspective of an equipment engineer that makes boxes and protocols to enable network operators to deliver VPN services, or from the perspective of a network engineer tasked with building a network and delivering a service. And why shouldn’t you have that perspective? It’s where you’re standing, and perfectly fine.

 

But imagine that you are a customer (perhaps an enterprise) commissioning a VPN service. You are interested in the end points that are connected, and you care about the SLA/SLO. But when you say “VPN” you don’t mean SRv6 or MPLS-TE or whatever (unless you are one of those annoying customers that network operators really hate).

 

And, obviously, the network operator sitting in the middle. For them a VPN is both the service sold and the technology used.

 

So (clearly?), the use of the term “VPN” is context specific and somewhat fragile. I think “transport” falls into this class as well.

 

The solution is to either avoid using the terms, or to be really careful to provide sufficient and clear context.

 

> From the subject heading my take on the definition of “transport”

> in the context of VPN+ or Enhanced VPN transport slicing is as follows.

> 

> When I think of transport I think of the physical underlying resource

> and hardware that makes up the physical infrastructure as a whole.

 

Well, I understand that interpretation. It’s a common interpretation and the one typically seen in CCAMP.

 

I don’t think that the VPN+ work uses that definition, and I think it is (attempts to be) clear on that point.

 

> When I think of the word “transports”  in the context of RSVP TE

> I think of SRLG definition below of links that share common fate

> - “ fate sharing” in the context of FRR n:1 facility protection or

> node protection.

> 

> The term “slice” I think of a slice of a pie where the sum of the

> parts equal the whole.  

> 

> In the context of slicing I think 3D dimensionally as if cutting a pie

> which could be a cross section of the networks if you look at in a

> 3D logical construct.

> 

> So you can think of the network as multi dimensional and take

> multiple cross sections of the network from which you get the

> layers construct that make up the physical topology.

 

That may all be a bit complex, but I understand what you are saying.

 

> So from a layer perspective just about every topology that

> involves some kind of tunneling of traffic has the concept of

> overlay and underlay.

 

Like John says, this may be a more useful terminology.

 

> In the MPLS or SR world you can think of a 2 level deep label

> stack where the topmost transport label is the “underlay” and

> the service label bottom of stack being the overlay.

> 

> So then going full circle looking at VPN+ or Enhanced VPN (EVPN)

> framework sits in the overlay.  

> 

> I would not call it transport overlay as the underlay is the topmost

> label underpinnings of resources isolation that you are trying to 

> pin the EVPN overlay service to.

> 

> I think however since we are cutting the network so cross sectionally

> and not horizontally it is more like a transport slice of the network pie. 

 

That’s probably a circular thing because that’s your definition of a transport slice.

 

> I think if it was just a regular L3 VPN it would be an overlay would be

> the right description but since we are carving our underlying resources

> for this VPN service I agree it’s more like a transport slice.

 

Well, playing with terminology a bit, yes, an L3VPN is an overlay when seen from outside. But when seen in the underlay, a L3VPN that is realised using TE tunnels that have resource reservations and follow specific paths (possibly avoiding other traffic, and possibly providing resilience) is using a “slice” of the underlay network.

 

> There was a long thread on this similar topic with Xie on using

> Isis MT for transport slicing.

> 

> https://tools.ietf.org/html/draft-xie-lsr-isis-sr-vtn-mt-00

 

Thanks for that pointer. I think this further serves to indicate that we need to clean up the terminology.

 

> So now how would the isolation work with this EVPN or VPN+

> transport slice that has its own dedication resources.

 

Well, now we are firmly in solution space and not talking about terminology or architecture.

Isolation is well described in draft-ietf-teas-enhanced-vpn and it is technology-dependent. For example, if the underlay is WDM, isolation might involve using different lambdas for different slices. OTOH, if the underlay is packet, isolation might require selection of non-overlapping paths (i.e., physical resources), of the reservation of different pools of buffers, or simply using different identifiers (such as labels).

 

I do suggest reading the document.

 

> Most vendors and modern routers have the Virtual router 

> concept vPE or vP, similar to NFV like VNF containers for

> network functions.  So let’s say on a MPLS or SR core where

> you are have a white box solution on merchant silicon and

> have virtualization containers built.  So for each P and PE

> router you have a dedicated container with dedicated

> resources memory for the EVPN as it needs special

> treatment for 5G RAN front and back hauls.  The remaining

> L3 VPNs on the core boxes sit in a BAU container with

> shared resources.  So there maybe cases where you might

> have multiple EVPNs that need dedicated resources and for

> those you have virtual router carved up enough resources to

> meet the applications requirement.  So with the draft

> mentioned each EVPN would sit isolated in its own Isis mt

> instance providing complete control plane isolation on top of

> the above router virtualization container based isolation.

 

This is a fine way to deliver an enhanced VPN service or a network slice service. I would say it is only one way of doing it out of many ways.

 

Best,

Adrian