Christian, From my POV explicitly stating that that the replacement data of 0xAA is the default as well as explaining (as you have done in your email) the impact of this replacement data on Ethernet and Fiber Channel CEs would be most useful.
Regards, Sasha From: Christian Schmutzer (cschmutz) <cschm...@cisco.com> Sent: Sunday, October 20, 2024 9:26 PM To: Alexander Vainshtein <alexander.vainsht...@rbbn.com>; Joel Halpern <jmh.dir...@joelhalpern.com> Cc: Christian Schmutzer (cschmutz) <cschm...@cisco.com>; gen-art@ietf.org; draft-ietf-pals-ple....@ietf.org; last-c...@ietf.org; p...@ietf.org Subject: Re: [EXTERNAL] [Pals] Re: Genart last call review of draft-ietf-pals-ple-08 Hi Alexander / Joel, if you think it is helpful I can change the text to explicitly state that the replacement data of 0xAA MUST be not only supported but also be the default of an implementation. Wrt the reaction of ethernet / fibre channel CEs: Taking 10GE as an example which is using 64B/66B encoding, the first 2 bits of each 66 bit long code block are called the “sync header”. Valid values are 10 and 01, which nicely aligns with 0xAA which is an alternating sequence of 1 and 0. The CE does use those sync headers to acquire and maintain what is called “PCS sync/lock”. For more details you can have a look at IEEE802.3 section 49, figure 49-14 respectively. So if we loose one or more PLE packets the insertion of the replacement data won’t impact PCS sync of the 10GE CE, because however the 66B code blocks were aligned with the PLE payload boundaries, the sync headers will always be either 10 or 01. Hence the replacement will only lead to corrupted data or invalid control blocks. The former leads to CRC errors at higher layers in the ethernet stack. The later is dealt with gracefully via the invalid code block replacement to be done by a PLE implementation in the CE-bound NSP as defined in https://datatracker.ietf.org/doc/html/draft-ietf-pals-ple-09#name-10gbase-r-and-25gbase-r<https://datatracker.ietf.org/doc/html/draft-ietf-pals-ple-09#name-10gbase-r-and-25gbase-r>. I gave the 10GE example, but similar things apply for other interface speeds and for fibre channel. Hope this helps Christian On 20.10.2024, at 15:32, Alexander Vainshtein <alexander.vainsht...@rbbn.com<mailto:alexander.vainsht...@rbbn.com>> wrote: Joel, Lots of thanks for a prompt response. I see that Section 7.2.2 says that the replacement data MAY be configurable. It also says: All PLE implementations MUST support generation of "0xAA" as replacement data. The alternating sequence of 0s and 1s of the "0xAA" pattern does ensure clock synchronization is maintained. I have some questions about the quoted text: 1. This text seems to suggest that the appropriate number of 0xAA bytes is the default for the replacement data, but this is not stated explicitly 2. This text differs from the matching text in Section 6.2.2 of RFC 4553 that says: The payload of each lost SAToP packet MUST be replaced with the equivalent amount of the replacement data. The contents of the replacement data are implementation-specific and MAY be locally configurable. By default, all SAToP implementations MUST support generation of the "all ones" pattern as the replacement data. Before a PW has been set up and after a PW has been torn down, the IWF MUST play out the "all ones" pattern to its TDM attachment circuit. 3. The default behavior defined in the quoted text of RFC 4553 is aligned with behavior of the corresponding TDM CEs that recognize a sufficient number of “all ones” as the Alarm Indication Signal (AIS) condition (the “sufficient number” here varies for different TDM streams) and pass this indication to the upper layer applications. But I do not know how Ethernet and/or Fiber Channel CEs would react to a sufficiently long pattern of alternating ones and zeroes and what would be passed to the upper layer applications – may be my personal problem. Regards, Sasha From: Joel Halpern <jmh.dir...@joelhalpern.com<mailto:jmh.dir...@joelhalpern.com>> Sent: Sunday, October 20, 2024 3:32 PM To: Alexander Vainshtein <alexander.vainsht...@rbbn.com<mailto:alexander.vainsht...@rbbn.com>>; Christian Schmutzer (cschmutz) <cschm...@cisco.com<mailto:cschm...@cisco.com>> Cc: gen-art@ietf.org<mailto:gen-art@ietf.org>; draft-ietf-pals-ple....@ietf.org<mailto:draft-ietf-pals-ple....@ietf.org>; last-c...@ietf.org<mailto:last-c...@ietf.org>; p...@ietf.org<mailto:p...@ietf.org> Subject: Re: [EXTERNAL] [Pals] Re: Genart last call review of draft-ietf-pals-ple-08 Sasha, I am no expert on this work, but section 7.2.2 of the draft seems to deal with the filling issues quite clearly. Yours, Joel On 10/20/2024 4:04 AM, Alexander Vainshtein wrote: Joel, Christian and all, Regarding the marked question from Joel: IMHO and FWIW the receiver always sends all the bits in all the bytes in has received: the transmitter simply slices the (potentially, infinite) bitstream it has received into chunks, and the number of bits in each chunk is a multiple of 8. A more interesting question is what happens if a packet that carries one of the chunks is lost in transit. Of course, the receiver detects a lost packet (this is why the sequence numbers are MUST), and it also knows how many bits have been lost (this is why all chunks MUST be of the same size), so that it can play out some predefined patter (e.g., all ones) replacing the lost chunk in the outgoing bitstream. But how does the receiving CE react to such a replacement? In the case of traditional TDM streams, a pattern of all ones could be used to make the receiving CE to detect, report and handle a suitable alarm (AIS). But here we are dealing with Ethernet and Fober Channel… My 2c, Sasha From: Joel Halpern <j...@joelhalpern.com><mailto:j...@joelhalpern.com> Sent: Friday, October 18, 2024 9:33 PM To: Christian Schmutzer (cschmutz) <cschm...@cisco.com><mailto:cschm...@cisco.com> Cc: gen-art@ietf.org<mailto:gen-art@ietf.org>; draft-ietf-pals-ple....@ietf.org<mailto:draft-ietf-pals-ple....@ietf.org>; last-c...@ietf.org<mailto:last-c...@ietf.org>;p...@ietf.org<mailto:p...@ietf.org> Subject: [EXTERNAL] [Pals] Re: Genart last call review of draft-ietf-pals-ple-08 Thanks. With regard to the non-byte-aligned payload, I am still slightly confused. I can well believe this is clear to those working in the area. But... If the payload is not byte aligned, and bytes are sent, how does the receiver know how many bits in the last byte to ignore? Thanks, Joel On 10/18/2024 1:44 PM, Christian Schmutzer (cschmutz) wrote: Hi Joel, Thank you for your review! Let me try to comment/answer here 1) RSV/FRG: Good catch. We indeed forgot to mention explicitly that payload fragmentation is not used by PLE. I changed the text for FRG to These bits MUST be set to zero by the sender and ignored by the receiver as PLE does not use payload fragmentation And similar to RFC4553 (https://datatracker.ietf.org/doc/html/rfc4553#section-4.2<https://datatracker.ietf.org/doc/html/rfc4553#section-4.2>) I also added the following sentence to the PW demultiplexing section The total size of a PLE packet for a specific PW MUST NOT exceed the path MTU between the pair of PEs terminating this PW. 2) byte aligned payload For Ethernet and Fibre Channel services, PLE is carrying 66B/64B encoded data for example. So the payload carried by PLE is not always in bytes. The basic payload of PLE is designed to be completely structure agnostic without any need to align the PLE packet generation with the incoming payload data. For OTN services (https://datatracker.ietf.org/doc/html/draft-ietf-pals-ple-08#section-4.5<https://datatracker.ietf.org/doc/html/draft-ietf-pals-ple-08#section-4.5>) the CE-bound IWF function must extract the extended ODUk frames from the received PLE payloads. Based on our discussions with leading OTN technology vendors, this "search function" is easier to implement under the assumption that the PLE payload is byte aligned hence we defined this dedicated PLE payload type which is byte aligned for OTN services. I hope this addresses your comments. The changes with respect to 1) are included in the -09 version I just uploaded to data tracker Regards Christian On 11.10.2024, at 16:34, Joel Halpern via Datatracker<nore...@ietf.org><mailto:nore...@ietf.org>wrote: Reviewer: Joel Halpern Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://wiki.ietf.org/en/group/gen/GenArtFAQ><https://wiki.ietf.org/en/group/gen/GenArtFAQ>. Document: draft-ietf-pals-ple-08 Reviewer: Joel Halpern Review Date: 2024-10-11 IETF LC End Date: 2024-10-23 IESG Telechat date: Not scheduled for a telechat Summary: This draft is ready for publication as a Proposed Standard Major issues: N/A Minor issues: N/A Nits/editorial comments: Section 5.2.1 defining the PLEA Control Word describes two pairs of bits, one pair called RSSV and described in the usual way for describing reserved bits. A second pair is called FRG and is described more teresely but appears to be simply more reserved bits. It is unclear why these two fields are separated, and why the wording is slightly different between them. Section 6 desccribes the basic payload and the byte aligned payload. The description makes it look like there are two different forms. Thinking about it, the payload is always in bytes, so the sender will fill bits from the source until it has filled the fixed number of bytes. SO what is the difference between 6.1 and 6.2? Disclaimer This e-mail together with any attachments may contain information of Ribbon Communications Inc. and its Affiliates 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.
_______________________________________________ Gen-art mailing list -- gen-art@ietf.org To unsubscribe send an email to gen-art-le...@ietf.org
