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

From: János Farkas <[email-masked]>
Date: Mon, 21 Mar 2016 16:16:49 +0100

Hi Jouni,

On 3/20/2016 9:20 AM, Jouni Korhonen wrote:
> Hi Janos,
>
>
>> On 19 Mar 2016, at 16:47, János Farkas<[email-masked]>  wrote:
>>
>>
>> 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?
Sorry, I meant:
"Edge Nodes 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)
> Isn’t flow ID at this layer implicitly same as service ID? Why need to change?
Well, it was just to bring it in sync we called the Layer. It is also 
fine if it remains as is.

>
>> The criteria for the DetNet Transport layer:
>>      #1 Encapsulation and overhead
>>      #2 Flow identification (Transport ID)
> I would not say any “clarification” here.
OK. (It was the same idea as the previous one.)

>
>> 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.
> 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 :)
Well, we discussed it in our calls that it may be more than two copies 
for DetNet. That's what I tried to capture.

>
>> 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.
> 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.
It is not there in IPv6. It is not there in MPLS either. Should we add 
corresponding text to MPLS?

We've been saying that the DetNet Service Layer and the DetNet Transport 
layer together form the DetNet data plane. If a functionality is 
available at the DetNet Service Layer and we are using DetNet Service 
Layer header fields to provide the given functionality, then it is not a 
drawback of a DetNet Transport Layer technology that the 
field/functionality is not available at the DetNet Transport Layer and 
we do not aim to implement it there.

We started it with the sequence number field when discussed IP in the 
early calls, when it was pointed out that sequence number is available 
at higher layers.

The same holds for MPLS. MPLS does not provide sequence number or packet 
elimination. (It is done at PW Layer.)

It is not among the goals to extend IP or MPLS with packet elimination.
This task belongs to the DetNet Service Layer, as e.g. you pointed out.
Therefore, we do not need that text in the draft.

Regards,
Janos