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

["Luis M. Contreras" <[e-mail]>]

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) (<
[e-mail]>) 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 <
> [e-mail]>
> *Sent:* Tuesday, May 5, 2020 7:27 PM
> *To:* Kiran Makhijani <[e-mail]>; Belotti, Sergio (Nokia -
> IT/Vimercate) <[e-mail]>; Italo Busi <
> [e-mail]>; [e-mail]
> *Cc:* [e-mail]; Rokui, Reza (Nokia - CA/Ottawa) <
> [e-mail]>
> *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 <[e-mail]> *En nombre de *Kiran Makhijani
> *Enviado el:* martes, 5 de mayo de 2020 17:05
> *Para:* Belotti, Sergio (Nokia - IT/Vimercate) <[e-mail]>;
> Italo Busi <[e-mail]>; [e-mail]
> *CC:* [e-mail]; Rokui, Reza (Nokia - CA/Ottawa) <
> [e-mail]>
> *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) <[e-mail]>
> *Sent:* Tuesday, May 5, 2020 1:31 AM
> *To:* Italo Busi <[e-mail]>; Kiran Makhijani <
> [e-mail]>; [e-mail]
> *Cc:* [e-mail]; Rokui, Reza (Nokia - CA/Ottawa) <
> [e-mail]>
> *Subject:* RE: [Teas] TS and VPN (was RE: FW: The word "transport")
>
>
>
> @Italo Busi <[e-mail]>  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 <[e-mail]> 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 <[e-mail]> *On Behalf Of *Italo Busi
> *Sent:* Tuesday, May 5, 2020 9:11 AM
> *To:* Kiran Makhijani <[e-mail]>; [e-mail]
> *Cc:* [e-mail]; Rokui, Reza (Nokia - CA/Ottawa) <
> [e-mail]>
> *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:[e-mail]
> <[e-mail]>]
> *Sent:* martedì 5 maggio 2020 02:49
> *To:* Italo Busi <[e-mail]>; [e-mail]
> *Cc:* [e-mail]; 'Rokui, Reza (Nokia - CA/Ottawa)' <
> [e-mail]>
> *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 <[e-mail]>
> *Sent:* Monday, May 4, 2020 1:54 PM
> *To:* Kiran Makhijani <[e-mail]>; [e-mail]
> *Cc:* [e-mail]; 'Rokui, Reza (Nokia - CA/Ottawa)' <
> [e-mail]>
> *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:[e-mail]
> <[e-mail]>]
> *Sent:* lunedì 4 maggio 2020 19:18
> *To:* Italo Busi <[e-mail]>; [e-mail]
> *Cc:* [e-mail]; 'Rokui, Reza (Nokia - CA/Ottawa)' <
> [e-mail]>
> *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 <[e-mail]> *On Behalf Of *Italo Busi
> *Sent:* Monday, May 4, 2020 9:36 AM
> *To:* [e-mail]
> *Cc:* [e-mail]; 'Rokui, Reza (Nokia - CA/Ottawa)' <
> [e-mail]>
> *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:[e-mail] <[e-mail]>]
> *Sent:* giovedì 30 aprile 2020 21:32
> *To:* 'Rokui, Reza (Nokia - CA/Ottawa)' <[e-mail]>
> *Cc:* [e-mail]
> *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 <[e-mail]> *On Behalf Of *Rokui,
> Reza (Nokia - CA/Ottawa)
> *Sent:* 30 April 2020 16:23
> *To:* [e-mail]; [e-mail]
> *Cc:* Rokui, Reza (Nokia - CA/Ottawa) <[e-mail]>
> *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 <[e-mail]>
> *Date: *Saturday, April 25, 2020 at 11:37 PM
> *To: *Dhruv Dhody <[e-mail]>, Jari Arkko <[e-mail]>,
> "[e-mail]" <
> [e-mail]>
> *Cc: *Reza Rokui <[e-mail]>
> *Subject: *Re: The word "transport"
>
>
>
> Hi all,
>
>
>
> Please see inline for some clarifications.
>
>
>
> Reza
>
>
>
>
>
> On 2020-04-24, 1:31 AM, "Dhruv Dhody" <[e-mail]> 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)
>
>     <[e-mail]> 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" <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/teas
>


-- 
___________________________________________
Luis M. Contreras
[e-mail]
[e-mail]
Global CTIO unit / Telefonica