Subject: [Pals] Comments regarding draft-schmutzer-bess-ple-01

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 4 Nov 2020 12:23:53 +0000

Hi,
I have a few questions regarding draft-schmutzer-bess-ple-01<https://tools.ietf.org/html/draft-schmutzer-bess-ple-01>.

1.       Section 4.2.1 of the draft says that the FRG bits in the CW "MUST be set to zero by the sender and ignored by the receiver except for frame aligned payloads; see Section 5.2."  However, this is the only mention of frame-aligned payload in the -01 version of the draft, and section 5.2 in this version is called "Byte aligned Payload".  My guess is that frame-aligned payload for ODUk streams have been dropped completely, and that the FRG bits must always be set to zero by the sender and ignored by the receiver - can you please confirm?

2.       Section 5.2 of the draft seems to imply that byte-aligned payload is only applicable to the PLE services emulating ODUk streams. Can you please confirm that this mode is not applicable to, say, OC-192 (SONET framing creates native bye alignment)?

3.       Section 6.2.2 states that "the payload of a lost packet MUST be replaced with equivalent amount of replacement data".  Can you please clarify how wraparound of the 16-bit sequence number (be it in the PW control word or in the RTP header)  affects ability to determine the required amount of replacement data? For the reference, with the default payload size for such streams as OC-192 or ODU2, wraparound of 16-bit sequence number will happen approximately every 20 milliseconds.

Your  feedback would be highly appreciated.

Regards, and lots of thanks in advance,
Sasha

Office: +972-39266302
Cell:      +972-549266302
Email:   [email-masked]

-----------------------------------------------------------------------------------------------------------------------
Notice: This e-mail together with any attachments may contain information of Ribbon Communications Inc. that
is confidential and/or proprietary for the sole use of the intended recipient.  Any review, disclosure, reliance or
distribution by others or forwarding without express permission is strictly prohibited.  If you are not the intended
recipient, please notify the sender immediately and then delete all copies, including any attachments.
-----------------------------------------------------------------------------------------------------------------------

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 4 Nov 2020 12:25:47 +0000

Resenting to  correct Yaakov's address...

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

From: Alexander Vainshtein
Sent: Wednesday, November 4, 2020 2:24 PM
To: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Comments regarding draft-schmutzer-bess-ple-01

Hi,

Office: +972-39266302
Cell:      +972-549266302
Email:   [email-masked]<mailto:[email-masked]>

---

From: Yaakov Stein <[email-masked]>
Date: Wed, 4 Nov 2020 14:25:19 +0000

Sasha,

Thanks for forwarding this to me – I have been out of the plumbing business for a while ☺

However, I took a look at the beginning of this ID and am already confused.

The first line says  encapsulating high-speed bit-streams as VPWS over packet switched networks.

I am not sure what is meant by carrying a service over a PSN.

I believe that encapsulating bit streams as PWs was meant,

but as I said I have been away for a while and perhaps in the meantime someone has found a way of encapsulating service attributes

(I do hope that includes failure recovery, since it was always a pain the neck to have to build mechanisms rather than just doing an encapsulation).

Backtracking, the first line says
This document describes a method for encapsulating high-speed bit-streams
but in the 2nd paragraph the examples given are both Ethernet centric (well, the draft says Ethernet with a small “e”, but I assume that it means Ethernet).

L2 Ethernet is of course not a bit-stream, so I am forced to understand that we are talking about L1 Ethernet,
with the 66b and all the K-codes and such (like in GFP-T).
Really? Do we really need yet another non-byte such monstrosity because of SyncE?

What is meant by control protocol transparency concerns for carrier ethernet (sic) services,

beyond the behavior definitions of MEF specifications?

MEF defines L2CP behavior, but doesn’t touch the L1 stuff. What do you want to do with the K-codes and the FECs anyway?

(BTW, SyncE’s ESMC is a slow L2 protocol, and so only uses the L1 from the CBR PoV).

The next paragraph mentioned fiber channel. If there was one thing we learned about FC in the old PWE work
is that it can’t be transparently transported, and required a rather complex NSP function.

In any case, we already have a FC PW. That same paragraph talks about treating SDH as a bit stream. What I assume is meant is some kind of SAToP for SDH.
I believe that this was discussed to death in the past.
Perhaps the purpose of this draft is to make some universal mechanism that works unchanged for all traffic types (like RFC 6658).
What is the need here? Do you envision a pipe one moment being SDH and then unannounced changing to OTN of similar rate?

In any case, I see from Sasha’s questions that OTN is being handled.
I personally think that an OTN PW is a particularly bad idea, but at least I would understand what an OTN PW proposal was talking about.
In any case, for high rate bit streams that real challenge is the synchronization, and not the encapsulation.

Please forgive my not reading further, as I was simply too confused to continue.

Y(J)S

From: Alexander Vainshtein [mailto:[email-masked]]
Sent: 04/11/2020 14:26
To: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; Yaakov Stein <[email-masked]>
Subject: RE: Comments regarding draft-schmutzer-bess-ple-01

Resenting to  correct Yaakov’s address...

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

From: Alexander Vainshtein
Sent: Wednesday, November 4, 2020 2:24 PM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Comments regarding draft-schmutzer-bess-ple-01

Hi,
I have a few questions regarding draft-schmutzer-bess-ple-01<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-schmutzer-bess-ple-01&data=04%7C01%7Cyaakov_s%40rad.com%7C20ebc69fd16c44983dd908d880bcc95b%7Cf9047108cc2c4e4897a343fad1b3bf9d%7C1%7C0%7C637400895618622076%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=8jtfcZKO76jX7ykqzUDshIYFdGFUd4wkd4izt1Qqne8%3D&reserved=0>.

1.       Section 4.2.1 of the draft says that the FRG bits in the CW “MUST be set to zero by the sender and ignored by the receiver except for frame aligned payloads; see Section 5.2.”  However, this is the only mention of frame-aligned payload in the -01 version of the draft, and section 5.2 in this version is called “Byte aligned Payload”.  My guess is that frame-aligned payload for ODUk streams have been dropped completely, and that the FRG bits must always be set to zero by the sender and ignored by the receiver – can you please confirm?

3.       Section 6.2.2 states that “the payload of a lost packet MUST be replaced with equivalent amount of replacement data”.  Can you please clarify how wraparound of the 16-bit sequence number (be it in the PW control word or in the RTP header)  affects ability to determine the required amount of replacement data? For the reference, with the default payload size for such streams as OC-192 or ODU2, wraparound of 16-bit sequence number will happen approximately every 20 milliseconds.

Office: +972-39266302
Cell:      +972-549266302

________________________________
Notice: This e-mail together with any attachments may contain information of Ribbon Communications Inc. that is confidential and/or proprietary for the sole use of the intended recipient. Any review, disclosure, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please notify the sender immediately and then delete all copies, including any attachments.
________________________________

---

From: "Christian Schmutzer (cschmutz)" <[email-masked]>
Date: Thu, 5 Nov 2020 11:30:33 +0000

Hi Alexander,

Thank you very much again for going through the draft. Please find our responses inline via [cs]

regards
Christian & Luca

On 04.11.2020, at 13:25, Alexander Vainshtein <[email-masked]<mailto:[email-masked]>> wrote:

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Hi,

[cs] good catch, we forgot to change this part when working on the -01 draft where we moved from ODUk frame to byte alignment. We will reword this in the -02 draft to "These bits MUST be set to zero by the sender and ignored by the receiver."

[cs] Yes the byte aligned mode is only applicable for ODUk streams and SONET streams will be carried via the CBR mode.

[cs] So far we did not consider any sequence number wrap around issue as with 1024byte PLE payload size wrap around only happens every ~50msec for 10G signals and we consider a PLOS detection time much shorter than that (proposed default = 1msec)

For even higher speed signals such as 100GE or 400GE and long PLOS detection times configured there could be two options:
1. Local wrap around count as described in https://tools.ietf.org/html/rfc3550#appendix-A.3
2. Concatenation of CW and RTP sequence number into a 32bit number

Do you have any thoughts or opinion?

Office: +972-39266302
Cell:      +972-549266302

---

From: Alexander Vainshtein <[email-masked]>
Date: Sun, 8 Nov 2020 13:25:59 +0000

Christian and Luca,
Lots of thanks for a prompt response.

Please see some responses to your comments inline below.

Please note also that both SONET and Synchronous Ethernet provide information about the quality of their clock that would be carried transparently with the PLE mechanism you have described. There is probably no way to guarantee that these indications would remain relevant after the corresponding bit-stream has been carried across a PSN, and I think that the corresponding caveat in the draft is necessary.

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

From: Christian Schmutzer (cschmutz) <[email-masked]>
Sent: Thursday, November 5, 2020 1:31 PM
To: Alexander Vainshtein <[email-masked]>
Cc: Christian Schmutzer (cschmutz) <[email-masked]>; [email-masked]; Nagendra Kumar Nainar (naikumar) <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; Luca Della Chiesa (ldellach) <[email-masked]>
Subject: Re: Comments regarding draft-schmutzer-bess-ple-01

________________________________
NOTICE: This email was received from an EXTERNAL sender
________________________________

Hi Alexander,

regards
Christian & Luca

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Hi,

[cs] good catch, we forgot to change this part when working on the -01 draft where we moved from ODUk frame to byte alignment. We will reword this in the -02 draft to "These bits MUST be set to zero by the sender and ignored by the receiver." [[Sasha]] OK

[cs] Yes the byte aligned mode is only applicable for ODUk streams and SONET streams will be carried via the CBR mode.[[Sasha]] Got it, thanks

[cs] So far we did not consider any sequence number wrap around issue as with 1024byte PLE payload size wrap around only happens every ~50msec for 10G signals and we consider a PLOS detection time much shorter than that (proposed default = 1msec)[[Sasha]] I would suggest to state explicitly that the PLOS detection time, while configurable, MUST be selected in such a way as to prevent wraparound of sequence numbers.

For even higher speed signals such as 100GE or 400GE and long PLOS detection times configured there could be two options:
1. Local wrap around count as described in https://tools.ietf.org/html/rfc3550#appendix-A.3[[Sasha]] I am not sure this mechanism is feasible to implement
2. Concatenation of CW and RTP sequence number into a 32bit number[[Sasha]]This option also looks quite problematic to me.

Office: +972-39266302
Cell:      +972-549266302