Subject: [Detnet-dp-dt] Solution draft -01 first sketch available

From: Jouni Korhonen <[email-masked]>
Date: Mon, 17 Apr 2017 15:30:53 -0700

Folks,

I pushed the latest edits to the repository.

- Jouni

-- 
Jouni Korhonen, Broadcom, Core Switching Group
+1-408-391-7160

---

From: Balázs Varga A <[email-masked]>
Date: Tue, 25 Apr 2017 12:07:56 +0000

Hi Jouni, thanks for the edit. I have some comments below. Cheers Bala'zs

1, General comment: on Flow identification for OAM purposes
Many months ago we have discussed some troubleshooting scenario, where
it was necessary on a link to being able to distinguish which DetNet 
packet belongs to which sub-flow of a compound flow. Using a Flow-ID
being part of the PW encapsulation that was easy to fulfill. Now it is
removed and furthermore we expect to use the same PW-label at elimination
points for sub-flows.

Example: 
sub-flow1: A --> D
sub-flow2: B --> D

So on link C-D we can NOT distinguish packets of the two sub-flow.

A--+
       \
        C-----D
       /
B--+

Do we intend to use the "Topology overlay Label" in such scenarios?
Any thoughts? Should we add text regarding this? 

2, Specific comments:
- 16 bits seqnum + editors note: as per my memory we have concluded 
that limited buffer size of nodes obsoletes the issue with high speed 
links? Have I missed something?

- IPv6 flow label (text after figure 6.): 
"IPv6 is the only supported IP transport and the intermediate routers
SHOULD use the IPv6 header Flow Label for the DetNet flow
identification.  The DetNet aware end hosts MUST program the IPv6
header Flow Label with a value that identifies the end to end DetNet
flow (together with the destination address)." 

I think there is a typo, text should speak about src and not dst address. 
A flow can be uniquely identified by the "IPv6 src address + Flow label", 
where the IPv6 src address is the IPv6 address of the DetNet source node 
(in case of DetNet aware end host). Just based on the IPv6 flow label 
intermediate nodes can NOT identify a DetNet flow unless IPv6 flow label
is unique.

- Figure 6 vs. figure 7:
What is the added information here? I see no difference between the figures.

- Section 7.3. Time synchronization:
In case of "PTP packets are sent as a normal DetNet flow" it would be worth 
note that some of the DetNet functions (like specific queuing methods) can not
be applied due to the lack of sync between the nodes.
For the "Time-as-a-service" case I have found somewhat confusing that accurate
time is provided also for the intermediate nodes. I would assume all nodes in 
the DetNet domain are in sync in this scenario and participating in PTP. Have
I missed something?

-----Original Message-----
From: Detnet-dp-dt [mailto:[email-masked]] On Behalf Of Jouni Korhonen
Sent: 2017. április 18. 0:31
To: [email-masked]
Subject: [Detnet-dp-dt] Solution draft -01 first sketch available

Folks,

- Jouni

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

---

From: Balázs Varga A <[email-masked]>
Date: Tue, 25 Apr 2017 12:28:13 +0000

1, General comment: on Flow identification for OAM purposes Many months ago we have discussed some troubleshooting scenario, where it was necessary on a link to being able to distinguish which DetNet packet belongs to which sub-flow of a compound flow. Using a Flow-ID being part of the PW encapsulation that was easy to fulfill. Now it is removed and furthermore we expect to use the same PW-label at elimination points for sub-flows.

Example: 
sub-flow1: A --> D
sub-flow2: B --> D

A--+
       \
        C-----D
       /
B--+

2, Specific comments:
- 16 bits seqnum + editors note: as per my memory we have concluded that limited buffer size of nodes obsoletes the issue with high speed links? Have I missed something?

- IPv6 flow label (text after figure 6.): 
"IPv6 is the only supported IP transport and the intermediate routers SHOULD use the IPv6 header Flow Label for the DetNet flow identification.  The DetNet aware end hosts MUST program the IPv6 header Flow Label with a value that identifies the end to end DetNet flow (together with the destination address)." 

I think there is a typo, text should speak about src and not dst address. 
A flow can be uniquely identified by the "IPv6 src address + Flow label", where the IPv6 src address is the IPv6 address of the DetNet source node (in case of DetNet aware end host). Just based on the IPv6 flow label intermediate nodes can NOT identify a DetNet flow unless IPv6 flow label is unique.

- Figure 6 vs. figure 7:

- Section 7.3. Time synchronization:
In case of "PTP packets are sent as a normal DetNet flow" it would be worth note that some of the DetNet functions (like specific queuing methods) can not be applied due to the lack of sync between the nodes.
For the "Time-as-a-service" case I have found somewhat confusing that accurate time is provided also for the intermediate nodes. I would assume all nodes in the DetNet domain are in sync in this scenario and participating in PTP. Have I missed something?

-----Original Message-----
From: Detnet-dp-dt [mailto:[email-masked]] On Behalf Of Jouni Korhonen
Sent: 2017. április 18. 0:31
To: [email-masked]
Subject: [Detnet-dp-dt] Solution draft -01 first sketch available

Folks,

- Jouni