Subject: [Detnet-dp-dt] 00 final review and changes by Janos

From: János Farkas <[email-masked]>
Date: Sun, 20 Mar 2016 00:47:14 +0100

Hi,

I've reviewed the draft.
I do not mention straightforward or typo kind of changes here in this 
mail, just did it in the xml.

As we discussed in the first calls, I just updated the section I wrote 
in the first place and explain major changes here, and comments to other 
sections.

An update easy to revert is that I've added an alternative to the "A 
Simple DetNet Enabled Network" figure. The new figure distinguishes Edge 
Nodes from the rest of the Network Nodes  as the two kinds of nodes have 
different tasks. Of course further updates can be done in the new figure.

We should either keep  the old figure or the new one.

If we go for the new figure, then the very first sentence of this 
"DetNet Data Plane Overview" section should be updated to include Edge 
Nodes too, i.e. to
"A "Deterministic Network" will be composed of DetNet enabled "End 
Systems" and DetNet enabled "Edge Nodes" and "Network Nodes".
"Network" then should be removed from the second sentence to get:
"DetNet enabled nodes will provide a DetNet service to attached DetNet 
end systems."

As I wrote earlier, I disagree with this sentence: "End systems 
originate and terminate the Det layer and are peers at the DetNet 
Service layer." If we keep the old figure, then we should just remove 
this sentence.
End Systems are peers, no question about that. But they are not peers at 
the DetNet Service Layer but some layer above. Taking PW over PSN as an 
example, I do not think that End Systems would add PW labels in most of 
the cases.

If we go for the new figure, then "End Systems" should be replaced with 
"Edge Nodes". Thus we get:
"End systems originate and terminate the DetNet Service layer and are 
peers at the DetNet Service layer."

With the DetNet Service Layer and the DetNet Transport Layer, the two 
components of the Flow ID could be:

The criteria for the DetNet Service layer:
     #1 Encapsulation and overhead
     #2 Flow identification (Service ID part of the DetNet flows)

The criteria for the DetNet Transport layer:
     #1 Encapsulation and overhead
     #2 Flow identification (Transport ID)

3.2. #1 Encapsulation and overhead
Not only the DetNet Service layer adds encapsulation/overhead, but the 
DetNet Transport Layer too. The simplest would be to update the first 
sentence to:
"Encapsulation and overhead is related to how the DetNet data plane 
carries DetNet user traffic."

I also brought it up before and we also discussed it on the phone.
Why do we only mention 1+1 protection? It can be 1+N protection too.

"      Another concern regarding packet replication is how to enforce
       replicated packets to take different route while the final 
destination
       still remains the same.
       With strict source routing, all the intermediate hops are listed 
and paths
       can be guaranteed to be non-overlapping. Loose source routing 
only signals
       some of the intermediate hops and it takes additional knowledge 
to ensure
       that there is no single point of failure."
This is generic text, not specific to IPv6. Moved it earlier, under the 
description of #5 Packet replication and deletion.

Deleted
"On the other hand, there is currently no specification
       for the duplicate packet deletion functionality at the 
elimination points.
       The behaviour of keeping a state about received packets exists in 
Neighbor
       Discovery during the address resolution process, but it is 
limited to final
       delivery and prone to DOS attacks."
from the IPv6 section because elimination belongs to the DetNet Service 
layer.

"MPLS can be controlled in a number of ways including via a control
    plane, via the management plane, or via centralized controller (SDN)
    based approaches"
This is valid for any PSN. It could be updated to:
"Such as any PSN, MPLS can be controlled in a number of ways including 
via a control
    plane, via the management plane, or via centralized controller (SDN)
    based approaches"

#5 Packet replication and deletion should be (M/W) for MPLS. The text 
says additional work needed.
I guess the same holds for OAM.

Time synchronization is M/W as the text says "it is possible existing 
mechanisms are not adequate for all use
       cases. "

Regards,
Janos

---

From: Jouni Korhonen <[email-masked]>
Date: Sun, 20 Mar 2016 01:20:33 -0700

Hi Janos,

> On 19 Mar 2016, at 16:47, János Farkas <[email-masked]> wrote:
> 
> Hi,
> 
> I've reviewed the draft.

\o/

> I do not mention straightforward or typo kind of changes here in this mail, just did it in the xml.

Thanks.

> 
> As we discussed in the first calls, I just updated the section I wrote in the first place and explain major changes here, and comments to other sections. 
> 
> An update easy to revert is that I've added an alternative to the "A Simple DetNet Enabled Network" figure. The new figure distinguishes Edge Nodes from the rest of the Network Nodes  as the two kinds of nodes have different tasks. Of course further updates can be done in the new figure.

I just took the new picture and deleted the older. 

> If we go for the new figure, then the very first sentence of this "DetNet Data Plane Overview" section should be updated to include Edge Nodes too, i.e. to
> "A "Deterministic Network" will be composed of DetNet enabled "End Systems" and DetNet enabled "Edge Nodes" and "Network Nodes". 
> "DetNet enabled nodes will provide a DetNet service to attached DetNet end systems.”

OK.

> 
> As I wrote earlier, I disagree with this sentence: "End systems originate and terminate the Det layer and are peers at the DetNet Service layer." If we keep the old figure, then we should just remove this sentence. 
> End Systems are peers, no question about that. But they are not peers at the DetNet Service Layer but some layer above. Taking PW over PSN as an example, I do not think that End Systems would add PW labels in most of the cases.

Agree.

> 
> If we go for the new figure, then "End Systems" should be replaced with "Edge Nodes". Thus we get:
> "End systems originate and terminate the DetNet Service layer and are peers at the DetNet Service layer.”

Hmm.. hat was the change proposed here?

> 
> With the DetNet Service Layer and the DetNet Transport Layer, the two components of the Flow ID could be:
> 

Isn’t flow ID at this layer implicitly same as service ID? Why need to change?

>     #2 Flow identification (Transport ID)

I would not say any “clarification” here.

> Not only the DetNet Service layer adds encapsulation/overhead, but the DetNet Transport Layer too. The simplest would be to update the first sentence to:
> "Encapsulation and overhead is related to how the DetNet data plane carries DetNet user traffic.”

OK.

> Why do we only mention 1+1 protection? It can be 1+N protection too.

CB is 1+1 when doing a stream split? And is there a spec for 1+N protection at the moment (I don’t remember nor did not look up :)

>       replicated packets to take different route while the final destination 
>       still remains the same.
>       With strict source routing, all the intermediate hops are listed and paths
>       can be guaranteed to be non-overlapping. Loose source routing only signals
>       some of the intermediate hops and it takes additional knowledge to ensure
> This is generic text, not specific to IPv6. Moved it earlier, under the description of #5 Packet replication and deletion.

Ok.

>       for the duplicate packet deletion functionality at the elimination points.
>       The behaviour of keeping a state about received packets exists in Neighbor
>       Discovery during the address resolution process, but it is limited to final
> from the IPv6 section because elimination belongs to the DetNet Service layer.

Hmm.. IF duplicate handling is done purely with IPv6 extension headers, we could argue whether that is Service or Network layer.. I still think the old text here was OK. I would bring this back, specifically because this functionally does not exist in IPv6 as of now.

> "Such as any PSN, MPLS can be controlled in a number of ways including via a control
>    based approaches”

Since the context is not PWE3 specific, I would keep the existing text here.

> 
> 
> #5 Packet replication and deletion should be (M/W) for MPLS. The text says additional work needed.

Ok.

> 
> Time synchronization is M/W as the text says "it is possible existing mechanisms are not adequate for all use
>       cases. “

OK.

Thanks for a thorough review!

- Jouni

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