[Pals] Re: Genart last call review of draft-ietf-pals-ple-08
Joel Halpern <[email protected]> Fri, 18 Oct 2024 16:03:18 -0400
| Newsgroups | gmane.ietf.pwe3,gmane.ietf.gen-art |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format. --===============5664071136971199725== Content-Type: multipart/alternative; boundary="------------NFulp0vC5OFPi58zMVXe33xj" Content-Language: en-US This is a multi-part message in MIME format. --------------NFulp0vC5OFPi58zMVXe33xj Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Thanks for confirming. Since I can't come up with suggested text to make this clearer, I will consider the issue resolved. Yours, Joel On 10/18/2024 3:44 PM, Christian Schmutzer (cschmutz) wrote: > Correct. In case of the byte-aligned mode, the receiver (IWF) of the > ingress PE is working at byte level and each PLE payload does start > with the first bit of a byte. > > Christian > >> On 18.10.2024, at 21:37, jmh.direct <[email protected]> wrote: >> >> If I understand, both modes send full bytes. It just Tha in one case >> the receiver interprets it as a raw bit stream, and in the other case >> the receiver understands it as a byte stream needing processing? >> Yours, >> Joel >> >> >> >> Sent via the Samsung Galaxy S20 FE 5G, an AT&T 5G smartphone >> >> >> -------- Original message -------- >> From: "Christian Schmutzer (cschmutz)" <[email protected]> >> Date: 10/18/24 3:26 PM (GMT-05:00) >> To: Joel Halpern <[email protected]> >> Cc: "Christian Schmutzer (cschmutz)" <[email protected]>, >> [email protected], [email protected], >> [email protected], [email protected] >> Subject: Re: Genart last call review of draft-ietf-pals-ple-08 >> >> Hi Joel, >> >> When the basic payload is used, the IWF of the ingress PE is storing >> bits (not bytes) as they come in, waits until enough bits have been >> received to fill a payload and once ready creates a PLE packet and >> sends it across the PSN. The IWF of the egress PE is doing the >> reverse in accordance to the recovered clock (DCR). >> >> In the end of the day a series of bits make their way across the PSN >> as is … i.e. the PLE service makes the two CEs connected to the PLE >> service think they are connected via a pair of fibre. >> >> The CEs apply their technology specific pattern sync methods to >> detect framing patters, etc without any interaction with the PEs. For >> Ethernet PCS sync is done, for SONET A1,A2 framing is performed. >> >> OTN services are a special case because we can’t carry bits as is. >> The ingress NSP function must terminate the lowest OTN layer called >> OTUk as it contains FEC. This means the egress NSP must create the >> OTUk/FEC layer, and in order to do that byte aligning the PLE packet >> is beneficial. >> >> Regards >> Christian >> >>> On 18.10.2024, at 20:33, Joel Halpern <[email protected]> wrote: >>> >>> 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) 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) >>>> 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 >>>>> <[email protected]> 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>. >>>>> >>>>> 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? >>>>> >>>>> >>>> >> > --------------NFulp0vC5OFPi58zMVXe33xj Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit <!DOCTYPE html> <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> </head> <body> <p>Thanks for confirming. Since I can't come up with suggested text to make this clearer, I will consider the issue resolved.</p> <p>Yours,</p> <p>Joel<br> </p> <div class="moz-cite-prefix">On 10/18/2024 3:44 PM, Christian Schmutzer (cschmutz) wrote:<br> </div> <blockquote type="cite" cite="mid:[email protected]"> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> Correct. In case of the byte-aligned mode, the receiver (IWF) of the ingress PE is working at byte level and each PLE payload does start with the first bit of a byte. <div><br> </div> <div>Christian<br id="lineBreakAtBeginningOfMessage"> <div><br> <blockquote type="cite"> <div>On 18.10.2024, at 21:37, jmh.direct <a class="moz-txt-link-rfc2396E" href="mailto:[email protected]"><[email protected]></a> wrote:</div> <br class="Apple-interchange-newline"> <div> <div dir="auto"> <div dir="auto">If I understand, both modes send full bytes. It just Tha in one case the receiver interprets it as a raw bit stream, and in the other case the receiver understands it as a byte stream needing processing?</div> <div dir="auto">Yours,</div> <div dir="auto">Joel</div> <div dir="auto"><br> </div> <div dir="auto"><br> </div> <div dir="auto"><br> </div> <div id="composer_signature" dir="auto"> <div style="font-size:12px;color:#575757" dir="auto">Sent via the Samsung Galaxy S20 FE 5G, an AT&T 5G smartphone</div> </div> <div dir="auto"><br> </div> <div><br> </div> <div align="left" dir="auto" style="font-size: 100%;"> <div>-------- Original message --------</div> <div>From: "Christian Schmutzer (cschmutz)" <a class="moz-txt-link-rfc2396E" href="mailto:[email protected]"><[email protected]></a> </div> <div>Date: 10/18/24 3:26 PM (GMT-05:00) </div> <div>To: Joel Halpern <a class="moz-txt-link-rfc2396E" href="mailto:[email protected]"><[email protected]></a> </div> <div>Cc: "Christian Schmutzer (cschmutz)" <a class="moz-txt-link-rfc2396E" href="mailto:[email protected]"><[email protected]></a>, <a class="moz-txt-link-abbreviated" href="mailto:[email protected]">[email protected]</a>, <a class="moz-txt-link-abbreviated" href="mailto:[email protected]">[email protected]</a>, <a class="moz-txt-link-abbreviated" href="mailto:[email protected]">[email protected]</a>, <a class="moz-txt-link-abbreviated" href="mailto:[email protected]">[email protected]</a> </div> <div>Subject: Re: Genart last call review of draft-ietf-pals-ple-08 </div> <div><br> </div> </div> Hi Joel, <div> <div><br> </div> <div>When the basic payload is used, the IWF of the ingress PE is storing bits (not bytes) as they come in, waits until enough bits have been received to fill a payload and once ready creates a PLE packet and sends it across the PSN. The IWF of the egress PE is doing the reverse in accordance to the recovered clock (DCR). </div> <div><br> </div> <div>In the end of the day a series of bits make their way across the PSN as is … i.e. the PLE service makes the two CEs connected to the PLE service think they are connected via a pair of fibre. </div> <div><br> </div> <div>The CEs apply their technology specific pattern sync methods to detect framing patters, etc without any interaction with the PEs. For Ethernet PCS sync is done, for SONET A1,A2 framing is performed.</div> <div><br> </div> <div>OTN services are a special case because we can’t carry bits as is. The ingress NSP function must terminate the lowest OTN layer called OTUk as it contains FEC. This means the egress NSP must create the OTUk/FEC layer, and in order to do that byte aligning the PLE packet is beneficial.</div> <div><br> </div> <div>Regards</div> <div>Christian <br id="lineBreakAtBeginningOfMessage"> <div><br> <blockquote type="cite"> <div>On 18.10.2024, at 20:33, Joel Halpern <a class="moz-txt-link-rfc2396E" href="mailto:[email protected]"><[email protected]></a> wrote:</div> <br class="Apple-interchange-newline"> <div> <div> <p>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?</p> <p>Thanks,</p> <p>Joel<br> </p> <div class="moz-cite-prefix">On 10/18/2024 1:44 PM, Christian Schmutzer (cschmutz) wrote:<br> </div> <blockquote type="cite">Hi Joel, <div><br> </div> <div>Thank you for your review! Let me try to comment/answer here</div> <div><br> </div> <div><u>1) RSV/FRG:</u></div> <div><br> </div> <div>Good catch. We indeed forgot to mention explicitly that payload fragmentation is not used by PLE. I changed the text for FRG to </div> <div><br> </div> <div> These bits MUST be set to zero by the sender and ignored by the receiver as PLE does not use payload fragmentation</div> <div><br> </div> <div>And similar to RFC4553 (<a class="moz-txt-link-freetext" href="https://datatracker.ietf.org/doc/html/rfc4553#section-4.2" moz-do-not-send="true">https://datatracker.ietf.org/doc/html/rfc4553#section-4.2</a>) I also added the following sentence to the PW demultiplexing section</div> <div><br> </div> <div> 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.</div> <div><br> </div> <div><br> </div> <div><u>2) byte aligned payload</u></div> <div><br> </div> <div> <div>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.</div> <div><br> </div> <div>For OTN services (<a href="https://datatracker.ietf.org/doc/html/draft-ietf-pals-ple-08#section-4.5" class="moz-txt-link-freetext" moz-do-not-send="true">https://datatracker.ietf.org/doc/html/draft-ietf-pals-ple-08#section-4.5</a>) 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.</div> </div> <div><br> </div> <div><br> </div> <div>I hope this addresses your comments. The changes with respect to 1) are included in the -09 version I just uploaded to data tracker</div> <div><br> </div> <div>Regards</div> <div>Christian <br id="lineBreakAtBeginningOfMessage"> <div><br> <blockquote type="cite"> <div>On 11.10.2024, at 16:34, Joel Halpern via Datatracker <a href="mailto:[email protected]" class="moz-txt-link-rfc2396E" moz-do-not-send="true"> <[email protected]></a> wrote:</div> <br class="Apple-interchange-newline"> <div> <div>Reviewer: Joel Halpern<br> Review result: Ready with Nits<br> <br> I am the assigned Gen-ART reviewer for this draft. The General Area<br> Review Team (Gen-ART) reviews all IETF documents being processed<br> by the IESG for the IETF Chair. Please treat these comments just<br> like any other last call comments.<br> <br> For more information, please see the FAQ at<br> <br> <a href="https://wiki.ietf.org/en/group/gen/GenArtFAQ" class="moz-txt-link-rfc2396E" moz-do-not-send="true"><https://wiki.ietf.org/en/group/gen/GenArtFAQ></a>.<br> <br> Document: draft-ietf-pals-ple-08<br> Reviewer: Joel Halpern<br> Review Date: 2024-10-11<br> IETF LC End Date: 2024-10-23<br> IESG Telechat date: Not scheduled for a telechat<br> <br> Summary: This draft is ready for publication as a Proposed Standard<br> <br> Major issues: N/A<br> <br> Minor issues: N/A<br> <br> Nits/editorial comments:<br> Section 5.2.1 defining the PLEA Control Word describes two pairs of bits,<br> one pair called RSSV and described in the usual way for describing reserved<br> bits. A second pair is called FRG and is described more teresely but<br> appears to be simply more reserved bits. It is unclear why these two<br> fields are separated, and why the wording is slightly different between<br> them.<br> <br> Section 6 desccribes the basic payload and the byte aligned payload. The<br> description makes it look like there are two different forms. Thinking<br> about it, the payload is always in bytes, so the sender will fill bits from<br> the source until it has filled the fixed number of bytes. SO what is the<br> difference between 6.1 and 6.2?<br> <br> <br> </div> </div> </blockquote> </div> <br> </div> </blockquote> </div> </div> </blockquote> </div> <br> </div> </div> </div> </div> </blockquote> </div> <br> </div> </blockquote> </body> </html> --------------NFulp0vC5OFPi58zMVXe33xj-- --===============5664071136971199725== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KUGFscyBtYWls aW5nIGxpc3QgLS0gcGFsc0BpZXRmLm9yZwpUbyB1bnN1YnNjcmliZSBzZW5kIGFuIGVtYWlsIHRv IHBhbHMtbGVhdmVAaWV0Zi5vcmcK --===============5664071136971199725==--