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 protected]] Sent: 04/11/2020 14:26 To: [email protected]; [email protected]; [email protected]; [email protected]; [email protected] Cc: [email protected]; [email protected]; Yaakov Stein <[email protected]> Subject: RE: Comments regarding draft-schmutzer-bess-ple-01 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://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? 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 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. ________________________________
_______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
