Subject: Re: [Detnet-dp-dt] draft in github

From: János Farkas <[email-masked]>
Date: Tue, 1 Mar 2016 14:48:39 +0100

Hi,

I've added some text on PW over IP PSN: the last paragraph in 3.5.1 and 
the last paragraph of the Encapsulation and overhead section in 3.5.2.

In order to address Greg's comment GM5, I've updated the sentence by 
adding a reference to RFC7426. I hope it makes clear the sentence, which 
is my fault at the first place.

I have updated the latest version available in github.

Regards,
Janos

On 2/29/2016 7:35 PM, Jouni Korhonen wrote:
> Folks,
>
> There was some hiccups in one of the recent commits (3432dff). I have 
> played back a bunch of lost changes to the current one (5c6cb85). 
> Hopefully this fixes most issues.
>
> @Pascal, could you check the latest commit has your edits? I have my 
> doubts they got lost now :(
>
> - Jouni
>
> _______________________________________________
> Detnet-dp-dt mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/detnet-dp-dt

---

From: János Farkas <[email-masked]>
Date: Tue, 1 Mar 2016 15:43:41 +0100

Hi,

Some comments on 3.5.  PseudoWires:

Stream identification
I'd delete "especially in the case of the MPLS PSN" because the first 
part of the sentence "PWs provide multiple layers of stream 
identification" is valid for IP PSN as well, PW label exists for PW over 
IP too.

Packet sequencing
Maybe we should mention that the optional CW could be made mandatory for 
DetNet.
I'd replace "link" with "connection".

Explicit routes
Maybe we can just refer back to 3.1.2 for IPv6 instead of the last sentence.

Packet replication and deletion
I'd update it to:
"     The 1+1 PW  protection / redundancy mechanisms [RFC6718] could
       provide tools for packet replication.  However, these solutions
       are not really intended for sourcing multiple simultaneous
       replication of packets belonging to the same stream. The solutions
       have one active and other standby stream. 1+N protection would be
       needed for DetNet. The PW duplicate detection mechanism also exists
       in theory {RFC3985] but no emulated service makes use of it
       currently. MS-PW technology [RFC5659] could also provide some
       tools for merging replicated streams. Intermediate nodes, where
       streams are merged, have to examine the CW of the PWs in order
       to be able to eliminate duplicates. This feature is available
       in S-PE nodes.  For IP PSN refer to the discussion in Section 3.1.2
       and Section 3.2.2."

I'd delete "LSP" from the first sentence because LSP protection is not 
covered by RFC6718 and it is somewhat more problematic; it is about PW 
here anyways.
We mentioned 1+N protection on the call, we should mention it in the 
draft too.
We should refer to RFC5659.

Regards,
Janos

On 3/1/2016 2:48 PM, János Farkas wrote:
> Hi,
>
> I've added some text on PW over IP PSN: the last paragraph in 3.5.1 
> and the last paragraph of the Encapsulation and overhead section in 
> 3.5.2.
>
> adding a reference to RFC7426. I hope it makes clear the sentence, 
> which is my fault at the first place.
>

---

From: Jouni Korhonen <[email-masked]>
Date: Tue, 1 Mar 2016 12:11:55 -0800

Thanks Janos,

3/1/2016, 6:43 AM, János Farkas kirjoitti:
> identification" is valid for IP PSN as well, PW label exists for PW 
> over IP too.
Fine with that.
>
> Packet sequencing
> Maybe we should mention that the optional CW could be made mandatory 
> for DetNet.
Both OK. Except that the "mandatory" recommendation would just be a 
gentle hint in this document.
> Maybe we can just refer back to 3.1.2 for IPv6 instead of the last 
Ok.
>       in S-PE nodes.  For IP PSN refer to the discussion in Section 3.1.2
I like the update. Will modify.
> We should refer to RFC5659.
I was thinking of RFC5659 but apparently forgot about it.. that was 
referenced in last IETF PWE slideset we had though.

- Jouni
>>> There was some hiccups in one of the recent commits (3432dff). I 
>>> have played back a bunch of lost changes to the current one 
>>> (5c6cb85). Hopefully this fixes most issues.
>>>