[Pals] Re: Zaheduzzaman Sarker's Discuss on draft-ietf-pal s-ple-13: (with DISCUSS and COMMENT)
Zaheduzzaman Sarker <[email protected]> Fri, 13 Dec 2024 09:35:35 +0100
| Newsgroups | gmane.ietf.pwe3 |
|---|---|
| Message-ID | <CAEh=tcfn5enHOc8pSDwmrM-12_ej_Jf_c0QEAzz5js16hDHfbg@mail.gmail.com> |
--===============2076833061078114765== Content-Type: multipart/alternative; boundary="00000000000096701e062922b7d1" --00000000000096701e062922b7d1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Dec 12, 2024 at 12:49=E2=80=AFAM Christian Schmutzer (cschmutz) < [email protected]> wrote: > Hi Zaheduzzaman, > > Thank you for review and feedback. Please find comments inline via [cs] > > Regards > Christian > > On 04.12.2024, at 18:40, Zaheduzzaman Sarker via Datatracker < > [email protected]> wrote: > > Zaheduzzaman Sarker has entered the following ballot position for > draft-ietf-pals-ple-13: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to > https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positio= ns/ > for more information about how to handle DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-pals-ple/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Thanks for working on this specification. Thanks to Tommy Pauly for the > TSVART > review. > > I have one discuss point - > > # I didn't find the rational to use RTP header in this protocol. If we ar= e > only > interestes in timestamp, SSRC and PT (not sure why we need it), and setti= ng > rest of bits to zeros then why can't we incorporate timestamp, SSRC in th= e > PLE > control word? I would like to see a description on the rationale on the > use RTP > here and proper description of the RTP endpoint behaviour. To me it is > important, as RTP has a particular use and I am not sure if these simulat= ed > packets will never reach to a proper RTP endpoint. I think we can improve > this > specification by explicitly saying best practices for the isolation of th= e > PSN > is a MUST, if RTP header is used. > > > [cs] this document expands the applicability of bit stream pseudowires > defined in RFC4553 to a broader range of service types than just E1, T1, = E3 > and T3. Also it is worth to note that the (re-)use of the RFC3550 RTP > header is common across all bit stream pseudowire RFCs defined so far > (RFC4553, RFC4842 and RFC5086). > > So it seemed a good rational to align with this precedence. It also allow= s > implementers to reuse existing (FPGA code) work that was done for RFC4553 > products. > I see the point, and that is fine. Can't we then describe the reasonings (like you mentioned here) in the document where we introduce the RTP header usage? > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > > Apart from my discuss point - I had hard time to understand the following > section > > The RTP header is purely a formal reuse and RTP mechanisms, such as > header > extensions, contributing source (CSRC) list, padding, RTP Control > Protocol > (RTCP), RTP header compression, Secure Realtime Transport Protocol > (SRTP), > etc., are not applicable to PLE VPWS. > > Specially, what does "purely a formal reuse" mean? My "formal" reuse will > mean > a proper RTP endpoint with RTCP. > > Also please explain the need ofr PT in PLE header. > > > [cs] we are using the same wording as > https://datatracker.ietf.org/doc/html/rfc4842#autoid-8 and > https://datatracker.ietf.org/doc/html/rfc5086#section-4.4. > And unfortunately none of those describe what "purely a formal reuse" actually means. I still think we can do a better job when defining new protocols. What about - The RTP header is reused here to convey particular information and there is no intention to support full RTP topology or protocol mechanisms, such as header extensions, contributing source (CSRC) list, padding, RTP Control Protoco= l (RTCP), RTP header compression, Secure Realtime Transport Protocol (SRTP)= , etc., are not applicable to PLE VPWS. ?? > > Good point about the need/use of PT. I would propose to add the following > bullet =E2=80=9CThe PT field MAY be used for detection of misconnections.= " > > > > > > --00000000000096701e062922b7d1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote g= mail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Thu, Dec 12,= 2024 at 12:49=E2=80=AFAM Christian Schmutzer (cschmutz) <<a href=3D"mai= lto:[email protected]">[email protected]</a>> wrote:<br></div><blockqu= ote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px= solid rgb(204,204,204);padding-left:1ex"> <div> <div dir=3D"auto"> Hi Zaheduzzaman, <div><br> </div> <div>Thank you for review and feedback. Please find comments inline via [cs= ]</div> <div><br> </div> <div>Regards</div> <div>Christian=C2=A0<br id=3D"m_-1879571257660566180lineBreakAtBeginningOfM= essage"> <div><br> <blockquote type=3D"cite"> <div>On 04.12.2024, at 18:40, Zaheduzzaman Sarker via Datatracker <<a hr= ef=3D"mailto:[email protected]" target=3D"_blank">[email protected]</a>> w= rote:</div> <br> <div> <div>Zaheduzzaman Sarker has entered the following ballot position for<br> draft-ietf-pals-ple-13: Discuss<br> <br> When responding, please keep the subject line intact and reply to all<br> email addresses included in the To and CC lines. (Feel free to cut this<br> introductory paragraph, however.)<br> <br> <br> Please refer to <a href=3D"https://www.ietf.org/about/groups/iesg/statement= s/handling-ballot-positions/" target=3D"_blank">https://www.ietf.org/about/= groups/iesg/statements/handling-ballot-positions/</a> <br> for more information about how to handle DISCUSS and COMMENT positions.<br> <br> <br> The document, along with other ballot positions, can be found here:<br> <a href=3D"https://datatracker.ietf.org/doc/draft-ietf-pals-ple/" target=3D= "_blank">https://datatracker.ietf.org/doc/draft-ietf-pals-ple/</a><br> <br> <br> <br> ----------------------------------------------------------------------<br> DISCUSS:<br> ----------------------------------------------------------------------<br> <br> Thanks for working on this specification. Thanks to Tommy Pauly for the TSV= ART<br> review.<br> <br> I have one discuss point -<br> <br> # I didn't find the rational to use RTP header in this protocol. If we = are only<br> interestes in timestamp, SSRC and PT (not sure why we need it), and setting= <br> rest of bits to zeros then why can't we incorporate timestamp, SSRC in = the PLE<br> control word? I would like to see a description on the rationale on the use= RTP<br> here and proper description of the RTP endpoint behaviour. To me it is<br> important, as RTP has a particular use and I am not sure if these simulated= <br> packets will never reach to a proper RTP endpoint. I think we can improve t= his<br> specification by explicitly saying best practices for the isolation of the = PSN<br> is a MUST, if RTP header is used.<br> </div> </div> </blockquote> <div><br> </div> <div>[cs] this document expands the applicability of bit stream pseudowires= defined in RFC4553 to a broader range of service types than just E1, T1, E= 3 and T3. Also it is worth to note that the (re-)use of the RFC3550 RTP hea= der is common across all bit stream pseudowire RFCs defined so far (RFC4553, RFC4842 and RFC5086).=C2=A0</div> <div><br> </div> <div>So it seemed a good rational to align with this precedence. It also al= lows implementers to reuse existing (FPGA code) work that was done for RFC4= 553 products.</div></div></div></div></div></blockquote><div><br></div><div= >I see the point, and that is fine. Can't we then describe the reasonin= gs (like you mentioned here) in the document where we introduce the RTP hea= der usage?<br>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin= :0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"= ><div><div dir=3D"auto"><div><div> <br> <blockquote type=3D"cite"> <div> <div>----------------------------------------------------------------------= <br> COMMENT:<br> ----------------------------------------------------------------------<br> <br> <br> Apart from my discuss point - I had hard time to understand the following<b= r> section<br> <br> =C2=A0=C2=A0The RTP header is purely a formal reuse and RTP mechanisms, suc= h as header<br> =C2=A0=C2=A0extensions, contributing source (CSRC) list, padding, RTP Contr= ol Protocol<br> =C2=A0=C2=A0(RTCP), RTP header compression, Secure Realtime Transport Proto= col (SRTP),<br> =C2=A0=C2=A0etc., are not applicable to PLE VPWS.<br> <br> Specially, what does "purely a formal reuse" mean? My "forma= l" reuse will mean<br> a proper RTP endpoint with RTCP.<br> <br> Also please explain the need ofr PT in PLE header.<br> </div> </div> </blockquote> <div><br> </div> <div>[cs] we are using the same wording as=C2=A0<a href=3D"https://datatrac= ker.ietf.org/doc/html/rfc4842#autoid-8" target=3D"_blank">https://datatrack= er.ietf.org/doc/html/rfc4842#autoid-8</a>=C2=A0and=C2=A0<a href=3D"https://= datatracker.ietf.org/doc/html/rfc5086#section-4.4" target=3D"_blank">https:= //datatracker.ietf.org/doc/html/rfc5086#section-4.4</a>.=C2=A0</div></div><= /div></div></div></blockquote><div><br></div><div>And unfortunately=C2=A0no= ne of those describe what "purely a formal reuse" actually=C2=A0m= eans. I still think we can do a better job when defining new protocols. Wha= t about -</div><div><br></div><div><blockquote type=3D"cite"><div><div>=C2= =A0 The RTP header is reused here to convey particular information and ther= e is no intention to support full RTP topology or protocol mechanisms, such= as header<br>=C2=A0=C2=A0extensions, contributing source (CSRC) list, padd= ing, RTP Control Protocol<br>=C2=A0=C2=A0(RTCP), RTP header compression, Se= cure Realtime Transport Protocol (SRTP),<br>=C2=A0=C2=A0etc., are not appli= cable to PLE VPWS.</div></div></blockquote></div><div>??=C2=A0</div><blockq= uote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1p= x solid rgb(204,204,204);padding-left:1ex"><div><div dir=3D"auto"><div><div= > <div><br> </div> <div>Good point about the need/use of PT. I would propose to add the follow= ing bullet =E2=80=9CThe PT field MAY be used for detection of misconnection= s."</div> <div><br> </div> <blockquote type=3D"cite"> <div> <div><br> <br> <br> </div> </div> </blockquote> </div> <br> </div> </div> </div> </blockquote></div></div> --00000000000096701e062922b7d1-- --===============2076833061078114765== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KUGFscyBtYWls aW5nIGxpc3QgLS0gcGFsc0BpZXRmLm9yZwpUbyB1bnN1YnNjcmliZSBzZW5kIGFuIGVtYWlsIHRv IHBhbHMtbGVhdmVAaWV0Zi5vcmcK --===============2076833061078114765==--