Re: Comments regarding draft-schmutzer-bess-ple-01

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 protected]<mailto:[email protected]>> wrote:

Resenting to  correct Yaakov’s address...

Regards,
Sasha

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

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

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?

[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."


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)?

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


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.

[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?





Your  feedback would be highly appreciated.

Regards, and lots of thanks in advance,
Sasha

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



________________________________
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.
________________________________

_______________________________________________
Pals mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pals