[Pals] Re: Genart last call review of draft-ietf-pals-ple-08
"Christian Schmutzer \(cschmutz\)" <[email protected]> Fri, 18 Oct 2024 17:44:57 +0000
| Newsgroups | gmane.ietf.pwe3,gmane.ietf.gen-art |
|---|---|
| Message-ID | <[email protected]> |
--===============5578183768133712628==
Content-Language: en-US
Content-Type: multipart/alternative;
boundary="_000_D0319BE35A83408B9E7CBD629712594Aciscocom_"
--_000_D0319BE35A83408B9E7CBD629712594Aciscocom_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
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 fragmentati=
on 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 receive=
r as PLE does not use payload fragmentation
And similar to RFC4553 (https://datatracker.ietf.org/doc/html/rfc4553#secti=
on-4.2) I also added the following sentence to the PW demultiplexing sectio=
n
The total size of a PLE packet for a specific PW MUST NOT exceed the pa=
th 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 da=
ta for example. So the payload carried by PLE is not always in bytes. The b=
asic 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 f=
rames from the received PLE payloads. Based on our discussions with leading=
OTN technology vendors, this "search function" is easier to implement unde=
r 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 inc=
luded 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]> wr=
ote:
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 reser=
ved
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. Th=
e
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 f=
rom
the source until it has filled the fixed number of bytes. SO what is th=
e
difference between 6.1 and 6.2?
--_000_D0319BE35A83408B9E7CBD629712594Aciscocom_
Content-Type: text/html; charset="us-ascii"
Content-ID: <[email protected]>
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
</head>
<body style=3D"overflow-wrap: break-word; -webkit-nbsp-mode: space; line-br=
eak: after-white-space;">
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 fragme=
ntation 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 href=3D"https://datatracker.ietf.org/doc/ht=
ml/rfc4553#section-4.2">https://datatracker.ietf.org/doc/html/rfc4553#secti=
on-4.2</a>) I also added the following sentence to the PW demultiplexing se=
ction</div>
<div><br>
</div>
<div> The total size of a PLE packet for a specific PW MUST NO=
T 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 encod=
ed 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 wi=
thout any need to align the PLE
packet generation with the incoming payload data.</div>
<div><br>
</div>
<div>For OTN services (https://datatracker.ietf.org/doc/html/draft-ietf-pal=
s-ple-08#section-4.5) the CE-bound IWF function must extract the extended O=
DUk frames from the received PLE payloads. Based on our discussions with le=
ading OTN technology vendors, this
"search function" is easier to implement under the assumption th=
at the PLE payload is byte aligned hence we defined this dedicated PLE payl=
oad 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) ar=
e included in the -09 version I just uploaded to data tracker</div>
<div><br>
</div>
<div>Regards</div>
<div>Christian <br id=3D"lineBreakAtBeginningOfMessage">
<div><br>
<blockquote type=3D"cite">
<div>On 11.10.2024, at 16:34, Joel Halpern via Datatracker <noreply@ietf=
.org> wrote:</div>
<br class=3D"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>
<https://wiki.ietf.org/en/group/gen/GenArtFAQ>.<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 tw=
o pairs of bits,<br>
one pair called RSSV and described in the usual way for d=
escribing reserved<br>
bits. A second pair is called FRG and is described =
more teresely but<br>
appears to be simply more reserved bits. It i=
s unclear why these two<br>
fields are separated, and why the wording is slightly dif=
ferent between<br>
them.<br>
<br>
Section 6 desccribes the basic payload and the byte align=
ed payload. The<br>
description makes it look like there are two different fo=
rms. Thinking<br>
about it, the payload is always in bytes, so the sender w=
ill 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>
</body>
</html>
--_000_D0319BE35A83408B9E7CBD629712594Aciscocom_--
--===============5578183768133712628==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: inline
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KUGFscyBtYWls
aW5nIGxpc3QgLS0gcGFsc0BpZXRmLm9yZwpUbyB1bnN1YnNjcmliZSBzZW5kIGFuIGVtYWlsIHRv
IHBhbHMtbGVhdmVAaWV0Zi5vcmcK
--===============5578183768133712628==--