[Pals] Re: [EXTERNAL] Re: Genart last call review of d raft-ietf-pals-ple-08
Joel Halpern <[email protected]> Sun, 20 Oct 2024 08:31:45 -0400
| Newsgroups | gmane.ietf.pwe3,gmane.ietf.gen-art |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format. --===============2845983769504429098== Content-Type: multipart/alternative; boundary="------------o8Q81yzehYDcGchFac184DTb" Content-Language: en-US This is a multi-part message in MIME format. --------------o8Q81yzehYDcGchFac184DTb Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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 <[email protected]> > *Sent:* Friday, October 18, 2024 9:33 PM > *To:* Christian Schmutzer (cschmutz) <[email protected]> > *Cc:* [email protected]; [email protected]; > [email protected]; [email protected] > *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) 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]> <mailto:[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> > <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. > --------------o8Q81yzehYDcGchFac184DTb 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>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.</p> <p>Yours,</p> <p>Joel<br> </p> <div class="moz-cite-prefix">On 10/20/2024 4:04 AM, Alexander Vainshtein wrote:<br> </div> <blockquote type="cite" cite="mid:PH0PR03MB63008438114BDB605453A337F6422@PH0PR03MB6300.namprd03.prod.outlook.com"> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> <meta name="Generator" content="Microsoft Word 15 (filtered medium)"> <style>@font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4;}@font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;}@font-face {font-family:Aptos;}p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0cm; font-size:12.0pt; font-family:"Aptos",sans-serif;}a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;}span.EmailStyle19 {mso-style-type:personal-reply; font-family:"Aptos",sans-serif; color:windowtext;}.MsoChpDefault {mso-style-type:export-only; font-size:10.0pt; mso-ligatures:none;}div.WordSection1 {page:WordSection1;}</style><!--[if gte mso 9]><xml> <o:shapedefaults v:ext="edit" spidmax="1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext="edit"> <o:idmap v:ext="edit" data="1" /> </o:shapelayout></xml><![endif]--> <style type="text/css">.style1 {font-family: "Times New Roman";}</style> <div class="WordSection1"> <p class="MsoNormal"><span style="font-size:11.0pt">Joel, Christian and all,<o:p></o:p></span></p> <p class="MsoNormal"><span style="font-size:11.0pt">Regarding the <span style="background:yellow;mso-highlight:yellow"> marked question from Joel</span>:<o:p></o:p></span></p> <p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p> <p class="MsoNormal"><span style="font-size:11.0pt">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.<o:p></o:p></span></p> <p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p> <p class="MsoNormal"><span style="font-size:11.0pt">A more interesting question is what happens if a packet that carries one of the chunks is lost in transit.<o:p></o:p></span></p> <p class="MsoNormal"><span style="font-size:11.0pt">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?<o:p></o:p></span></p> <p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p> <p class="MsoNormal"><span style="font-size:11.0pt">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). <o:p></o:p></span></p> <p class="MsoNormal"><span style="font-size:11.0pt">But here we are dealing with Ethernet and Fober Channel…<o:p></o:p></span></p> <p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p> <p class="MsoNormal"><span style="font-size:11.0pt">My 2c,<o:p></o:p></span></p> <div> <p class="MsoNormal"><span style="font-size:11.0pt">Sasha<o:p></o:p></span></p> </div> <p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p> <div> <div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm"> <p class="MsoNormal" style="margin-left:36.0pt"><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> Joel Halpern <a class="moz-txt-link-rfc2396E" href="mailto:[email protected]"><[email protected]></a> <br> <b>Sent:</b> Friday, October 18, 2024 9:33 PM<br> <b>To:</b> Christian Schmutzer (cschmutz) <a class="moz-txt-link-rfc2396E" href="mailto:[email protected]"><[email protected]></a><br> <b>Cc:</b> <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><br> <b>Subject:</b> [EXTERNAL] [Pals] Re: Genart last call review of draft-ietf-pals-ple-08<o:p></o:p></span></p> </div> </div> <p class="MsoNormal" style="margin-left:36.0pt"><o:p> </o:p></p> <p style="margin-left:36.0pt">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, <span style="background:yellow;mso-highlight:yellow">how does the receiver know how many bits in the last byte to ignore</span>?<o:p></o:p></p> <p style="margin-left:36.0pt">Thanks,<o:p></o:p></p> <p style="margin-left:36.0pt">Joel<o:p></o:p></p> <div> <p class="MsoNormal" style="margin-left:36.0pt">On 10/18/2024 1:44 PM, Christian Schmutzer (cschmutz) wrote:<o:p></o:p></p> </div> <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"> <p class="MsoNormal" style="margin-left:36.0pt">Hi Joel, <o:p></o:p></p> <div> <p class="MsoNormal" style="margin-left:36.0pt"><o:p> </o:p></p> </div> <div> <p class="MsoNormal" style="margin-left:36.0pt">Thank you for your review! Let me try to comment/answer here<o:p></o:p></p> </div> <div> <p class="MsoNormal" style="margin-left:36.0pt"><o:p> </o:p></p> </div> <div> <p class="MsoNormal" style="margin-left:36.0pt"><u>1) RSV/FRG:</u><o:p></o:p></p> </div> <div> <p class="MsoNormal" style="margin-left:36.0pt"><o:p> </o:p></p> </div> <div> <p class="MsoNormal" style="margin-left:36.0pt">Good catch. We indeed forgot to mention explicitly that payload fragmentation is not used by PLE. I changed the text for FRG to <o:p></o:p></p> </div> <div> <p class="MsoNormal" style="margin-left:36.0pt"><o:p> </o:p></p> </div> <div> <p class="MsoNormal" style="margin-left:36.0pt"> These bits MUST be set to zero by the sender and ignored by the receiver as PLE does not use payload fragmentation<o:p></o:p></p> </div> <div> <p class="MsoNormal" style="margin-left:36.0pt"><o:p> </o:p></p> </div> <div> <p class="MsoNormal" style="margin-left:36.0pt">And similar to RFC4553 (<a href="https://datatracker.ietf.org/doc/html/rfc4553#section-4.2" moz-do-not-send="true" class="moz-txt-link-freetext">https://datatracker.ietf.org/doc/html/rfc4553#section-4.2</a>) I also added the following sentence to the PW demultiplexing section<o:p></o:p></p> </div> <div> <p class="MsoNormal" style="margin-left:36.0pt"><o:p> </o:p></p> </div> <div> <p class="MsoNormal" style="margin-left:36.0pt"> 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.<o:p></o:p></p> </div> <div> <p class="MsoNormal" style="margin-left:36.0pt"><o:p> </o:p></p> </div> <div> <p class="MsoNormal" style="margin-left:36.0pt"><o:p> </o:p></p> </div> <div> <p class="MsoNormal" style="margin-left:36.0pt"><u>2) byte aligned payload</u><o:p></o:p></p> </div> <div> <p class="MsoNormal" style="margin-left:36.0pt"><o:p> </o:p></p> </div> <div> <div> <p class="MsoNormal" style="margin-left:36.0pt">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.<o:p></o:p></p> </div> <div> <p class="MsoNormal" style="margin-left:36.0pt"><o:p> </o:p></p> </div> <div> <p class="MsoNormal" style="margin-left:36.0pt">For OTN services (<a href="https://datatracker.ietf.org/doc/html/draft-ietf-pals-ple-08#section-4.5" moz-do-not-send="true" class="moz-txt-link-freetext">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.<o:p></o:p></p> </div> </div> <div> <p class="MsoNormal" style="margin-left:36.0pt"><o:p> </o:p></p> </div> <div> <p class="MsoNormal" style="margin-left:36.0pt"><o:p> </o:p></p> </div> <div> <p class="MsoNormal" style="margin-left:36.0pt">I hope this addresses your comments. The changes with respect to 1) are included in the -09 version I just uploaded to data tracker<o:p></o:p></p> </div> <div> <p class="MsoNormal" style="margin-left:36.0pt"><o:p> </o:p></p> </div> <div> <p class="MsoNormal" style="margin-left:36.0pt">Regards<o:p></o:p></p> </div> <div> <p class="MsoNormal" style="margin-left:36.0pt">Christian <o:p></o:p></p> <div> <p class="MsoNormal" style="margin-left:36.0pt"><br> <br> <o:p></o:p></p> <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"> <div> <p class="MsoNormal" style="margin-left:36.0pt">On 11.10.2024, at 16:34, Joel Halpern via Datatracker <a href="mailto:[email protected]" moz-do-not-send="true"><[email protected]></a> wrote:<o:p></o:p></p> </div> <p class="MsoNormal" style="margin-left:36.0pt"><o:p> </o:p></p> <div> <div> <p class="MsoNormal" style="mso-margin-top-alt:0cm;margin-right:0cm;margin-bottom:12.0pt;margin-left:36.0pt"> 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" 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> <o:p></o:p></p> </div> </div> </blockquote> </div> <p class="MsoNormal" style="margin-left:36.0pt"><o:p> </o:p></p> </div> </blockquote> </div> <br> <br> <p style="font-family: Verdana; font-size:10pt; color:#666666;"><b>Disclaimer</b></p> <p style="font-family: Verdana; font-size:8pt; color:#666666;">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. </p> </blockquote> </body> </html> --------------o8Q81yzehYDcGchFac184DTb-- --===============2845983769504429098== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KUGFscyBtYWls aW5nIGxpc3QgLS0gcGFsc0BpZXRmLm9yZwpUbyB1bnN1YnNjcmliZSBzZW5kIGFuIGVtYWlsIHRv IHBhbHMtbGVhdmVAaWV0Zi5vcmcK --===============2845983769504429098==--