Re: [Teas] TS and VPN (was RE: FW: The word "transport")

"Luis M. Contreras" <contreras.ietf@gmail.com> Wed, 06 May 2020 11:34 UTC

Return-Path: <contreras.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 3E07A3A0969 for <teas@ietfa.amsl.com>; Wed, 6 May 2020 04:34:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 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, HTTPS_HTTP_MISMATCH=0.1, 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 M8I42d3-3F9S for <teas@ietfa.amsl.com>; Wed, 6 May 2020 04:34:16 -0700 (PDT)
Received: from mail-qk1-x72c.google.com (mail-qk1-x72c.google.com [IPv6:2607:f8b0:4864:20::72c]) (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 7CA283A0937 for <teas@ietf.org>; Wed, 6 May 2020 04:34:16 -0700 (PDT)
Received: by mail-qk1-x72c.google.com with SMTP id f13so1489051qkh.2 for <teas@ietf.org>; Wed, 06 May 2020 04:34:16 -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=RtZ9hU7KlW78ZRKtHD9vIHa6yUb/9WrehrwOtBrsW2k=; b=upU4nqkDOHiZX6eh8TukoOx5DW2cQfFrCM6dn8rdraY8cuOQTjyiczo1yy4kwlIJEv E0zD8SiHbrwgYue14uWKAJ6nUWucHf3l4CoIzCNI9piaJEsnKyePBx+VLOL+ELhdZU5Y mmfXdBt7SC3hkN4uKlnb7lKhmmLJVbTwxWtEm4FFajMLeCa+Vl7wd890GW5WZVs5FnDb 9H6rolp8WdjzHhXpGcBE6w5Ue93ZzkD6tkDaaldm04abTzYcvO5puEM7Le7iEi3o2xUT iOpth1IeI1gQpjS/dLZ8J0Cu48sb5suhY8UgFk9iwCIzwf077XJzl9CyzrdoHflHGHWW sSZw==
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=RtZ9hU7KlW78ZRKtHD9vIHa6yUb/9WrehrwOtBrsW2k=; b=MWH3vBmwQgLMBZprKI9O3n9b5aQ5E4RbJJvvqFdvfZNkbzXglwTH1k0M/piko0CGyS 8kTpXtvO30O4sx/cr3QJF3cF/mxpVIWCfNkBMPQSGmL7LhDENySiE1h/i+66u9muVIFY Wj+D5cyI/M9iB7r3ZHRKRdf3EJjfB6tjjEuE6SeKXe3ZbPyxJUQf11+v+/MdjDDUZZrj 6Y5uto6HRXXQaG4F2GKa8+mwcq6CBcSlvT+QTpovcISn3vi3s1POmsRXRdt97z7vyNFh Ub5Df7zES73FhycSt9psQPB5d3fHDPojt13wa1Xk+xreCeU1Otd/dz9Ro2BooolT9F5g CaGQ==
X-Gm-Message-State: AGi0Puaf54S/ZTQiVhmQQ6aWCU8yACDBAjA9yOMaM9uV8r57TO2MFlMh YjQVNPtx3+rpIv3spEzWw7Y7p3+CvrTTJBjBfds=
X-Google-Smtp-Source: APiQypLeCvC33YGlnC5d8w4d4sK/F5a5CDTbh6LUJX6PrvuuZuefLvhlNKJucQo4uYPVqikSLDuN0ZCXS85p7Pf2oAg=
X-Received: by 2002:a37:670d:: with SMTP id b13mr8633153qkc.206.1588764855410; Wed, 06 May 2020 04:34:15 -0700 (PDT)
MIME-Version: 1.0
References: <178e5a340c924e43a5d762cf2eded95f@huawei.com> <BYAPR13MB24374F3AC030231756895B6AD9A60@BYAPR13MB2437.namprd13.prod.outlook.com> <e2b5b9d06c274d1c8bd5a04ee03b3990@huawei.com> <BYAPR13MB24377B18BDDBF85005502C83D9A70@BYAPR13MB2437.namprd13.prod.outlook.com> <6ab501fff5134afaade389a3a7b1fc35@huawei.com> <AM6PR07MB52229D804A608B82957BFBB691A70@AM6PR07MB5222.eurprd07.prod.outlook.com> <BYAPR13MB2437FC160871F312DDD09B1CD9A70@BYAPR13MB2437.namprd13.prod.outlook.com> <VI1PR0601MB2157B2060D444DF48669913D9EA70@VI1PR0601MB2157.eurprd06.prod.outlook.com> <AM6PR07MB5222AD3C24E0D6CE4CC1C14491A70@AM6PR07MB5222.eurprd07.prod.outlook.com> <CAE4dcxk-Hridc9X8Lpi=2GaFbdytrxmwwkZesun2gpc+G3Xn1g@mail.gmail.com> <1a4d326c606e4538a0e340ffb90b4e67@huawei.com>
In-Reply-To: <1a4d326c606e4538a0e340ffb90b4e67@huawei.com>
From: "Luis M. Contreras" <contreras.ietf@gmail.com>
Date: Wed, 6 May 2020 13:34:03 +0200
Message-ID: <CAE4dcxmtmDjgTo0NMc3a-r8NxWPRmGt1nAwrUZ-rWtjGejEhew@mail.gmail.com>
To: Italo Busi <Italo.Busi@huawei.com>
Cc: "Belotti, Sergio (Nokia - IT/Vimercate)" <sergio.belotti@nokia.com>, LUIS MIGUEL CONTRERAS MURILLO <luismiguel.contrerasmurillo@telefonica.com>, Kiran Makhijani <kiranm@futurewei.com>, "teas@ietf.org" <teas@ietf.org>, "adrian@olddog.co.uk" <adrian@olddog.co.uk>, "Rokui, Reza (Nokia - CA/Ottawa)" <reza.rokui@nokia.com>
Content-Type: multipart/related; boundary="000000000000d748b805a4f92482"
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/RiD7xeD1vf4lgIGhvNlg6-Ice9U>
Subject: Re: [Teas] TS and VPN (was RE: 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: Wed, 06 May 2020 11:34:23 -0000

Hi Italo,

understood your point.

Thanks

Luis



El mar., 5 may. 2020 a las 23:38, Italo Busi (<Italo.Busi@huawei.com>)
escribió:

> Luis,
>
>
>
> I think that the TS SBI should use the L2NM or L3NM to request the network
> controllers to setup the L2VPN and L3VPN realizing the TS
>
>
>
> Italo
>
>
>
> *From:* Luis M. Contreras [mailto:contreras.ietf@gmail.com]
> *Sent:* martedì 5 maggio 2020 20:03
> *To:* Belotti, Sergio (Nokia - IT/Vimercate) <sergio.belotti@nokia.com>
> *Cc:* LUIS MIGUEL CONTRERAS MURILLO <
> luismiguel.contrerasmurillo@telefonica.com>gt;; Kiran Makhijani <
> kiranm@futurewei.com>gt;; Italo Busi <Italo.Busi@huawei.com>om>; teas@ietf.org;
> adrian@olddog.co.uk; Rokui, Reza (Nokia - CA/Ottawa) <reza.rokui@nokia.com
> >
> *Subject:* Re: [Teas] TS and VPN (was RE: FW: The word "transport")
>
>
>
> Ok, understood.
>
>
>
> By the way, according to the figure (left hand side) TSC would instruct
> some network controllers, so L3/L2 service models could be expected at that
> level, right?
>
>
>
> This is something to clarify to properly defining the SBI as you commented.
>
>
>
> Thanks
>
>
>
> Luis
>
>
>
>
>
> El mar., 5 may. 2020 a las 19:45, Belotti, Sergio (Nokia - IT/Vimercate) (<
> sergio.belotti@nokia.com>) escribió:
>
> Hi Luis,
>
> yes correct but I think here it’s like the chicken and the egg: based on
> what was written about the usage of LxSM at SBI, obviously, Dhruv made,
> correctly,  the mapping of ACTN starting from CMI at the level of SBI in
> slicing context.
>
>
>
> Thanks
>
> Sergio
>
>
>
> *From:* LUIS MIGUEL CONTRERAS MURILLO <
> luismiguel.contrerasmurillo@telefonica.com>
> *Sent:* Tuesday, May 5, 2020 7:27 PM
> *To:* Kiran Makhijani <kiranm@futurewei.com>om>; Belotti, Sergio (Nokia -
> IT/Vimercate) <sergio.belotti@nokia.com>om>; Italo Busi <
> Italo.Busi@huawei.com>gt;; teas@ietf.org
> *Cc:* adrian@olddog.co.uk; Rokui, Reza (Nokia - CA/Ottawa) <
> reza.rokui@nokia.com>
> *Subject:* RE: [Teas] TS and VPN (was RE: FW: The word "transport")
>
>
>
> HI all,
>
>
>
> According to the mapping in the framework document between TSC and ACTN
> (section 4 of draft-nsdt-teas-ns-framework-02) the TSC SBI could be mapped
> to the CMI in ACTN architecture. Thus customer service models such as L3SM
> would fit in the SBI of TSC.
>
>
>
> If that is not the case, then the mapping is not correct or at least
> inconsistent.
>
>
>
> Best regards
>
>
>
> Luis
>
>
>
> *De:* Teas <teas-bounces@ietf.org> *En nombre de *Kiran Makhijani
> *Enviado el:* martes, 5 de mayo de 2020 17:05
> *Para:* Belotti, Sergio (Nokia - IT/Vimercate) <sergio.belotti@nokia.com>om>;
> Italo Busi <Italo.Busi@huawei.com>om>; teas@ietf.org
> *CC:* adrian@olddog.co.uk; Rokui, Reza (Nokia - CA/Ottawa) <
> reza.rokui@nokia.com>
> *Asunto:* Re: [Teas] TS and VPN (was RE: FW: The word "transport")
>
>
>
> Hi Italo, Sergio,
>
> Your explanation helped. If “customer service models” should not be at SBI
> is a sufficient explanation then it makes sense to maintain that
> separation.
>
> Are there any other side-effects of this on NBI or framework? Lets check
> in nsdt, if no one disagrees, we can exclude LxSMs with 8309 reference.
>
> Thanks
>
> Kiran
>
>
>
> *From:* Belotti, Sergio (Nokia - IT/Vimercate) <sergio.belotti@nokia.com>
> *Sent:* Tuesday, May 5, 2020 1:31 AM
> *To:* Italo Busi <Italo.Busi@huawei.com>om>; Kiran Makhijani <
> kiranm@futurewei.com>gt;; teas@ietf.org
> *Cc:* adrian@olddog.co.uk; Rokui, Reza (Nokia - CA/Ottawa) <
> reza.rokui@nokia.com>
> *Subject:* RE: [Teas] TS and VPN (was RE: FW: The word "transport")
>
>
>
> @Italo Busi <Italo.Busi@huawei.com>  Hi Italo , many thanks to point out
> this text from RFC 8309. More in session 7.1 , RFC 8309 try again to
> clarify the agnostic characteristic of a customer service model as LxSM vs.
> what could technology specific (e.g. encapsulation) from customer
> prospective.
>
>
>
> @Kiran Makhijani <kiranm@futurewei.com> Hi Kiran, I think your
> explanation does not provide the clarity required : “the SBI will use which
> ever technology specific data model is provided by the operator (L3VPN or
> L3SM)”
>
>
>
> L3VPN or L3SM are not the same thing so the “or” is creating confusion.
>
> I think we need to clarify better what is required at NBI of TSC and what
> at SBI, taking into account in my view  that models being considered as
> “customer service model” like e.g. LxSM should not be at SBI .
>
> Moreover, clarifying the context of SBI and NBI interfaces would also help
> to describe more specifically the real functionality of TSC.
>
>
>
> Thanks
>
> Sergio
>
>
>
>
>
>
>
> *From:* Teas <teas-bounces@ietf.org> *On Behalf Of *Italo Busi
> *Sent:* Tuesday, May 5, 2020 9:11 AM
> *To:* Kiran Makhijani <kiranm@futurewei.com>om>; teas@ietf.org
> *Cc:* adrian@olddog.co.uk; Rokui, Reza (Nokia - CA/Ottawa) <
> reza.rokui@nokia.com>
> *Subject:* Re: [Teas] TS and VPN (was RE: FW: The word "transport")
>
>
>
> I am sorry but I am still very confused
>
>
>
> Please consider the following text from RFC8309:
>
>
>
>                                                     Except where
>
>          specific technology details are directly pertinent to the
>
>          customer (such as encapsulations or mechanisms applied on
>
>          access links), customer service models are technology agnostic
>
>          so that the customer does not have influence over or knowledge
>
>          of how the network operator engineers the service.
>
>
>
> Why this is not applicable to TS as well?
>
>
>
> Italo
>
>
>
> *From:* Kiran Makhijani [mailto:kiranm@futurewei.com
> <kiranm@futurewei.com>]
> *Sent:* martedì 5 maggio 2020 02:49
> *To:* Italo Busi <Italo.Busi@huawei.com>om>; teas@ietf.org
> *Cc:* adrian@olddog.co.uk; 'Rokui, Reza (Nokia - CA/Ottawa)' <
> reza.rokui@nokia.com>
> *Subject:* RE: [Teas] TS and VPN (was RE: FW: The word "transport")
>
>
>
> Hi Italo,
>
> Please note that the definitions document  wants to develop an independent
> concept of transport slices. It says nothing about either of the 2 – that
> transport slice is a service or is a technology.
>
>
>
> However, how is it possible to define a service without specifying the
> type the traffic (e.g., Ethernet or IP) that is exchanged at the UNI and
> over the VPN?
>
> ^^^^
>
> Short answer is - this will happen through mappings when actual
> realization of TS happens, the SBI will use which ever technology specific
> data model is provided by the operator (L3VPN or L3SM).  This will become
> clearer in NBI data model.
>
>
>
> -Kiran
>
>
>
> *From:* Italo Busi <Italo.Busi@huawei.com>
> *Sent:* Monday, May 4, 2020 1:54 PM
> *To:* Kiran Makhijani <kiranm@futurewei.com>om>; teas@ietf.org
> *Cc:* adrian@olddog.co.uk; 'Rokui, Reza (Nokia - CA/Ottawa)' <
> reza.rokui@nokia.com>
> *Subject:* RE: [Teas] TS and VPN (was RE: FW: The word "transport")
>
>
>
> Hi Kiran,
>
>
>
> Thanks for your explanation
>
>
>
> I am still confused by the service versus underlay versus technology
> specific
>
>
>
> A service defined from the viewpoint of the customer is usually not
> underlay specific since it is possible to implement the same service using
> different underlay technologies
>
>
>
> However, how is it possible to define a service without specifying the
> type the traffic (e.g., Ethernet or IP) that is exchanged at the UNI and
> over the VPN?
>
>
>
> Italo
>
>
>
> *From:* Kiran Makhijani [mailto:kiranm@futurewei.com
> <kiranm@futurewei.com>]
> *Sent:* lunedì 4 maggio 2020 19:18
> *To:* Italo Busi <Italo.Busi@huawei.com>om>; teas@ietf.org
> *Cc:* adrian@olddog.co.uk; 'Rokui, Reza (Nokia - CA/Ottawa)' <
> reza.rokui@nokia.com>
> *Subject:* RE: [Teas] TS and VPN (was RE: FW: The word "transport")
>
>
>
> Hi Italo,
>
> My understanding is that the former use of the term VPN is meant as “VPN as a service” while the latter is meant as “the technologies used to realize a VPN”
>
> ^^^^
>
> That’s right. In the beginning, we consider ‘VPN+ some resource
> guarantees’ as a use case. In section 1 we aren’t concerned how that VPN
> will be realized (L2 or L3 way). In section 5, we are actually saying that
> well-known models for L2VPN, L3VPN (whether service or underlay specific)
> are means to realize transport slice. By associating L2- or L3- usage
> becomes technology-specific. In section 5, we don’t use VPN generically.
>
> -Kiran
>
>
>
>
>
> *From:* Teas <teas-bounces@ietf.org> *On Behalf Of *Italo Busi
> *Sent:* Monday, May 4, 2020 9:36 AM
> *To:* teas@ietf.org
> *Cc:* adrian@olddog.co.uk; 'Rokui, Reza (Nokia - CA/Ottawa)' <
> reza.rokui@nokia.com>
> *Subject:* [Teas] TS and VPN (was RE: FW: The word "transport")
>
>
>
> I think that Adrian has spotted another area of confusion in the current
> work:
>
>
>
> Actually, I think you would do well to distinguish between VPN as a
> service and the technologies used to realise a VPN.
>
>
>
> I agree with Adrian’s point and I think the documents needs more clarity
> about this distinction
>
>
>
> For example, section 1 of draft-nsdt-teas-transport-slice-definition-02 mentions “VPNs with specific characteristics” as an example of a service which could benefit from TS, while in section 5 VPN is mentioned as a technology-specific realization of a TS …
>
>
>
> My understanding is that the former use of the term VPN is meant as “VPN as a service” while the latter is meant as “the technologies used to realise a VPN”
>
>
>
> If my understanding is correct, it is not clear why at the TS NBI the L2SM/L3SM YANG models, which are defined to request a “VPN as a service”, are considered instead of the L2NM/L3NM YANG models, which are defined to configure “the technologies used to realise a VPN” …
>
>
>
> Could you please clarify?
>
>
>
> Thanks, Italo
>
>
>
> *From:* Adrian Farrel [mailto:adrian@olddog.co.uk <adrian@olddog.co.uk>]
> *Sent:* giovedì 30 aprile 2020 21:32
> *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%7Cfb3ff222be214d1be9b808d7f0ceb7bb%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637242642968275741&sdata=7xnTpsT1IY833RRzHnovscncirjXW6E3UG51lH%2F2C9o%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
>
>     >
>
>
> ------------------------------
>
>
> Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario,
> puede contener información privilegiada o confidencial y es para uso
> exclusivo de la persona o entidad de destino. Si no es usted. el
> destinatario indicado, queda notificado de que la lectura, utilización,
> divulgación y/o copia sin autorización puede estar prohibida en virtud de
> la legislación vigente. Si ha recibido este mensaje por error, le rogamos
> que nos lo comunique inmediatamente por esta misma vía y proceda a su
> destrucción.
>
> The information contained in this transmission is privileged and
> confidential information intended only for the use of the individual or
> entity named above. If the reader of this message is not the intended
> recipient, you are hereby notified that any dissemination, distribution or
> copying of this communication is strictly prohibited. If you have received
> this transmission in error, do not read it. Please immediately reply to the
> sender that you have received this communication in error and then delete
> it.
>
> Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário,
> pode conter informação privilegiada ou confidencial e é para uso exclusivo
> da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário
> indicado, fica notificado de que a leitura, utilização, divulgação e/ou
> cópia sem autorização pode estar proibida em virtude da legislação vigente.
> Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique
> imediatamente por esta mesma via e proceda a sua destruição
>
> _______________________________________________
> Teas mailing list
> Teas@ietf.org
> https://www.ietf.org/mailman/listinfo/teas
>
>
>
>
> --
>
> ___________________________________________
>
> Luis M. Contreras
>
> contreras.ietf@gmail.com
>
> luismiguel.contrerasmurillo@telefonica.com
>
> Global CTIO unit / Telefonica
>


-- 
___________________________________________
Luis M. Contreras
contreras.ietf@gmail.com
luismiguel.contrerasmurillo@telefonica.com
Global CTIO unit / Telefonica