Re: [Teas-ns-dt] Brief meeting notes

[John E Drake <[e-mail]>]

Hi,

And one thing further, the primary purpose of the definitions draft is to define a network slice.  I would assert that our current definition is woefully inadequate:

"A transport slice is a logical network topology connecting a number of endpoints with a set of shared or dedicated network resources, that are used to satisfy specific Service Level Objectives (SLOs)".

And would propose an alternative definition:

"A set of endpoints and a set of one or more dataplane constructs (MP2MP, P2MP, P2P uni-directional, and P2P bi-directional) each of which connects a subset of these endpoints.  For each dataplane construct there is an SLO for each endpoint that can transmit using that dataplane construct.  (This allows us to self-identify the type of a given data plane construct.)"

Yours Irrespectively,

John



Juniper Business Use Only
From: John E Drake
Sent: Thursday, September 24, 2020 3:42 PM
To: Jari Arkko <jari.arkko=[e-mail]>; [e-mail]
Cc: Vishnu Pavan Beeram <vbeeram=[e-mail]>; Lou Berger <[e-mail]>; 'BRUNGARD, DEBORAH A' <[e-mail]>; [e-mail]
Subject: RE: Brief meeting notes

Hi,

I just wanted to comment on some of the statements that were made during the conference call today.  I think it's important that we have a written record rather than trying to respond during the conference call.


  1.  Reza said that we couldn't use the term 'network slice' because 3GPP uses the term 'E2E network slice'.  Obviously, 'network slice' is a different term than 'E2E network slice' so this is nonsense.  Further, the definition of the term 'E2E network slice' would appear to be the concatenation of two or more 'network slices'.
  2.  Kiran said that the network slicing was introducing an entirely new concept to the IETF.  The last time I checked, there were roughly 20-30 drafts or RFCs on the topic of network slicing, all of which pre-date anything the NSDT has published and all of which use the term 'network slicing'
  3.  Kiran said that 'transport network' was a common term in the IETF.  This is incorrect.  'Transport Network' is an ITU term and the only time it is used in the IETF is in support of the ITU's use of MPLS.  This is MPLS-TP (transport profile).
  4.  Kiran said that term 'IETF network slice' is not generic.  Why is it important that the term we use be generic and why is this term not generic?
  5.  Kiran said that the NBI was not a service definition.  I think this is nonsense - otherwise, why do we have 'service level objectives'?

Further, any discussion of isolation should be in terms of the variation of an SLO parameter's value, since this is the only thing a customer can measure as the instantiation of its 'service'.  E.g., absolute isolation would mean that a given SLO parameter's value is invariant.

Yours Irrespectively,

John



Juniper Business Use Only
From: Teas-ns-dt <[e-mail]<mailto:[e-mail]>> On Behalf Of Jari Arkko
Sent: Thursday, September 24, 2020 12:34 PM
To: [e-mail]<mailto:[e-mail]>
Subject: [Teas-ns-dt] Brief meeting notes

[External Email. Be cautious of content]

Situation:
- Documents not adopted as is

Process:
- we need to revise based on feedback and ask again
- wait on framework until definitions agreed
- interim on Oct 19

Main changes:
1/ need to use a different term
- Perhaps more about the name itself than its definition - but also have to worry about the latter. Maybe easier to discuss once the name is not objectionable?
- We all recognize the feedback, and agree not to use transport network slice term
- IETF network slice one contender, some resistance
2/ isolation
- Need acceptable content, not just a placeholder
- Need to understand which approach to use, though (Jari recommended explaining how the term relates to this work, perhaps some breakdown of the term as well)

Next steps:
- For each issue/change, a small team to look at it, provide some options, and analysis of the implications and tradeoffs in those options
- Post early to main TEAS WG list, keep discussion ongoing
- Jari can arrange a weekly call starting next week (again, posted to main list) for those who want to discuss in real-time. But useful only after the above two steps are done first.
- Responsible people: on the name issue, the author team; on isolation Luis, Jie, and Jeff will work on it
- Everyone else to stay active on list + comment and make counter proposals and additional analysis