Subject: [Teas] Network Slicing Design Team definitions

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 23 Apr 2020 20:39:01 -0400

This message contains two relatively minor points I noted while reading 
the draft.  I think they need to be considered, but want to keep them 
separate from the discussion of the Isolation and Resolution text.

Oddity:
     The definition of Endpoint has the oddity that it seems to leave 
the original packet source and the intended packet destination as not 
being Endpoints?  They can not be attached directly to the transport slice?

Minor issues:
     The definition of availability says it is about the time to recover 
from failure.  But then it includes the mean time between failure, which 
while I can understand having an impact on availability is not about the 
time to recover.  The combination of mtbf and mttr give the expect 
portion of the time the service is running / available.

     It is also worth noting that the MEF ended up going to a lot of 
trouble to more precisely define availability due to real-world problems 
with the informal definition.  Maybe we should point to their definition 
instead of trying to craft our own?

Yours,
Joel

---

From: Greg Mirsky <[email-masked]>
Date: Sat, 25 Apr 2020 14:25:57 -0700

Hi Joel,
thank you for starting this discussion. I agree, defining availability in a
packet-switched network is challenging, and, despite several efforts, I
cannot name any good we can use. I may have a proposal that might be the
start for another attempt, but first I'd like to point to the definition of
availability for constant bit-rate paths (e.g., DS, SONET/SDH, etc.). I
apologize for the lengthy post as it will include extensive quotes from
G.826 that are necessary to present the definition.
Firstly, G.826 defines necessary elements that are further used in the
definition: Severely Errored Seconds (SES), Errored Seconds, Defect.
Secondly, an unavailability time is defined as an onset of ten consecutive
SES or Defect periods. Then, the available time is defined as the onset of
ten consecutive non-SES and without a Defect. These definitions can be
applied to unidirectional and bi-directional paths (bi-directional
deemed unavailable if one direction is unavailable). From these
definitions, Availability ratio can be defined as
Availability ratio = (Availability time) / (Up time - Scheduled maintenance
time) * 100.
We can note, that these definitions work for the constant rate network
because a receiver has an expectation of the guaranteed bit-rate, something
that is absent in the PSN case. But if a consumer of a transport slice is
interested in its availability metric, then the controller is expected to
provide necessary instrumentation to enable monitoring on
availability/unavailability. I think that a mechanism that transmits
periodic packets, e.g., BFD in Asynchronous mode, can be used to create the
flow that will be used to measure availability/unavailability time. The
scale might be different from the one used in G.826, and we will need to
define SES considering the difference between PSN and constant bit-rate
technologies.
Do you think that will work?

Regards,
Greg

On Thu, Apr 23, 2020 at 5:39 PM Joel M. Halpern <[email-masked]> wrote:

> _______________________________________________
> Teas mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/teas
>

---

From: Jari Arkko <[email-masked]>
Date: Thu, 30 Apr 2020 17:29:17 +0300

Joel:

> Oddity:
>    The definition of Endpoint has the oddity that it seems to leave the original packet source and the intended packet destination as not being Endpoints?  They can not be attached directly to the transport slice?

I’d like to understand your comment better. What specific text are you referring to? The definition simply said:
 
"A transport slice is a logical network topology connecting a number
   of endpoints and a set of shared or dedicated network resources,
   which are used to satisfy specific Service Level Objectives (SLO)”.

At least in my mind this isn’t necessarily related to packet source and destination addresses; I may want a VPN between your network and mine, but that’s different from the addresses used in the traffic entering the VPN. For instance, my computer’s address is not the endpoint of the VPN, my VPN router is.

But maybe I misunderstood the comment. I agree that the sections that come after the definition and talk about e.g. specific characteristics may have confused something in some cases. E.g., not sure we’ve entirely covered directionality correctly in all the text.

Jari

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 30 Apr 2020 10:58:51 -0400

I am referring to the later text on endpoints.  It defines transport 
endpoints and service endpoints.  But not actual endpoints.  So I found 
it odd.

Yours,
Joel

---

From: John E Drake <[email-masked]>
Date: Thu, 30 Apr 2020 15:06:41 +0000

Hi,

This section is incorrect for at least two reasons.  It is describing the PE rather than the CE as the transport slice endpoint and every PE device will modify a CE packet if only to tag it with an identifier of the transport slice to which it belongs.

Yours Irrespectively,

John

Juniper Business Use Only

> -----Original Message-----
> From: Teas <[email-masked]> On Behalf Of Joel M. Halpern
> Sent: Thursday, April 30, 2020 10:59 AM
> To: Jari Arkko <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [Teas] Network Slicing Design Team definitions
>
> [External Email. Be cautious of content]
>
>
> I am referring to the later text on endpoints.  It defines transport endpoints and
> service endpoints.  But not actual endpoints.  So I found it odd.
>
> Yours,
> Joel
>
> >>     The definition of Endpoint has the oddity that it seems to leave the original
> packet source and the intended packet destination as not being Endpoints?  They
> can not be attached directly to the transport slice?
> >
> > I’d like to understand your comment better. What specific text are you
> referring to? The definition simply said:
> >
> > At least in my mind this isn’t necessarily related to packet source and
> destination addresses; I may want a VPN between your network and mine, but
> that’s different from the addresses used in the traffic entering the VPN. For
> instance, my computer’s address is not the endpoint of the VPN, my VPN router
> is.
> >
> > But maybe I misunderstood the comment. I agree that the sections that come
> after the definition and talk about e.g. specific characteristics may have
> confused something in some cases. E.g., not sure we’ve entirely covered
> directionality correctly in all the text.
> >
> > Jari
> >
>
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas__;!!N
> Et6yMaO-
> gk!RhXTvaULnySMcvW0WVXpcT_CnW3Ualfi21Lg4JXYA2DNe6etPgofj1o4p2otk3
> w$

Juniper Business Use Only

---

From: Joel Halpern Direct <[email-masked]>
Date: Thu, 30 Apr 2020 11:54:38 -0400

If "Service Endpoint" is supposed to include the actual source or sink 
of the packet, then the definition should say that.  It is possible it 
means that, but it is very hard to glean it from the current text.  How 
about:

Service type EP:  This type of endpoint receives and sends user packets.
     It may be the actual source or sink of the packet.  It may also be
     a node which processes and potentially modifies received packets,
     and then sends those packets onward.  This would include ...

Yours,
Joel

On 4/30/2020 11:03 AM, Eric Gray wrote:
> I believe the intention is that “service end-points” correspond to the devices connecting to the transport slice, while “transport end-points” are the devices terminating the service itself.
> 
> Add the understanding the by “devices” IO do not mean to exclude “virtual devices.”
> 
> If my understanding is correct, what could we say to make this clearer?
> 
> —
> Eric
> 
>> On Apr 30, 2020, at 10:58 AM, Joel M. Halpern <[email-masked]> wrote:
>>
>> I am referring to the later text on endpoints.  It defines transport endpoints and service endpoints.  But not actual endpoints.  So I found it odd.
>>
>> Yours,
>> Joel
>>