Hi Yaakov, 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.
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 <yaako...@rad.com<mailto:yaako...@rad.com>> 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:alexander.vainsht...@rbbn.com] Sent: 04/11/2020 14:26 To: cpign...@cisco.comp<mailto:cpign...@cisco.comp>; naiku...@cisco.com<mailto:naiku...@cisco.com>; cschm...@cisco.com<mailto:cschm...@cisco.com>; jeremy.whitta...@verizon.com<mailto:jeremy.whitta...@verizon.com>; steven.gring...@verizon.com<mailto:steven.gring...@verizon.com> Cc: p...@ietf.org<mailto:p...@ietf.org>; bess@ietf.org<mailto:bess@ietf.org>; Yaakov Stein <yaako...@rad.com<mailto:yaako...@rad.com>> Subject: RE: Comments regarding draft-schmutzer-bess-ple-01 Resenting to correct Yaakov’s address... Regards, Sasha Office: +972-39266302 Cell: +972-549266302 Email: alexander.vainsht...@rbbn.com<mailto:alexander.vainsht...@rbbn.com> From: Alexander Vainshtein Sent: Wednesday, November 4, 2020 2:24 PM To: cpign...@cisco.comp<mailto:cpign...@cisco.comp>; naiku...@cisco.com<mailto:naiku...@cisco.com>; cschm...@cisco.com<mailto:cschm...@cisco.com>; jeremy.whitta...@verizon.com<mailto:jeremy.whitta...@verizon.com>; steven.gring...@verizon.com<mailto:steven.gring...@verizon.com> Cc: p...@ietf.org<mailto:p...@ietf.org>; bess@ietf.org<mailto:bess@ietf.org>; yaako...@rad.co<mailto:yaako...@rad.co> 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: alexander.vainsht...@rbbn.com<mailto:alexander.vainsht...@rbbn.com> ________________________________ 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 BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
