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

[Young Lee <[e-mail]>]

Hi Eric,

RFC 8453 has defined Virtual Network Service (VNS) Model which seems to be
similar or identical to what you are describing as "service abstract" or
"transport service slice".

RFC 8453 has the following defintlition:

TE Network Slicing:  In the context of ACTN, a TE network slice is a
      collection of resources that is used to establish a logically
      dedicated virtual network over one or more TE networks.  TE
      network slicing allows a network operator to provide dedicated
      virtual networks for applications/customers over a common network
      infrastructure.  The logically dedicated resources are a part of
      the larger common network infrastructures that are shared among
      various TE network slice instances, which are the end-to-end
      realization of TE network slicing, consisting of the combination
      of physically or logically dedicated resources.


The above definition of TE network slicing does not necessarily preclude IP
technology as potential transport underlay. I believe IP technology can
realize TE network slicing with some enhancement/support.

Thanks.
Young (waking up after a long hibernation)


2020년 5월 6일 (수) 오전 3:59, Eric Gray <eric.gray=[e-mail]>님이
작성:

> Adrian,
>
>
>
> This is an obvious segue, quite possibly into an equally obvious rat-hole.
>
>
>
> Nobody is (as far as I am aware) arguing that we cannot use existing IETF
> technology to “slice” IP networks using existing technology, for carrying
> arbitrary data (including control and management data) in packetized form.
>
>
>
> Some folks have stated that current technology may not be enough.  That
> remains to be seen.  We need to get a much better understanding of exactly
> what is required in order to make a decision on this, both in the short and
> long term.
>
>
>
> Another group (probably containing a subset of the same people) are
> arguing that we will likely need a high-level model for creating,
> maintaining, monitoring, modifying, and removing a “service” as defined at
> that level.  The intent is that this work would take place at a level of
> abstraction where it is independent of specific technologies that may be
> used within the service, to deliver a requested service at that same level
> of abstraction.
>
>
>
> Actual work to define this model was not an objective (at least initially
> – and I believe – so far) for the design team, although some individual
> work has begun.
>
>
>
> We call this “service abstraction” a “transport slice service.”
>
>
>
> Implicit in this argument is a requirement for a function or component
> that can accept the information in this model and translate it into
> specific control and management instructions required to make the
> underlying network behave in the ways requested for the services to be
> provided.
>
>
>
> We call this function/component a “transport slice controller (TSC).”
>
>
>
> As part of this controller (or control function) an interface is a need to
> define how these abstract service requests are handled.
>
>
>
> We call this interface the TSC’s Northbound Interface (NBI).
>
>
>
> There is no current intent (at least on the part of most of the design
> team) to standardize this entity or it’s interactions with other entities
> in any network application, other than via this NBI.
>
>
>
> Other terminology is included to allow for logical descriptions of the
> required interaction between an arbitrary implementation of a TSC and the
> underlying network (which it is used to control) in providing any arbitrary
> set of transport slice services.
>
>
>
> Example of this include the Southbound Interface (SBI), and the Network
> Controller – which may or may not exist in every instance, especially if
> the TSC itself is not to be standardized, or if specific network
> controllers are not needed in some instances.
>
>
>
> This is really not the sort of rocket surgery that warrants this much
> confusion, uncertainty and doubt.
>
>
>
> --
>
> Eric
>
>
>
> *From:* Adrian Farrel <[e-mail]>
> *Sent:* Friday, May 1, 2020 12:13 PM
> *To:* Eric Gray <[e-mail]>; 'Rokui, Reza (Nokia -
> CA/Ottawa)' <[e-mail]>; 'John E Drake' <jdrake=
> [e-mail]>; [e-mail]
> *Subject:* RE: [Teas] FW: The word "transport"
> *Importance:* High
>
>
>
> Eric,
>
>
>
> I appreciate your attempt here, but I see know reason why we would not
> slice a sub-IP network utilising the technology that we have developed in
> the IETF for control and management of sub-IP networks.
>
>
>
> In fact, maybe we should not try to use this thread to define the purpose
> and scope of the IETF 😊 The creation of CCAMP was an old argument and
> results in the IP-based control of non-packet networks being in scope.
>
>
>
> Best,
>
> Adrian
>
>
>
> *From:* Eric Gray <[e-mail]>
> *Sent:* 01 May 2020 16:46
> *To:* Rokui, Reza (Nokia - CA/Ottawa) <[e-mail]>;
> [e-mail]; 'John E Drake' <jdrake=[e-mail]>;
> [e-mail]; [e-mail]
> *Subject:* RE: [Teas] FW: The word "transport"
>
>
>
> Possibly it would be better to clarify this in terms of what the IETF does
> deal with?
>
>
>
> The IETF deals with “packetized” (more specifically, where packetization
> uses IETF defined packet formats) transport of otherwise arbitrary data.
>
>
>
> Here you can replace transport with “carrying” – but this is essentially
> the standard English meaning of transport.
>
>
>
> *From:* Teas-ns-dt <[e-mail]> *On Behalf Of *Rokui,
> Reza (Nokia - CA/Ottawa)
> *Sent:* Friday, May 1, 2020 11:38 AM
> *To:* [e-mail]; 'John E Drake' <
> jdrake=[e-mail]>; [e-mail]; [e-mail]
> *Cc:* Rokui, Reza (Nokia - CA/Ottawa) <[e-mail]>
> *Subject:* Re: [Teas-ns-dt] [Teas] FW: The word "transport"
>
>
>
> Adrian,
>
>
>
> >>>>>> I don’t understand “we (IETF) do not deal with network slice”.
>
>
>
> Please refer to Figure 4 of the draft.
>
> In summary, an E2E network slice is the logical network from End user X to
> End use Y and comprises of:
>
>    - One or more Transport slices (TS)
>    - One or more Other Slices (OS)
>
>
>
> Just as an example for “Other Slices”, in 5G these slices are RAN slices
> and 5G Core Slices.
>
> Referring  this Figure, it is clear that IETF deals with Transport slice
> which is part of an E2E network slice and “Other slices” are outside scope
> of IETF.
>
> Please make a clear distinction between Transport Slices and e2e network
> slices. They are different.
>
> IMHO, any reference to “Network Slice” in IETF drafts means “Transport
> slice” .
>
>
>
> >>>>>>.  Why do we have a “TEAS Network Slicing Design Team”?
>
> Good question. The correct name can be “TEAS Transport Slicing Design Team”
>
>
>
>
>
> *Reza *
>
>
>
>
>
> *From: *Adrian Farrel <[e-mail]>
> *Organization: *Old Dog Consulting
> *Reply-To: *"[e-mail]" <[e-mail]>
> *Date: *Friday, May 1, 2020 at 10:30 AM
> *To: *Reza Rokui <[e-mail]>, 'John E Drake' <
> jdrake=[e-mail]>, "[e-mail]" <[e-mail]>, "
> [e-mail]" <[e-mail]>
> *Subject: *RE: [Teas] FW: The word "transport"
>
>
>
> Hi Reza,
>
>
>
> I don’t understand “we (IETF) do not deal with network slice”.
>
> Why do we have a “TEAS Network Slicing Design Team”?
>
>
>
> Cheers,
>
> Adrian
>
>
>
> *From:* Rokui, Reza (Nokia - CA/Ottawa) <[e-mail]>
> *Sent:* 01 May 2020 15:13
> *To:* [e-mail]; 'John E Drake' <
> jdrake=[e-mail]>; [e-mail]; [e-mail]
> *Cc:* Rokui, Reza (Nokia - CA/Ottawa) <[e-mail]>
> *Subject:* Re: [Teas] FW: The word "transport"
>
>
>
> John and all,
>
>
>
> This is where I disagree with term “Underlay Network Slice”. It brings
> lots of other questions since we (IETF) do not deal with network slice as
> clearly described in our draft.
>
>
>
> As I send in another email thread, as per Adrian’s suggestion, we define
> the term “Transport” as follows and would like to keep the term “Transport
> Slice”
>
>
>
>    - *Definition of term Transport: This term embraces various
>    technologies such as IP, Optical, Ethernet, TDM, etc  that carry packets
>    and traffic and might span multiple administrative domains.*
>
>
>
> Please provide your suggestion to refine this definition.
>
>
>
> Cheers,
>
> Reza
>
>
>
> *From: *Adrian Farrel <[e-mail]>
> *Organization: *Old Dog Consulting
> *Reply-To: *"[e-mail]" <[e-mail]>
> *Date: *Friday, May 1, 2020 at 5:23 AM
> *To: *'John E Drake' <jdrake=[e-mail]>, Reza Rokui <
> [e-mail]>
> *Cc: *"[e-mail]" <[e-mail]>
> *Subject: *RE: [Teas] FW: The word "transport"
>
>
>
> Yeah, ‘underlay’ seems good because it is a relative term and usefully
> recursive.
>
>
>
> A
>
>
>
> *From:* Teas <[e-mail]> *On Behalf Of *John E Drake
> *Sent:* 30 April 2020 20:59
> *To:* [e-mail]; 'Rokui, Reza (Nokia - CA/Ottawa)' <
> [e-mail]>
> *Cc:* [e-mail]
> *Subject:* Re: [Teas] FW: The word "transport"
>
>
>
> Hi,
>
>
>
> How about ‘underlay network slice’?  It’s describing exactly what we are
> doing and is congruent with the Enhanced VPN draft.
>
>
>
> Yours Irrespectively,
>
>
>
> John
>
>
>
>
>
> Juniper Business Use Only
>
> *From:* Teas <[e-mail]> *On Behalf Of *Adrian Farrel
> *Sent:* Thursday, April 30, 2020 3:32 PM
> *To:* 'Rokui, Reza (Nokia - CA/Ottawa)' <[e-mail]>
> *Cc:* [e-mail]
> *Subject:* [Teas] FW: The word "transport"
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
> 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.
>
>
>
> [image: cid:image001.png@01D61F08.48854020]
>
>
>
>
>
>
>
>     [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.
>
>
>
> ] [image: cid:image003.png@01D61F08.48854020]
>
>
>
>     [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://protect2.fireeye.com/v1/url?k=d4f6bc46-8a560628-d4f6fcdd-86b1886cfa64-dd8e4ff74c5dda87&q=1&e=b15230b3-e6dc-4732-83e3-00354fdc75ae&u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fwww.ietf.org%2Fjabber%2Flogs%2Fteas%2F2020-04-23.html__%3B%21%21NEt6yMaO-gk%21WrvQt2QtERG2EFnE6CPHr8TzNjoFggUjNzUFGwWmlw2KiRSR42MiO2N4YtwhZJI%24>
>
>
>
>     ==
>
>
>
>     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
>
>     >
>
>
>
> Juniper Business Use Only
> _______________________________________________
> Teas mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/teas
>