Subject: [Detnet] Promised comments on draft-ietf-detnet-architecture

From: Lou Berger <[email-masked]>
Date: Fri, 1 Jun 2018 16:41:44 -0400

Hi,

     I have a number of high level comments on the document that I'd 
like to raise below.  I also have a number of more editorial/specific 
comments that I'd like to review directly with the authors and then have 
them report back on changes -- if any turn out to be more substantive 
discussions from the author's perspective, I'll raise these on the list 
separately.

My higher level comments are:

- Support for out of order delivery (or miss-ordering) has come up a few 
times and looks like at least some will be allowed in the data plane 
solutions being discussed.  I suggest that the architecture reflect 
this, perhaps by inserting a new subsection before 3.2.4. noting that 
DetNet service should include maximum allowed miss-ordering as a 
constraint, and that some specific (small) value be allowed - of course 
zero miss-ordering would be a valid service constraint.

- While the document discusses how you can have overlapping or nested 
service protection, it does so without reusing the very useful concept 
of "protection domains" that was formalized in RFC6372.  A related, but 
more minor point: I suggest that the document add this term to the 
definitions section and use while describing Service Protection.  I also 
suggest that the "DetNet Service Protection" term be used in place of 
packet replication and elimination when the architectural concept is 
being referenced vs a specific implementation. (I'll provide specific 
examples for both to the authors.)

- WRT Section 4.4.3, I think the inclusion of a distributed control 
plane in the "Network Plane" is inconsistent with other functional 
definitions and conflates where a function resides from the actual 
function and that whether control is implemented in a fully centralized, 
fully distributed or some hybrid form doesn't fundamentally change  the 
control function's role -- therefore I think the sections 4.4.2 and .3 
should be revised accordingly

- In several places it's not clear that DetNet service is always a L3 
service which is controlled using L3 identifiers, i.e., IP addresses -- 
this is true even in the MPLS service case and the TSN over MPLS case.  
I think this is an important point to be clear on in the document.

Please let me know what you think.

Cheers,

Lou

---

From: Balázs Varga A <[email-masked]>
Date: Tue, 12 Jun 2018 08:05:37 +0000

Hi Lou, Thanks for the comments. See reactions inline. Document update in progress. Cheers Bala'zs

-----Original Message-----
From: detnet <[email-masked]> On Behalf Of Lou Berger
Sent: 2018. június 1. 22:42
To: DetNet WG <[email-masked]>; [email-masked]
Subject: [Detnet] Promised comments on draft-ietf-detnet-architecture

Hi,

     I have a number of high level comments on the document that I'd like to raise below.  I also have a number of more editorial/specific comments that I'd like to review directly with the authors and then have them report back on changes -- if any turn out to be more substantive discussions from the author's perspective, I'll raise these on the list separately.

- Support for out of order delivery (or miss-ordering) has come up a few times and looks like at least some will be allowed in the data plane solutions being discussed.  I suggest that the architecture reflect this, perhaps by inserting a new subsection before 3.2.4. noting that DetNet service should include maximum allowed miss-ordering as a constraint, and that some specific (small) value be allowed - of course zero miss-ordering would be a valid service constraint.
[Balázs Varga A] Agree. Update done.

- While the document discusses how you can have overlapping or nested service protection, it does so without reusing the very useful concept of "protection domains" that was formalized in RFC6372.  A related, but more minor point: I suggest that the document add this term to the definitions section and use while describing Service Protection.  I also suggest that the "DetNet Service Protection" term be used in place of packet replication and elimination when the architectural concept is being referenced vs a specific implementation. (I'll provide specific examples for both to the authors.)
[Balázs Varga A] OK. Please provide the examples.

- WRT Section 4.4.3, I think the inclusion of a distributed control plane in the "Network Plane" is inconsistent with other functional definitions and conflates where a function resides from the actual function and that whether control is implemented in a fully centralized, fully distributed or some hybrid form doesn't fundamentally change  the control function's role -- therefore I think the sections 4.4.2 and .3 should be revised accordingly
[Balázs Varga A] Agree in principal. Let's discuss the details.

- In several places it's not clear that DetNet service is always a L3 service which is controlled using L3 identifiers, i.e., IP addresses -- this is true even in the MPLS service case and the TSN over MPLS case. I think this is an important point to be clear on in the document.
[Balázs Varga A] I am not sure. DetNet service is always provided over a L3 network (IP or MPLS), that is fine. However the service itself can be L2 or L3. In case of TSN Ethernet frames are transported, so it is a L2 service. In case of IP end systems IP packets are transported so it is a L3 service.

Cheers,

Lou

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

---

From: Lou Berger <[email-masked]>
Date: Tue, 12 Jun 2018 08:48:38 -0400

Balázs,

Thanks for the response -- please see below.

----------
On June 12, 2018 4:07:35 AM Balázs Varga A <[email-masked]> 
wrote:

>      I have a number of high level comments on the document that I'd like to 
>  raise below.  I also have a number of more editorial/specific comments that 
>  I'd like to review directly with the authors and then have them report back 
>  on changes -- if any turn out to be more substantive discussions from the 
>  author's perspective, I'll raise these on the list separately.
>
...
>
> - WRT Section 4.4.3, I think the inclusion of a distributed control plane 
> in the "Network Plane" is inconsistent with other functional definitions 
> and conflates where a function resides from the actual function and that 
> whether control is implemented in a fully centralized, fully distributed or 
> some hybrid form doesn't fundamentally change  the control function's role 
> -- therefore I think the sections 4.4.2 and .3 should be revised accordingly
Okay - I'll work with you off line and we can report back the 
results/proposed changes.

> this is true even in the MPLS service case and the TSN over MPLS case. I 
> think this is an important point to be clear on in the document.
> [Balázs Varga A] I am not sure. DetNet service is always provided over a L3 
> network (IP or MPLS), that is fine. However the service itself can be L2 or 
> L3. In case of TSN Ethernet frames are transported, so it is a L2 service. 
> In case of IP end systems IP packets are transported so it is a L3 service.
>

Humm - While I agree that DetNet is providing an (enhanced) L2VPN 
service, it is not itself providing control or service of L2 devices -- 
this is TSN's job.  The fact that DetNet is all about behavior of L3 
nodes (i.e., IP and PW/MPLS) and not L2 nodes (i.e., TSN bridges) is 
something the architecture should make unambiguous.

Thanks,
Lou