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

["Christian Schmutzer (cschmutz)" <[e-mail]>]

Hi Alexander,

Apology upfront for not coming back to you earlier. Back in November we considered organising a adhoc live discussion where people interested could join and discuss recent input. This didn’t happen and then we forgot to get back via email.

See responses from Luca and me inline via [cs/ldc]

Regards
Christian

On 08.11.2020, at 14:25, Alexander Vainshtein <[e-mail]<mailto:[e-mail]>> wrote:

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.

[cs/ldc] I think this the same concern you raised during your review of the -00 version? https://mailarchive.ietf.org/arch/msg/pals/vEL1-Azc76YoHlgExO0CwHuyZ5o/.

Based on your input we actually added information related to clock recovery performance targets in section https://tools.ietf.org/html/draft-schmutzer-bess-ple-01#section-6.2.2 of our draft that an implementation has to comply with. This is similar to how other technologies such as OTN are covering the aspect of client clock recovery across a server layer transport network.


Regards,
Sasha

Office: [phone]
Cell:      [phone]
Email:   [e-mail]<mailto:[e-mail]>

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

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

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 <[e-mail]<mailto:[e-mail]>> wrote:

Resenting to  correct Yaakov’s address...

Regards,
Sasha

Office: [phone]
Cell:      [phone]
Email:   [e-mail]<mailto:[e-mail]>

From: Alexander Vainshtein
Sent: Wednesday, November 4, 2020 2:24 PM
To: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
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." [[Sasha]] OK


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.[[Sasha]] Got it, thanks


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

[cs/ldc] could you please provide more insights on why you think #2 is problematic? For an implementation it doesn’t really matter where the bits are stored in the packet header. Also we would be interested in why you think it is not feasible to implement a wrap around counter as proposed in #1?


Do you have any thoughts or opinion?




Your  feedback would be highly appreciated.

Regards, and lots of thanks in advance,
Sasha

Office: [phone]
Cell:      [phone]
Email:   [e-mail]<mailto:[e-mail]>


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