Subject: [Detnet-dp-dt] some comments

From: János Farkas <[email-masked]>
Date: Sun, 13 Mar 2016 17:11:45 +0100

Hi,

Some comments on the first sections:

Section 1
replace "a specific protocol" with "specific protocol(s)"

Section 2

Independent of which approach we choose, clarifications seem to be needed.
Maybe all terminology definitions should go to the architecture draft at 
some point.
End System is already defined in the architecture draft.
I believe, the following would be also useful:
- UNI
- Edge Node
- Core Node / Intermediate Node

I understand that in some cases End System and Edge Node may coincide. 
However, they are different entities in other cases.

Figure 1, then needs to be updated according to the approach chosen by 
the design team.
My current view is that we need to distinguish three layers.

New name to be chosen instead of Det Layer and Net Layer if they are 
found confusing inappropriate by the Design Team.
Note that Layer 4 is "Transport Layer" in the OSI layering, which is 
clearly not the Net Layer.

Definition of the Det Layer:
I still think that "End System" should be replaced by "Edge Node", but 
it ultimately depends on the exact layering approach we choose.

Replace
"For example, some technologies may violate these strict layers and 
still be able to deliver a DetNet service."
with
"For example, some technologies may violate these strict layers and 
still be able or can be developed to be able to deliver a DetNet service."

The criteria for the Det layer:
We need to add "duplicate elimination" to "#3 Packet sequencing"

3.2. #1 Encapsulation and overhead
Replace the first sentence with:
"Encapsulation and overhead is related to how the DetNet Packet Switched 
Network (PSN) carries traffic of DetNet End Systems."
typo: strem -> stream

3.3. #2 Stream identification
I think we should follow Lou's suggestion and replace "stream" with "flow".

3.4. #3 Packet sequencing
Sequence numbering can be used at least for three purpose: detection of 
reordering, loss and duplicates. All three should be reflected in the text.

3.5. #4 Explicit routes
On Lou's question.
In some solutions explicit route is encoded in the data plane. I think 
that's why we are having it here.

3.6. #5 Packet replication and deletion
I agree with Norm, that merging and duplicate deletion are two things.
Duplicate deletion belongs to #3 Packet sequencing.
In general, duplicate deletion may happen at 3 places:
1. End System
2. Edge Node
3. Core Node
It may be worth mentioning these options.

3.6 #5 should be renamed to packet replication and merging or sg alike.

It is in fact not 1+1 but 1+N

3.8. #7 Time synchronization
Text should be updated to reflect the two distinct aspects.
The lower/lowest layer (Net Layer for the moment) provides time/phase 
sync. (e.g. via IEEE 1588)
The layer right on top may use it, e.g., time stamping

I guess, the rest of the doc can be updated / brought in-line if the 
design team agrees on the layering approach to be used.

Regards,
Janos

ps: I have very limited time and email access from now on. I'm chairing 
TSN this week, which means complete blackout for anything else. TSN runs 
from 8:00 till 18:00 or 19:30, and we have sg going on till 21:30 every 
day except for the last one. I also have to finish my 
contributions/presentations for this week, it seems that the 
flight/battery was not long enough. Apologies for delayed / sporadic 
response; this is the reason.

---

From: Lou Berger <[email-masked]>
Date: Sun, 13 Mar 2016 14:56:29 -0400

János,

Lots of good points to respond to -- just picking this one to start

> The layer right on top may use it, e.g., time stamping

If on top you mean detnet client, then I agree and then at most we say
it's outside the scope of DetNet, e.g., by the client running RTP.  If
on top mean the Det layer, then my question is why is this needed and
requirement is it satisfying?

Thanks,
Lou

---

From: "Norman Finn (nfinn)" <[email-masked]>
Date: Mon, 14 Mar 2016 01:05:27 +0000

As mentioned in the architecture draft, there are low-level
queuing/shaping/scheduling mechanisms that are, IMO, below both the “Det”
and “Net” layers, because they are below the forwarding decisions,
operating on all packets leaving a port, whether bridged or routed or
whatevered.  Some of the low-level mechanisms in the process of being
defined in IEEE 802.1, but not yet officially standards, require the relay
system to have its clock synchronized with the other relay systems in the
network with an accuracy typically provided by PTP.  To the extent that
such mechanisms are required to satisfy a particularly rigorous
application making use of DetNet, DetNet requires time sync.

It’s not clear to me whether the above paragraph implies that there are at
least 3 layers of DetNet.  We could well say that neither the time sync
nor the low-level mechanisms are defined by the DetNet WG, although they
are often necessary for DetNet to do its job.  But at the least, the
DetNet WG needs to express its requirements for such externally-provided
services.

— Norm

-----Original Message-----
From: Detnet-dp-dt <[email-masked]> on behalf of Lou Berger
<[email-masked]>
Date: Monday, March 14, 2016 at 02:56 AM
To: János Farkas <[email-masked]>, "[email-masked]"
<[email-masked]>
Subject: [Detnet-dp-dt] Time sync (was Re:  some comments)

>_______________________________________________
>Detnet-dp-dt mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/detnet-dp-dt

---

From: János Farkas <[email-masked]>
Date: Mon, 14 Mar 2016 18:09:15 +0100

Hi,

I tried to draw a more colorful picture for the discussion among us. It 
is not for the draft, as color does not go through.
I hope it helps and it does not increase confusion.

I'm easy on the naming.
We can call the lower, former Net Layer as Layer A, and the on on top, 
the former Det Layer as Layer B.

For simplicity, I'd focus on a single domain Packet Switched Network at 
the first place.

Layer A (used to be called Net) is at the bottom, provides networking it 
includes P routers (Core Nodes).
Layer B (used to be called Det) is the next on top of Layer A. Layer B 
is between PE routers (Edge Nodes).

The PSN provides the DetNet service via the UNIs to the End Systems.

We may consider distinguishing the flows between the End Systems, which 
is the pink Deterministic flow, from its encapsulated version, which is 
the green DetNet flow, which is actually carried by the PSN from PE to 
PE. According to this approach the DetNet flows are from PE to PE within 
the PSN. I believe these DetNet flows are the subject of the PSN data plane.

Regards,
Janos

On 3/13/2016 5:11 PM, János Farkas wrote:
> Maybe all terminology definitions should go to the architecture draft 
> at some point.
> "Encapsulation and overhead is related to how the DetNet Packet 
> Switched Network (PSN) carries traffic of DetNet End Systems."
> typo: strem -> stream
>
> Sequence numbering can be used at least for three purpose: detection 
> of reordering, loss and duplicates. All three should be reflected in 
> the text.
>
> 3.5. #4 Explicit routes
> On Lou's question.
> ps: I have very limited time and email access from now on. I'm 
> chairing TSN this week, which means complete blackout for anything 
> else. TSN runs from 8:00 till 18:00 or 19:30, and we have sg going on 
> till 21:30 every day except for the last one. I also have to finish my

---

From: János Farkas <[email-masked]>
Date: Mon, 14 Mar 2016 18:12:50 +0100

Hi Lou,

> requirement is it satisfying?
I think the Edge Nodes (PE routers) may apply time stamping between 
them, e.g. for SLA verification.
That was the thinking behind that.

Thanks,
Janos

---

From: Lou Berger <[email-masked]>
Date: Mon, 14 Mar 2016 14:56:53 -0400

János

> That was the thinking behind that.
Humm, something to discuss as that might be something better suited to
OAM than every packet...

Lou

---

From: Gregory Mirsky <[email-masked]>
Date: Mon, 14 Mar 2016 19:16:43 +0000

Hi,
if the timestamp in a DetNet packet is only to measure latency and calculate jitter, then I agree with Lou, OAM is more suitable, more generic. I believe that we should formulate DetNet requirements towards OAM and use those while analyzing transport layers, i.e. Net layer.

	Regards,
		Greg

-----Original Message-----
From: Detnet-dp-dt [mailto:[email-masked]] On Behalf Of Lou Berger
Sent: Monday, March 14, 2016 11:57 AM
To: Janos Farkas
Cc: [email-masked]
Subject: Re: [Detnet-dp-dt] Time sync (was Re: some comments)

János

On 3/14/2016 1:12 PM, János Farkas wrote:
>>> The lower/lowest layer (Net Layer for the moment) provides 
>>> time/phase sync. (e.g. via IEEE 1588) The layer right on top may use 
>>> it, e.g., time stamping
>>>
>> If on top you mean detnet client, then I agree and then at most we 
>> say it's outside the scope of DetNet, e.g., by the client running 
>> RTP.  If on top mean the Det layer, then my question is why is this 
>> needed and requirement is it satisfying?
>>
>> Thanks,
>> Lou
>>
Humm, something to discuss as that might be something better suited to OAM than every packet...

Lou

---

From: Lou Berger <[email-masked]>
Date: Mon, 14 Mar 2016 15:22:29 -0400

János,

This looks good to me. 

I'm torn between wanting to steal terminology/text/drawings from
MPLS-(TP|TE) because it's there and abundant vs implying that we're
locking in to a specific solution/approach at this point.

Lou

PS I hope to be able to spend much of tomorrow on detnet.

On 3/14/2016 1:09 PM, János Farkas wrote:
>> This body part will be downloaded on demand.

---

From: Gregory Mirsky <[email-masked]>
Date: Mon, 14 Mar 2016 19:30:34 +0000

Hi Janos,

I think that at IETF there are multiple pairs of terms to describe relationship between the two networking layers. To list some:

·         client – server

·         overlay – underlay

·         service – transport

Det, i.e. overlay, in my view is not limited to edge but will have intermediate, i.e. P, nodes as well.

                Regards,

                                Greg

-----Original Message-----
From: Detnet-dp-dt [mailto:[email-masked]] On Behalf Of János Farkas
Sent: Monday, March 14, 2016 10:09 AM
To: [email-masked]
Subject: Re: [Detnet-dp-dt] some comments

Hi,

I tried to draw a more colorful picture for the discussion among us. It is not for the draft, as color does not go through.

I'm easy on the naming.

We can call the lower, former Net Layer as Layer A, and the on on top, the former Det Layer as Layer B.

For simplicity, I'd focus on a single domain Packet Switched Network at the first place.

Layer A (used to be called Net) is at the bottom, provides networking it includes P routers (Core Nodes).

Layer B (used to be called Det) is the next on top of Layer A. Layer B is between PE routers (Edge Nodes).

We may consider distinguishing the flows between the End Systems, which is the pink Deterministic flow, from its encapsulated version, which is the green DetNet flow, which is actually carried by the PSN from PE to PE. According to this approach the DetNet flows are from PE to PE within the PSN. I believe these DetNet flows are the subject of the PSN data plane.

Regards,

Janos

> Independent of which approach we choose, clarifications seem to be

> needed.

> still be able or can be developed to be able to deliver a DetNet

> service."

> I think we should follow Lou's suggestion and replace "stream" with

> "flow".

> 3.6. #5 Packet replication and deletion I agree with Norm, that

> merging and duplicate deletion are two things.

> sync. (e.g. via IEEE 1588) The layer right on top may use it, e.g.,

> time stamping

---

From: Lou Berger <[email-masked]>
Date: Mon, 14 Mar 2016 15:52:30 -0400

Greg,

On March 14, 2016 3:31:05 PM Gregory Mirsky <[email-masked]> 
wrote:

> Hi Janos,
>
> I think that at IETF there are multiple pairs of terms to describe 
> relationship between the two networking layers. To list some:
>
> ·         client – server
>
> ·         overlay – underlay
>
> ·         service – transport
>

Much like a ms-pw, right?

> I tried to draw a more colorful picture for the discussion among us. It is 
> not for the draft, as color does not go through.
>
> We may consider distinguishing the flows between the End Systems, which is 
> the pink Deterministic flow, from its encapsulated version, which is the 
> green DetNet flow, which is actually carried by the PSN from PE to PE. 
> According to this approach the DetNet flows are from PE to PE within the 
> PSN. I believe these DetNet flows are the subject of the PSN data plane.
>
>
>
> Regards,
>
> Janos
>
>
>
> ----------

---

From: Gregory Mirsky <[email-masked]>
Date: Mon, 14 Mar 2016 19:56:04 +0000

Hi Lou,
yes, multi-segment is very good analogy and the term to use.

                Regards,
                                Greg

From: Lou Berger [mailto:[email-masked]]
Sent: Monday, March 14, 2016 12:53 PM
To: Gregory Mirsky; Janos Farkas; [email-masked]
Subject: Re: [Detnet-dp-dt] some comments

Greg,

> To: [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>

---

From: Jouni Korhonen <[email-masked]>
Date: Mon, 14 Mar 2016 20:50:17 -0700

I tend to agree with Greg and Lou. I do see timestamping capabilities 
essential in DetNet context but that for me is more of deterministic 
flow/end system property - not the interest of intermediate nodes.

- Jouni

---

From: János Farkas <[email-masked]>
Date: Tue, 15 Mar 2016 17:06:08 +0100

I do not  want to replace OAM with time stamping. Let's use OAM for OAM. ;-)

Thanks,
Janos

On 3/15/2016 4:50 AM, Jouni Korhonen wrote:
>> if the timestamp in a DetNet packet is only to measure latency and 
>> calculate jitter, then I agree with Lou, OAM is more suitable, more 
>> generic. I believe that we should formulate DetNet requirements 
>> towards OAM and use those while analyzing transport layers, i.e. Net 
>> layer.
>>
>>     Regards,
>>         Greg
>>