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

From: "Christian Schmutzer (cschmutz)" <[email-masked]>
Date: Wed, 27 Jan 2021 11:16:00 +0000

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 <[email-masked]<mailto:[email-masked]>> 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: +972-39266302
Cell:      +972-549266302
Email:   [email-masked]<mailto:[email-masked]>

From: Christian Schmutzer (cschmutz) <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, November 5, 2020 1:31 PM
To: Alexander Vainshtein <[email-masked]<mailto:[email-masked]>>
Cc: Christian Schmutzer (cschmutz) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Nagendra Kumar Nainar (naikumar) <[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]>; [email-masked]<mailto:[email-masked]>; Luca Della Chiesa (ldellach) <[email-masked]<mailto:[email-masked]>>
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 <[email-masked]<mailto:[email-masked]>> wrote:

Resenting to  correct Yaakov’s address...

Regards,
Sasha

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

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://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: +972-39266302
Cell:      +972-549266302
Email:   [email-masked]<mailto:[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: "Christian Schmutzer (cschmutz)" <[email-masked]>
Date: Wed, 27 Jan 2021 11:16:03 +0000

Hi Yaakov,

You are right the intention of this draft is to define a mechanism that allows for carrying traffic without touching it (aka being bit transparent). Essentially what OTN does by GMP/BMP mapping traffic into ODUs. But also very similar to what SAToP defined for low speed TDM interfaces but across a packet switched network (i.e. MPLS). We now want to bring this “SAToP like” concept to high(er) speed interfaces.

Why?

Optical transmission is quickly evolving from 100Gbps per wavelength to 200Gbps, 400Gbps and Tbps very soon. However the rate of point 2 point service connections (aka circuits) is still predominantly <=10G (10GE, OC192, STM64, FC) or 100G (100GE) so there is a need for a “electrical switching layer” to make efficient use of the DWDM transmission capacity over an arbitrary network topology.

As has already been outlined in the past during the early work of PWE3 (https://tools.ietf.org/html/rfc3916#section-1), using MPLS for this switching layer allows for optimising the infrastructure by consolidating onto a single network instead of maintaining multiple parallel/overlay networks

Having said that you are right that synchronisation is very important and requires careful consideration.

I hope this does provide a bit more context and we are happy to discuss further input/feedback to improve the draft further

Christian

On 04.11.2020, at 15:25, Yaakov Stein <[email-masked]<mailto:[email-masked]>> wrote:

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]<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]>; Yaakov Stein <[email-masked]<mailto:[email-masked]>>
Subject: RE: Comments regarding draft-schmutzer-bess-ple-01

Regards,
Sasha

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

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

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