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

Gyan Mishra <hayabusagsm@gmail.com> Fri, 01 May 2020 05:19 UTC

Return-Path: <hayabusagsm@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 A25A23A074E for <teas@ietfa.amsl.com>; Thu, 30 Apr 2020 22:19:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.003
X-Spam-Level: ***
X-Spam-Status: No, score=3.003 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, GB_SUMOF=5, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 kRDRe5MgrGzf for <teas@ietfa.amsl.com>; Thu, 30 Apr 2020 22:19:32 -0700 (PDT)
Received: from mail-il1-x130.google.com (mail-il1-x130.google.com [IPv6:2607:f8b0:4864:20::130]) (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 4468B3A0747 for <teas@ietf.org>; Thu, 30 Apr 2020 22:19:32 -0700 (PDT)
Received: by mail-il1-x130.google.com with SMTP id q10so3624912ile.0 for <teas@ietf.org>; Thu, 30 Apr 2020 22:19: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=6hcw4hDJYl1glH/xjYe1oWfqP19sYKEd8xEKh+4Udiw=; b=F4o+Fw5cCdEQZYFB5BSj/UiU/rwElnawU7Q47UN0uFwfmvpHSs75GzzTkeUYJui4E0 eXafPz7MTC2lw0ITprbTIzVMAxikQmQKizo2Tu0EaasmdT0eCCE1BRT1XB8yDAXW9c/n xLzW/URbxAkoZG0f03sZmyqSFoL0w2lo4DshVcnhTcGBUcFVzQXZR/biK6JjaXIuOEaI ruSDCyK/heE23g9CxhXlESa17b22wcqQBQd7HF5Fka4ots9A/GyFBtkIRCKC5B+MTMdO zwiAfjqB0iv9Tu28kfxRyYEAdQaUebWXqqcPKASfOJQsIzVGuaQzaAMy/8PqXvwUwf8H fHUg==
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=6hcw4hDJYl1glH/xjYe1oWfqP19sYKEd8xEKh+4Udiw=; b=qyR0dGY1siOU5T8ydfJJaSB72zdJHq7fbmT/WlJYH0ebJsc/1q5IPdXp+tWQhPQoyi hBW+ehKf1xbgeXlsLLMP7Ef9VibH/suo+1fLHSGrm23dtGS32QmiHp78gSHJXf7okBai w3EczWgtvC9UEiDksdgnaRfsSkbHDIRg9TEBiN3lnAYyiuwEhk/Iy8qHEK3VhzjhRb2R RBJC0CA7VaGcQcK1wyq936PE0s9TvTYrSNgSPI9NSYHklwY1JAlZxhf1qhgwTzxPXqZh JDa9hV5yH/b/NZ/bryozm50DeUnAdqZtmy2N1T+CRGAJxn18SKbPTK8cccMsFz2VV4f9 ehHQ==
X-Gm-Message-State: AGi0PubMNCziikw2C/qi2K4AiC56FR8HQEZf1Ran+sEwUWEwwdjxPkTd U8CqEz2owsGBTA/K+rxVdPPr3eL/F5LYvov1MzglNBjjKzU=
X-Google-Smtp-Source: APiQypJm7WZ4KEx7zVKSGWPsKi1tHa5pRiFlsOOSKQ9YQfnIlmjZcbyPlVsBLLL9X61eK/wafbSGo8PWTXU18JQ1z1M=
X-Received: by 2002:a92:6b04:: with SMTP id g4mr2115261ilc.82.1588310370326; Thu, 30 Apr 2020 22:19:30 -0700 (PDT)
MIME-Version: 1.0
References: <036501d61f26$01756f20$04604d60$@olddog.co.uk> <BYAPR13MB2437871D5E6BEF87D2625E93D9AA0@BYAPR13MB2437.namprd13.prod.outlook.com> <03b401d61f39$54b5dd10$fe219730$@olddog.co.uk>
In-Reply-To: <03b401d61f39$54b5dd10$fe219730$@olddog.co.uk>
From: Gyan Mishra <hayabusagsm@gmail.com>
Date: Fri, 1 May 2020 01:19:18 -0400
Message-ID: <CABNhwV3--ZHEXn4AUDnYK4nui30+Bdzg1O4tEVmyo26jcvvUVQ@mail.gmail.com>
To: adrian@olddog.co.uk
Cc: Kiran Makhijani <kiranm@futurewei.com>, "Rokui, Reza (Nokia - CA/Ottawa)" <reza.rokui@nokia.com>, teas@ietf.org
Content-Type: multipart/related; boundary="0000000000006ac79505a48f538e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/pf3Vkygy5SiG-iL-G2ZqpeyqQwI>
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 05:19:38 -0000

Chiming in..

I agree with the confusion of just the word “VPN” by itself can mean many
different things.

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.

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

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.

So from a layer perspective just about every topology that involves some
kind of tunneling of traffic has the concept of overlay and underlay.

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.

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.

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

So now how would the isolation work with this EVPN or VPN+ transport slice
that has its own dedication resources.

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.


Kind regards

Gyan
Verizon



On Thu, Apr 30, 2020 at 5:50 PM Adrian Farrel <adrian@olddog.co.uk> wrote:

> Hey,
>
>
>
> Not sure if you mean “the relationship to the existing document” or “the
> relationship to VPN+”.
>
>
>
> The relationship to VPN+ is really about how you view a service that is
> network slice: i.e., a collection of end-points, the connectivity between
> them, the level of service. Enhanced VPN is simply another way of thinking
> about a network slice.
>
>
>
> Probably, as I said to Reza, there is confusion between “VPN as a service”
> and “VPN as a set of technologies for delivering a service.” As engineers
> we often get confused between the two concepts, but we shouldn’t.
>
>
>
> Yes, you’re right: if we describe ‘transport’ in our context this will
> help avoid confusion. That’s what I was trying to suggest in my email. I
> was also suggesting that suitable text can be found in the enhanced VPN
> draft, just the way that suitable text for describing a slice was found
> there.
>
>
>
> The relationship to the existing document is a different question. I would
> like to understand how we resolve that so that we can put our efforts into
> the right documents.
>
>
>
> Best,
>
> Adrian
>
>
>
> *From:* Kiran Makhijani <kiranm@futurewei.com>
> *Sent:* 30 April 2020 21:58
> *To:* adrian@olddog.co.uk; 'Rokui, Reza (Nokia - CA/Ottawa)' <
> reza.rokui@nokia.com>
> *Cc:* teas@ietf.org
> *Subject:* RE: [Teas] FW: The word "transport"
>
>
>
> Hello Adrian,
>
> Thanks for many interesting points below.
>
> If we describe what ‘transport’ is in the context of the slices, (use
> hyphenated  transport-slice 😊) perhaps it’s ok?  (The enhanced VPN
> relationship is a lengthier discussion).
>
> -Kiran
>
>
>
> *From:* Teas <teas-bounces@ietf.org> *On Behalf Of *Adrian Farrel
> *Sent:* Thursday, April 30, 2020 12:32 PM
> *To:* 'Rokui, Reza (Nokia - CA/Ottawa)' <reza.rokui@nokia.com>
> *Cc:* teas@ietf.org
> *Subject:* [Teas] FW: The word "transport"
>
>
>
> Reza,
>
>
>
> Thanks for forwarding this email.
>
>
>
> I appreciate and understand the way that 3GPP use the term “transport”. It
> makes a lot of sense in the 3GPP context: they are talking about
> connectivity in their realm, and anything that provides that connectivity
> (such as an IP network) counts as “transport”.
>
>
>
> But we are not the 3GPP and our terminology needs to be consistent. As I
> noted, we already have multiple meanings of transport:
>
>    - The transport layer (traditional from the OSI model) that includes
>    TCP, UDP, etc.
>    - Transport networks (a term also used in the ITU-T) that embraces
>    Ethernet, TDM, and optical technologies that carry packets for us. This
>    term is most often seen in CCAMP, TEAS, and PCE.
>    - MPLS-TP (possibly deriving from the ITU-T’s T-MPLS) that refers to
>    the use of MPLS as a technology to build transport networks as described in
>    the previous bullet
>    - Transport as a verb (such as in HTTP) meaning simply ‘to carry’
>
> In the ACTN work, we moved from ‘transport’ to ‘TE’ recognising that ACTN
> was applicable to any network type where paths could be computed and
> imposed, and resource partitioned and reserved.
>
>
>
> Now, you say Transport networks (which are technology specific) are used
> to realized “Transport Slices” which would appear to imply that IP cannot
> be used to realise a transport slice. I don’t know if that is your
> intention.
>
>
>
> You also say They [3GPP] did not define anything related to Transport but
> you say that immediately under a figure you have copied from 3GPP TS
> 28.530 that clearly shows transport slices, so that leaves me more than a
> little confused.
>
>
>
> Additionally, you say…
>
> VPN is one of the  solutions to realize the transport slices in IP
> networks.
>
> …which is fine by me since I am not (here) talking about solutions but
> services. Actually, I think you would do well to distinguish between VPN as
> a service and the technologies used to realise a VPN.
>
>
>
> Then…
>
> However, The idea of Transport Slice is to allow a high-level system (or
> consumer or an Orchestrator) to ask for a various connections (i.e.
> Transport slices)
>
> … This is pretty meaningless the way you have worded it. You have said
> “the idea of a transport slice is to all a request for transport slices...
>
> across  IP, Optics, PON, Microwave or any combination of these networks.
> We shall not limit ourselves to IP VPN.
>
> …Yes, indeed. I wonder where the idea of such a limitation came from…
>
> Note that the definition of the Transport slice is technology agnostic.
>
> …I know. It comes from draft-ietf-teas-enhanced-vpn. That originated in
> draft-king-teas-applicability-actn-slicing. I believe I drafted it…
>
> [snip]
>
> In summary, since the connectivity between various endpoints are across
> transport network (i.e. IP, Optics, PON, Microware etc.), it is logical to
> assume the Connections are called Transport Slice.
>
> …which is fine except that you have moved the problem to the definition of
> “transport network”. The IETF will struggle, I think, with the idea that an
> IP network is a transport network unless, in the context of these
> documents, you give a very clear explanation of what these documents mean
> by that term.
>
>
>
> But perhaps we can cut through all of this with some simple clarity. Text
> to describe the context and meaning of ‘transport’. Since the terminology
> document has so cheerfully plundered the enhanced VPN framework draft for
> some text, you might look there (in the Introduction) for suitable
> context-setting text.
>
>
>
> That, of course, leads me to a separate question that I have, which is why
> the design team is reproducing and/or copying material from an existing WG
> document rather than working with that document to refine it and/or split
> it into multiple documents. A different question, but one the chairs might
> like to comment on.
>
>
>
> Best,
>
> Adrian
>
>
>
> *From:* Teas-ns-dt <teas-ns-dt-bounces@ietf.org> *On Behalf Of *Rokui,
> Reza (Nokia - CA/Ottawa)
> *Sent:* 30 April 2020 16:23
> *To:* teas@ietf.org; teas-ns-dt@ietf.org
> *Cc:* Rokui, Reza (Nokia - CA/Ottawa) <reza.rokui@nokia.com>
> *Subject:* [Teas-ns-dt] FW: The word "transport"
>
>
>
> All,
>
>
>
> I thought I sent this to TEAS and TEAS-NS-DT team before. Forwarding the
> response to everyone.
>
>
>
> Cheers,
>
> Reza
>
>
>
>
>
>
>
> *From: *Reza Rokui <reza.rokui@nokia.com>
> *Date: *Saturday, April 25, 2020 at 11:37 PM
> *To: *Dhruv Dhody <dhruv.ietf@gmail.com>om>, Jari Arkko <jari.arkko@piuha.net>et>,
> "draft-nsdt-teas-transport-slice-definition@ietf.org" <
> draft-nsdt-teas-transport-slice-definition@ietf.org>
> *Cc: *Reza Rokui <reza.rokui@nokia.com>
> *Subject: *Re: The word "transport"
>
>
>
> Hi all,
>
>
>
> Please see inline for some clarifications.
>
>
>
> Reza
>
>
>
>
>
> On 2020-04-24, 1:31 AM, "Dhruv Dhody" <dhruv.ietf@gmail.com> wrote:
>
>
>
>     Hi Reza,
>
>
>
>     I am putting the relevant text here -
>
>
>
>     ==
>
>
>
>     [14:28:42] <adrianfarrel> I'm getting very confused by everyone
>
>     talking about "transport networks" and "transport slices". Is this
>
>     something coming out of 3GPP?
>
>
>
> [Reza] Please note that the “Transport Slice” from IETF point of view is
> not only limited to 5G network slicing.
>
> 5G network slicing is just one use-case of transport slicing as described
> in Transport Slice definition draft.
>
>
>
> Regarding 5G use-case, the following figure is taken from 3GPP TS 28.530
> where the “Transport slice” is described as “Connectivity” across transport
> network.
>
> This is the reason that what has been described in our draft for
> “Transport Slices” is a set of Connections between various endpoints with
> certain SLOs.
>
> Note that 3GPP did not define the Transport slice explicitly.
>
>
>
>
>
>
>
>
>
>     [14:29:06] <adrianfarrel> Seems to me that we (for example, ACTN) went
>
>     through a lot to clarify that "transport network" was sub-IP
>
>     [14:29:17] <adrianfarrel> ...maybe even sub-MPLS
>
> [Reza] Transport networks (which are technology specific) are used to
> realized “Transport Slices”. Please see draft for more info.
>
>
>
>     [14:31:39] <Joel Halpern> "Transport Network" is the industry
>
>     terminology for the network that connects the radio (and related gear)
>
>     to the packet core (and related gear).
>
>     [14:32:03] <Joel Halpern> It is indeed a different usage.  I wish it
>
>     were not overloading.  But they didn't ask me.
>
>     [14:32:47] <Joel Halpern> Which part it refers to in a fixed access
>
>     network is even less clear.
>
>
>
> [Reza] The following figure is taken from 3GPP TS 28.530 where it shows
> various “Transport slices”.
>
> Note that the “Transport Slices” are not only used for RAN to Core.
> Depends on the deployment, we can have
>
> Transport slices in RAN for midhaul and fronthaul, in 5G Core or for
> application. All these transport slices are shown below.
>
>
>
> ]
>
>
>
>     [14:39:54] <adrianfarrel> I understand why 3GPP uses the term. I don't
>
>     understand why we use the term. We could talk about 'Foobar slices'
>
>     and add one line that says "In the 3GPP, the term 'Transport Slice' is
>
>     used for what we call a 'Foobar Slice'."
>
> [Reza]  Note that 3GPP used the term “slice subnet” when describing it in
> context of 5G Core and RAN (i.e Core Slice Subnet and RAN Slice Subnet).
>
> They did not define anything related to Transport. As indicated above,
> 3GPP refer it to “Connectivity”.
>
> We did not want to use Subnet because in IP,  subnet has a very clear
> definition and using term “Transport Subnet” is completely misleading. So,
> we chose Transport Slice.
>
> Also since the connectivity between various endpoints are across transport
> network (i.e. IP, Optics, PON, Microware etc.), it is logical to assume the
> Connections are called Transport Slice.
>
>
>
>
>
>     [14:40:18] <adrianfarrel> We *already* have two definitions of
>
>     "transport" in the IETF. We really don't need three
>
> [Reza] Please provide links to these two definition.
>
>
>
>     [14:59:00] <adrianfarrel> Well, I picked "foobar' in order to not jump
>
>     immediately to a strawman solution. I think we are talking about
>
>     providing slices as a service across the Internet. Same level of entry
>
>     as a VPN: that is, the consumer provides a packet stream to the
>
>     service entry point, and expects the packets to be delivered to the
>
>     service exit point. Obviously, the consumer of the service may see the
>
>     service as a transport (cf. pseudowires), but we would be 'alarmed' to
>
>     hear a L3VPN described as a 'transport VPN.'
>
> [Reza] VPN is one of the  solutions to realize the transport slices in IP
> networks.
>
> However, The idea of Transport Slice is to allow a high-level system (or
> consumer or an Orchestrator) to ask for a various connections (i.e.
> Transport slices) across  IP, Optics, PON, Microwave or any combination of
> these networks. We shall not limit ourselves to IP VPN.
>
> Note that the definition of the Transport slice is technology agnostic.
> For example in 5G you can realize a transpot slice in midhaul (please refer
> to picture above) which is a set of connections between 5G RAN nodes using
> PON or Optical connection. In this case there is no IP VPN.
>
> In summary, since the connectivity between various endpoints are across
> transport network (i.e. IP, Optics, PON, Microware etc.), it is logical to
> assume the Connections are called Transport Slice.
>
>
>
>     Full logs - https://www..ietf.org/jabber/logs/teas/2020-04-23.html
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fjabber%2Flogs%2Fteas%2F2020-04-23.html&data=02%7C01%7Ckiranm%40futurewei.com%7C5fb387d7a551444584ca08d7ed3d5097%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637238719923636105&sdata=%2FZXF3AwTmx4qHpY3PzQURpylcyZ2CnMYAKMRm9F8%2FEA%3D&reserved=0>
>
>
>
>     ==
>
>
>
>     More inline..
>
>
>
>     On Thu, Apr 23, 2020 at 10:27 PM Rokui, Reza (Nokia - CA/Ottawa)
>
>     <reza.rokui@nokia.com> wrote:
>
>     >
>
>     > Hi Dhruv,
>
>     >
>
>     > As far as I remember, we did not have any argument about term
> "transport". It was agreed that the term "Transport" is suited in context
> of network slicing.
>
>     > The initial discussion was "Transport network slicing" which later
> we agreed to remove "network" since it causes confusion since IETF do not
> cover the e2e network slicing but rather the transport part.
>
>     >
>
>     > I was not clear about Adrian's comment regarding term "transport".
> IMHO, this term is well suited since it convers any underlying technology
> for L0 to L3.
>
>     >
>
>
>
>     In CCAMP/TEAS circles, the transport network term might not be used
>
>     for L3 (and thus the confusion). And then there are the Transport
>
>     Protocols! Definition draft should include some clarity on what do we
>
>     mean when we say transport network at the least!
>
>
>
>     It would be good to get this resolved sooner as we develop multiple
>
>     documents that uses the same terminology!
>
>
>
>     Thanks!
>
>     Dhruv
>
>
>
>     > Reza
>
>     >
>
>     >
>
>     > On 2020-04-23, 12:35 PM, "Dhruv Dhody" <dhruv.ietf@gmail.com> wrote:
>
>     >
>
>     >     Hi,
>
>     >
>
>     >     Adrian gave some comments on jabber about using the word
> "transport".
>
>     >
>
>     >     During RFC8453 devolpment, this came up where TN in ACTN was
> transport
>
>     >     networks and it was changed to TE networks to avoid using the
>
>     >     overloaded term "transport".
>
>     >
>
>     >     We need to find a way to justify using this term and maybe
> describe
>
>     >     this more in the definition draft - and just saying that 3GPP
> uses
>
>     >     that term may not work I guess!
>
>     >
>
>     >     Was this discussed in the design team earlier, i joined the
> effort
>
>     >     much later.
>
>     >
>
>     >     Thanks!
>
>     >     Dhruv
>
>     >
> _______________________________________________
> Teas mailing list
> Teas@ietf.org
> https://www.ietf.org/mailman/listinfo/teas
>
-- 

Gyan  Mishra

Network Engineering & Technology

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347

Email: gyan.s.mishra@verizon.com