[Pals] Re: RtgDir Last Call review: draft-ietf-pals-ple
"Andrew G. Malis" <[email protected]> Fri, 28 Jun 2024 12:52:32 -0400
| Newsgroups | gmane.ietf.pwe3 |
|---|---|
| Message-ID | <CAA=duU2ex1n6O=e1CxR=38sjx+vDAR4xY=zqt-ADK7Vgbcw=tw@mail.gmail.com> |
--===============6427051354294055629== Content-Type: multipart/alternative; boundary="000000000000ebac77061bf6130f" --000000000000ebac77061bf6130f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Christian, Thanks! We'll get the process going from here. Cheers, Andy On Fri, Jun 28, 2024 at 11:26=E2=80=AFAM Christian Schmutzer (cschmutz) < [email protected]> wrote: > Hi Andy, > > Fyi I just uploaded a new version of the draft: > - addressing Tal=E2=80=99s RtgDir review comments > - checked all references against normative / informative > - added missing terminology definitions > - minor editorial changes as I saw fit > > regards > Christian > > On 17.06.2024, at 14:33, Andrew G. Malis <[email protected]> wrote: > > Christian, > > Thanks. I look forward to the next revision, after which we can start > getting ready for IESG submission. > > Cheers, > Andy > > > On Mon, Jun 17, 2024 at 1:13=E2=80=AFAM Christian Schmutzer (cschmutz) < > [email protected]> wrote: > >> Hi Andy and Tal, >> >> Works for me and agree on RFC8986 being normative. I will first describe >> the behaviours and only after that insert a note to the two informative >> references that don=E2=80=99t really define anything with respect to PLE= but >> provide context which I thought may be useful. >> >> Christian >> >> On 16.06.2024, at 21:28, Andrew G. Malis <[email protected]> wrote: >> >> Tal, >> >> That sounds good to me, thanks! >> >> Christian, how about you? >> >> Cheers, >> Andy >> >> >> On Sun, Jun 16, 2024 at 2:10=E2=80=AFPM Tal Mizrahi <tal.mizrahi.phd@gma= il.com> >> wrote: >> >>> Hi Andy, >>> >>> That is an interesting question. >>> The text that was suggested by Christian seemed to assume that the >>> reader is familiar with the previous endpoint behaviors (End.DX2, >>> End.DX2 with NEXT-CSID and End.DX2 with REPLACE-CSID). >>> Therefore, the text does not explain the meaning of the new endpoint >>> behaviors, because a reader who is familiar with the DX2 endpoint >>> behaviors would understand what the new DX1 behaviors do. >>> >>> A possible way around this is to add more detailed text to the current >>> document that explains for each of these new behaviors (End.DX1, >>> End.DX1 with NEXT-CSID and End.DX1 with REPLACE-CSID) what exactly it >>> means and the corresponding pseudo-code. The similarity to the DX2 >>> behaviors could be mentioned as a side note, and thus the two drafts >>> (srh-compression and srv6-usid) could be informative references. I >>> believe RFC 8986 should probably be normative anyway. >>> >>> Please let me know if that makes sense. >>> Cheers, >>> Tal. >>> >>> On Sun, Jun 16, 2024 at 4:26=E2=80=AFPM Andrew G. Malis <agmalis@gmail.= com> >>> wrote: >>> > >>> > Tal, >>> > >>> > Thanks again for your review and also reviewing Christian's reply. >>> > >>> > I'm concerned regarding your suggestion that >>> draft-filsfils-spring-net-pgm-extension-srv6-usid be made a normative >>> reference, as it is only an individual draft right now and there's no >>> guarantee that it'll even become a WG draft, never mind an RFC, and mak= ing >>> it a normative reference would hold up publishing this draft for quite = a >>> while, unless we get special dispensation from the IESG. Do you see any= way >>> we can get around making draft-filsfils normative? >>> > >>> > I'm much less concerned regarding >>> draft-ietf-spring-srv6-srh-compression, as that is currently in WG last >>> call. >>> > >>> > Thanks again, >>> > Andy >>> > >>> > >>> > On Sun, Jun 16, 2024 at 1:12=E2=80=AFAM Tal Mizrahi <tal.mizrahi.phd@= gmail.com> >>> wrote: >>> >> >>> >> Hi Christian and authors, >>> >> >>> >> Thanks for considering my comments. >>> >> The changes you suggested make sense to me. >>> >> >>> >> Regarding the new endpoint behaviors, please note: >>> >> - The IANA section will need to be updated accordingly. >>> >> - You may need to move the references to normative: {{?RFC8986}}, >>> >> {{?I-D.draft-ietf-spring-srv6-srh-compression}}, >>> >> {{?I-D.draft-filsfils-spring-net-pgm-extension-srv6-usid}}. >>> >> Specifically the last two, which may still be subject to changes. >>> >> >>> >> Cheers, >>> >> Tal. >>> >> >>> >> On Sat, Jun 8, 2024 at 12:16=E2=80=AFPM Christian Schmutzer (cschmut= z) >>> >> <[email protected]> wrote: >>> >> > >>> >> > Hi Tal, >>> >> > >>> >> > Sorry for taking so long. Below our comments and proposal for >>> addressing your issues. >>> >> > >>> >> > Can you please let us know your thoughts. Upon your feedback we >>> will work towards uploading a new version addressing the issues. >>> >> > >>> >> > regards >>> >> > Christian >>> >> > >>> >> > On 15.05.2024, at 01:20, Tal Mizrahi <[email protected]> >>> wrote: >>> >> > >>> >> > Hello, >>> >> > >>> >> > I have been selected as the Routing Directorate reviewer for this >>> >> > draft. The Routing Directorate seeks to review all routing or >>> >> > routing-related drafts as they pass through IETF last call and IES= G >>> >> > review, and sometimes on special request. The purpose of the revie= w >>> is >>> >> > to provide assistance to the Routing ADs. For more information abo= ut >>> >> > the Routing Directorate, please see >>> >> > https://wiki.ietf.org/en/group/rtg/RtgDir >>> >> > >>> >> > Document: draft-ietf-pals-ple-04 >>> >> > Reviewer: Tal Mizrahi >>> >> > Intended Status: Standards Track >>> >> > >>> >> > Summary: >>> >> > I have some concerns about this document that I think should be >>> >> > resolved before publication. >>> >> > >>> >> > The draft is well-written and clear from a grammatical and >>> structural >>> >> > perspective. However, there is a very long list of normative >>> >> > references that are cited in almost every paragraph of the documen= t, >>> >> > making it very difficult to follow for a reader who is somewhat >>> >> > familiar with the area but is not an expert in the area. >>> >> > >>> >> > >>> >> > [cs] >>> >> > PLE has a lot of similarities with RFC 4553 and other referenced >>> specifications. We felt references are better as it avoids duplication = of >>> text across documents, but I see your point. We will work through the >>> document and add a bit more text / context before calling out a RFC >>> reference. >>> >> > >>> >> > Here an example from the introduction section. Will do something >>> similar for other sections. >>> >> > >>> >> > before: >>> >> > >>> >> > The mechanisms described in this document follow principals simila= r >>> to [RFC4553] but expanding the applicability beyond the narrow set of P= DH >>> interfaces (T1, E1, T3 and E3) and allow the transport of signals from = many >>> different technologies such as Ethernet, Fibre Channel, SONET/SDH >>> [GR253]/[G.707] and OTN [G.709] at gigabit speeds by treating them as >>> bit-stream payload defined in sections 3.3.3 and 3.3.4 of [RFC3985]. >>> >> > >>> >> > >>> >> > after: >>> >> > >>> >> > The mechanisms described in this document follow principles simila= r >>> to Structure-Agnostic Time Division Multiplexing (TDM) over Packet (SAT= oP) >>> defined in [RFC4553]. The the applicability is expanded beyond the narr= ow >>> set of PDH interfaces (T1, E1, T3 and E3) to allow the transport of sig= nals >>> from many different technologies such as Ethernet, Fibre Channel, SONET= /SDH >>> [GR253]/[G.707] and OTN [G.709] at gigabit speeds. The signals are trea= ted >>> as bit-stream payload which was defined in the Pseudo Wire Emulation >>> Edge-to-Edge (PWE3) architecture in [RFC3985] sections 3.3.3 and 3.3.4. >>> >> > >>> >> > >>> >> > Where applicable we will remove the reference and just have >>> appropriate text. Once example >>> >> > >>> >> > before: >>> >> > >>> >> > Similar to [RFC4553] and [RFC5086] the term Interworking Function >>> (IWF) is used to describe the functional block that encapsulates bit >>> streams into PLE packets and in the reverse direction decapsulates PLE >>> packets and reconstructs bit streams. >>> >> > >>> >> > >>> >> > after: >>> >> > >>> >> > The term Interworking Function (IWF) is used to describe the >>> functional block that encapsulates bit streams into PLE packets and in = the >>> reverse direction decapsulates PLE packets and reconstructs bit streams= . >>> >> > >>> >> > >>> >> > >>> >> > Issues: >>> >> > - The target audience of the document should be clarified, >>> preferably >>> >> > in the abstract. On a related note, throughout the document it is = a >>> >> > bit difficult to distinguish between requirements defined for >>> >> > operators vs. requirements defined for implementers. Perhaps the >>> >> > authors could give some thought as to whether this issue can be >>> >> > mitigated. >>> >> > >>> >> > >>> >> > [cs] >>> >> > the target audience is implementers. We adjusted the abstract to >>> reflect that >>> >> > >>> >> > before: >>> >> > >>> >> > This document describes a method for encapsulating high-speed >>> bit-streams as virtual private wire services (VPWS) over packet switche= d >>> networks (PSN) providing complete signal transport transparency. >>> >> > >>> >> > >>> >> > after: >>> >> > >>> >> > This document describes methods and requirements for implementing >>> the encapsulation of high-speed bit-streams into virtual private wire >>> services (VPWS) over packet switched networks (PSN) providing complete >>> signal transport transparency. >>> >> > >>> >> > >>> >> > - The security considerations should be more detailed. The cited >>> >> > references are a good start, but the following issues should also = be >>> >> > discussed: >>> >> > >>> >> > - The requirement for synchronization is potentially a >>> >> > vulnerability. An on-path attacker may compromise the >>> synchronization, >>> >> > and thus compromise the service. You may want to take a look at RF= C >>> >> > 7384. >>> >> > >>> >> > - The requirements for low jitter, low loss and bandwidth >>> >> > reservation (section 8) are also potentially an attack vector. You >>> may >>> >> > take a look at RFC 9055 for example. >>> >> > >>> >> > >>> >> > [cs] >>> >> > We have added a couple of sentences to provide more details, plus >>> referred to respective RFCs for more information >>> >> > >>> >> > before: >>> >> > >>> >> > As PLE is leveraging VPWS as transport mechanism the security >>> considerations described in [RFC7432] and [RFC3985] are applicable. >>> >> > >>> >> > >>> >> > >>> >> > after: >>> >> > >>> >> > As PLE is leveraging VPWS as transport mechanism the security >>> considerations described in [RFC7432] and [RFC3985] are applicable. >>> >> > >>> >> > PLE does not enhance or detract from the security performance of >>> the underlying PSN. It relies upon the PSN mechanisms for encryption, >>> integrity, and authentication whenever required. >>> >> > >>> >> > A data plane attack may force PLE packets to be dropped, re-ordere= d >>> or delayed beyond the limit of the CE-bound IWF's dejitter buffer leadi= ng >>> to either degradation or service disruption. Considerations outlined in >>> [RFC9055] are a good reference. >>> >> > >>> >> > Clock synchronization leveraging PTP is sensitive to Packet Delay >>> Variation (PDV) and vulnerable to various threads and attacked vectors. >>> Considerations outlined in [RFC7384] should be taken into account. >>> >> > >>> >> > >>> >> > >>> >> > - The following two endpoint behaviors are defined in the IANA >>> >> > considerations section, but not defined anywhere in the document. >>> >> > These endpoint behaviors should either be removed or specified in >>> >> > detail: >>> >> > End.DX1 with NEXT-CSID >>> >> > End.DX1 with REPLACE-CSID >>> >> > >>> >> > >>> >> > [cs] >>> >> > Good point and I realised we have also forgotten to add the >>> required encaps description. We have reworded this section as follows (= in >>> markdown syntax) >>> >> > >>> >> > When a SRv6 PSN layer is used, a SRv6 service SID does provide the >>> demultiplexing mechanism and the mechanisms defined in {{?RFC8402}} and >>> {{?RFC9252}} section 6 do apply. Both SRv6 service SIDs with the full I= Pv6 >>> address format defined in {{?RFC8986}} and compressed SIDs (C-SIDs) wit= h >>> format defined in {{?I-D.draft-ietf-spring-srv6-srh-compression}} can b= e >>> used. >>> >> > >>> >> > Two new encapsulation behaviors H.Encaps.L1 and H.Encaps.L1.Red ar= e >>> defined in this document. The behavior procedures are applicable to bot= h >>> SIDs and C-SIDs. >>> >> > >>> >> > The H.Encaps.L1 behavior encapsulates a frame received from an IWF >>> in a IPv6 packet with an SRH. The received frame becomes the payload of= the >>> new IPv6 packet. >>> >> > >>> >> > * The next header field of the SRH MUST be set to TBA1. >>> >> > >>> >> > * The push of the SRH MAY be omitted when the SRv6 policy only >>> contains one segment. >>> >> > >>> >> > The H.Encaps.L1.Red behavior is an optimization of the H.Encaps.L1 >>> behavior. >>> >> > >>> >> > * H.Encaps.L1.Red reduces the length of the SRH by excluding the >>> first SID in the SRH of the pushed IPv6 header. The first SID is only >>> placed in the destination address field of the pushed IPv6 header. >>> >> > >>> >> > * The push of the SRH MAY be omitted when the SRv6 policy only >>> contains one segment. >>> >> > >>> >> > Three new "Endpoint with decapsulation and bit-stream >>> cross-connect" behaviors called End.DX1, End.DX1 with NEXT-CSID and End= .DX1 >>> with REPLACE-CSID are defined in this document. >>> >> > >>> >> > These new behaviors are variants of End.DX2 defined in >>> {{?RFC8986}}, End.DX2 with REPLACE-CSID defined in >>> {{?I-D.draft-ietf-spring-srv6-srh-compression}} and End.DX2 with NEXT-C= SID >>> defined in {{?I-D.draft-filsfils-spring-net-pgm-extension-srv6-usid}} a= nd >>> all have the following procedures in common >>> >> >> > --000000000000ebac77061bf6130f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">Christian,<div><br></div><div>Thanks! We'll get the pr= ocess going from here.</div><div><br></div><div>Cheers,</div><div>Andy</div= ><div><br></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class= =3D"gmail_attr">On Fri, Jun 28, 2024 at 11:26=E2=80=AFAM Christian Schmutze= r (cschmutz) <<a href=3D"mailto:[email protected]">[email protected]</= a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0p= x 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <div> Hi Andy, <div><br> </div> <div>Fyi I just uploaded a new version of the draft:</div> <div>- addressing Tal=E2=80=99s RtgDir review comments</div> <div>- checked all references against normative / informative</div> <div>- added missing terminology definitions</div> <div>- minor editorial changes as I saw fit</div> <div><br> </div> <div>regards</div> <div>Christian=C2=A0<br id=3D"m_-4562875861823260483lineBreakAtBeginningOfM= essage"> <div><br> <blockquote type=3D"cite"> <div>On 17.06.2024, at 14:33, Andrew G. Malis <<a href=3D"mailto:agmalis= @gmail.com" target=3D"_blank">[email protected]</a>> wrote:</div> <br> <div> <div dir=3D"ltr">Christian, <div><br> </div> <div>Thanks. I look forward to the next revision, after=C2=A0which we can s= tart getting ready for IESG submission.</div> <div><br> </div> <div>Cheers,</div> <div>Andy</div> <div><br> </div> </div> <br> <div class=3D"gmail_quote"> <div dir=3D"ltr" class=3D"gmail_attr">On Mon, Jun 17, 2024 at 1:13=E2=80=AF= AM Christian Schmutzer (cschmutz) <<a href=3D"mailto:[email protected]"= target=3D"_blank">[email protected]</a>> wrote:<br> </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>Hi Andy and Tal, <div><br> </div> <div>Works for me and agree on RFC8986 being normative. I will first descri= be the behaviours and only after that insert a note to the two informative = references that don=E2=80=99t really define anything with respect to PLE bu= t provide context which I thought may be useful.=C2=A0</div> <div><br> </div> <div>Christian<br id=3D"m_-4562875861823260483m_-5452698716363092946lineBre= akAtBeginningOfMessage"> <div><br> <blockquote type=3D"cite"> <div>On 16.06.2024, at 21:28, Andrew G. Malis <<a href=3D"mailto:agmalis= @gmail.com" target=3D"_blank">[email protected]</a>> wrote:</div> <br> <div> <div dir=3D"ltr">Tal, <div><br> </div> <div>That sounds good to me, thanks!</div> <div><br> </div> <div>Christian, how about you?</div> <div><br> </div> <div>Cheers,</div> <div>Andy</div> <div><br> </div> </div> <br> <div class=3D"gmail_quote"> <div dir=3D"ltr" class=3D"gmail_attr">On Sun, Jun 16, 2024 at 2:10=E2=80=AF= PM Tal Mizrahi <<a href=3D"mailto:[email protected]" target=3D"_= blank">[email protected]</a>> wrote:<br> </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"> Hi Andy,<br> <br> That is an interesting question.<br> The text that was suggested by Christian seemed to assume that the<br> reader is familiar with the previous endpoint behaviors (End.DX2,<br> End.DX2 with NEXT-CSID and End.DX2 with REPLACE-CSID).<br> Therefore, the text does not explain the meaning of the new endpoint<br> behaviors, because a reader who is familiar with the DX2 endpoint<br> behaviors would understand what the new DX1 behaviors do.<br> <br> A possible way around this is to add more detailed text to the current<br> document that explains for each of these new behaviors (End.DX1,<br> End.DX1 with NEXT-CSID and End.DX1 with REPLACE-CSID) what exactly it<br> means and the corresponding pseudo-code. The similarity to the DX2<br> behaviors could be mentioned as a side note, and thus the two drafts<br> (srh-compression and srv6-usid) could be informative references. I<br> believe RFC 8986 should probably be normative anyway.<br> <br> Please let me know if that makes sense.<br> Cheers,<br> Tal.<br> <br> On Sun, Jun 16, 2024 at 4:26=E2=80=AFPM Andrew G. Malis <<a href=3D"mail= to:[email protected]" target=3D"_blank">[email protected]</a>> wrote:<br= > ><br> > Tal,<br> ><br> > Thanks again for your review and also reviewing Christian's reply.= <br> ><br> > I'm concerned regarding your suggestion that draft-filsfils-spring= -net-pgm-extension-srv6-usid be made a normative reference, as it is only a= n individual draft right now and there's no guarantee that it'll ev= en become a WG draft, never mind an RFC, and making it a normative reference would hold up publishing this draft for quite a w= hile, unless we get special dispensation from the IESG. Do you see any way = we can get around making draft-filsfils normative?<br> ><br> > I'm much less concerned regarding draft-ietf-spring-srv6-srh-compr= ession, as that is currently in WG last call.<br> ><br> > Thanks again,<br> > Andy<br> ><br> ><br> > On Sun, Jun 16, 2024 at 1:12=E2=80=AFAM Tal Mizrahi <<a href=3D"mai= lto:[email protected]" target=3D"_blank">[email protected]<= /a>> wrote:<br> >><br> >> Hi Christian and authors,<br> >><br> >> Thanks for considering my comments.<br> >> The changes you suggested make sense to me.<br> >><br> >> Regarding the new endpoint behaviors, please note:<br> >> - The IANA section will need to be updated accordingly.<br> >> - You may need to move the references to normative: {{?RFC8986}},<= br> >> {{?I-D.draft-ietf-spring-srv6-srh-compression}},<br> >> {{?I-D.draft-filsfils-spring-net-pgm-extension-srv6-usid}}.<br> >> Specifically the last two, which may still be subject to changes.<= br> >><br> >> Cheers,<br> >> Tal.<br> >><br> >> On Sat, Jun 8, 2024 at 12:16=E2=80=AFPM Christian Schmutzer (cschm= utz)<br> >> <<a href=3D"mailto:[email protected]" target=3D"_blank">cschmu= [email protected]</a>> wrote:<br> >> ><br> >> > Hi Tal,<br> >> ><br> >> > Sorry for taking so long. Below our comments and proposal for= addressing your issues.<br> >> ><br> >> > Can you please let us know your thoughts. Upon your feedback = we will work towards uploading a new version addressing the issues.<br> >> ><br> >> > regards<br> >> > Christian<br> >> ><br> >> > On 15.05.2024, at 01:20, Tal Mizrahi <<a href=3D"mailto:ta= [email protected]" target=3D"_blank">[email protected]</a>>= ; wrote:<br> >> ><br> >> > Hello,<br> >> ><br> >> > I have been selected as the Routing Directorate reviewer for = this<br> >> > draft. The Routing Directorate seeks to review all routing or= <br> >> > routing-related drafts as they pass through IETF last call an= d IESG<br> >> > review, and sometimes on special request. The purpose of the = review is<br> >> > to provide assistance to the Routing ADs. For more informatio= n about<br> >> > the Routing Directorate, please see<br> >> > <a href=3D"https://wiki.ietf.org/en/group/rtg/RtgDir" rel=3D"= noreferrer" target=3D"_blank"> https://wiki.ietf.org/en/group/rtg/RtgDir</a><br> >> ><br> >> > Document: draft-ietf-pals-ple-04<br> >> > Reviewer: Tal Mizrahi<br> >> > Intended Status: Standards Track<br> >> ><br> >> > Summary:<br> >> > I have some concerns about this document that I think should = be<br> >> > resolved before publication.<br> >> ><br> >> > The draft is well-written and clear from a grammatical and st= ructural<br> >> > perspective. However, there is a very long list of normative<= br> >> > references that are cited in almost every paragraph of the do= cument,<br> >> > making it very difficult to follow for a reader who is somewh= at<br> >> > familiar with the area but is not an expert in the area.<br> >> ><br> >> ><br> >> > [cs]<br> >> > PLE has a lot of similarities with RFC 4553 and other referen= ced specifications. We felt references are better as it avoids duplication = of text across documents, but I see your point. We will work through the do= cument and add a bit more text / context before calling out a RFC reference.<br> >> ><br> >> > Here an example from the introduction section. Will do someth= ing similar for other sections.<br> >> ><br> >> > before:<br> >> ><br> >> > The mechanisms described in this document follow principals s= imilar to [RFC4553] but expanding the applicability beyond the narrow set o= f PDH interfaces (T1, E1, T3 and E3) and allow the transport of signals fro= m many different technologies such as Ethernet, Fibre Channel, SONET/SDH [GR253]/[G.707] and OTN [G.709] at gigabit speeds= by treating them as bit-stream payload defined in sections 3.3.3 and 3.3.4= of [RFC3985].<br> >> ><br> >> ><br> >> > after:<br> >> ><br> >> > The mechanisms described in this document follow principles s= imilar to Structure-Agnostic Time Division Multiplexing (TDM) over Packet (= SAToP) defined in [RFC4553]. The the applicability is expanded beyond the n= arrow set of PDH interfaces (T1, E1, T3 and E3) to allow the transport of signals from many different technologies suc= h as Ethernet, Fibre Channel, SONET/SDH [GR253]/[G.707] and OTN [G.709] at = gigabit speeds. The signals are treated as bit-stream payload which was def= ined in the Pseudo Wire Emulation Edge-to-Edge (PWE3) architecture in [RFC3985] sections 3.3.3 and 3.3.4.<br= > >> ><br> >> ><br> >> > Where applicable we will remove the reference and just have a= ppropriate text. Once example<br> >> ><br> >> > before:<br> >> ><br> >> > Similar to [RFC4553] and [RFC5086] the term Interworking Func= tion (IWF) is used to describe the functional block that encapsulates bit s= treams into PLE packets and in the reverse direction decapsulates PLE packe= ts and reconstructs bit streams.<br> >> ><br> >> ><br> >> > after:<br> >> ><br> >> > The term Interworking Function (IWF) is used to describe the = functional block that encapsulates bit streams into PLE packets and in the = reverse direction decapsulates PLE packets and reconstructs bit streams.<br= > >> ><br> >> ><br> >> ><br> >> > Issues:<br> >> > - The target audience of the document should be clarified, pr= eferably<br> >> > in the abstract. On a related note, throughout the document i= t is a<br> >> > bit difficult to distinguish between requirements defined for= <br> >> > operators vs. requirements defined for implementers. Perhaps = the<br> >> > authors could give some thought as to whether this issue can = be<br> >> > mitigated.<br> >> ><br> >> ><br> >> > [cs]<br> >> > the target audience is implementers. We adjusted the abstract= to reflect that<br> >> ><br> >> > before:<br> >> ><br> >> > This document describes a method for encapsulating high-speed= bit-streams as virtual private wire services (VPWS) over packet switched n= etworks (PSN) providing complete signal transport transparency.<br> >> ><br> >> ><br> >> > after:<br> >> ><br> >> > This document describes methods and requirements for implemen= ting the encapsulation of high-speed bit-streams into virtual private wire = services (VPWS) over packet switched networks (PSN) providing complete sign= al transport transparency.<br> >> ><br> >> ><br> >> > - The security considerations should be more detailed. The ci= ted<br> >> > references are a good start, but the following issues should = also be<br> >> > discussed:<br> >> ><br> >> >=C2=A0 - The requirement for synchronization is potentially a<= br> >> > vulnerability. An on-path attacker may compromise the synchro= nization,<br> >> > and thus compromise the service. You may want to take a look = at RFC<br> >> > 7384.<br> >> ><br> >> >=C2=A0 - The requirements for low jitter, low loss and bandwid= th<br> >> > reservation (section 8) are also potentially an attack vector= . You may<br> >> > take a look at RFC 9055 for example.<br> >> ><br> >> ><br> >> > [cs]<br> >> > We have added a couple of sentences to provide more details, = plus referred to respective RFCs for more information<br> >> ><br> >> > before:<br> >> ><br> >> > As PLE is leveraging VPWS as transport mechanism the security= considerations described in [RFC7432] and [RFC3985] are applicable.<br> >> ><br> >> ><br> >> ><br> >> > after:<br> >> ><br> >> > As PLE is leveraging VPWS as transport mechanism the security= considerations described in [RFC7432] and [RFC3985] are applicable.<br> >> ><br> >> > PLE does not enhance or detract from the security performance= of the underlying PSN. It relies upon the PSN mechanisms for encryption, i= ntegrity, and authentication whenever required.<br> >> ><br> >> > A data plane attack may force PLE packets to be dropped, re-o= rdered or delayed beyond the limit of the CE-bound IWF's dejitter buffe= r leading to either degradation or service disruption. Considerations outli= ned in [RFC9055] are a good reference.<br> >> ><br> >> > Clock synchronization leveraging PTP is sensitive to Packet D= elay Variation (PDV) and vulnerable to various threads and attacked vectors= . Considerations outlined in [RFC7384] should be taken into account.<br> >> ><br> >> ><br> >> ><br> >> > - The following two endpoint behaviors are defined in the IAN= A<br> >> > considerations section, but not defined anywhere in the docum= ent.<br> >> > These endpoint behaviors should either be removed or specifie= d in<br> >> > detail:<br> >> > End.DX1 with NEXT-CSID<br> >> > End.DX1 with REPLACE-CSID<br> >> ><br> >> ><br> >> > [cs]<br> >> > Good point and I realised we have also forgotten to add the r= equired encaps description. We have reworded this section as follows (in ma= rkdown syntax)<br> >> ><br> >> > When a SRv6 PSN layer is used, a SRv6 service SID does provid= e the demultiplexing mechanism and the mechanisms defined in {{?RFC8402}} a= nd {{?RFC9252}} section 6 do apply. Both SRv6 service SIDs with the full IP= v6 address format defined in {{?RFC8986}} and compressed SIDs (C-SIDs) with format defined in {{?I-D.draft-ietf-spri= ng-srv6-srh-compression}} can be used.<br> >> ><br> >> > Two new encapsulation behaviors H.Encaps.L1 and H.Encaps.L1.R= ed are defined in this document. The behavior procedures are applicable to = both SIDs and C-SIDs.<br> >> ><br> >> > The H.Encaps.L1 behavior encapsulates a frame received from a= n IWF in a IPv6 packet with an SRH. The received frame becomes the payload = of the new IPv6 packet.<br> >> ><br> >> > * The next header field of the SRH MUST be set to TBA1.<br> >> ><br> >> > * The push of the SRH MAY be omitted when the SRv6 policy onl= y contains one segment.<br> >> ><br> >> > The H.Encaps.L1.Red behavior is an optimization of the H.Enca= ps.L1 behavior.<br> >> ><br> >> > * H.Encaps.L1.Red reduces the length of the SRH by excluding = the first SID in the SRH of the pushed IPv6 header. The first SID is only p= laced in the destination address field of the pushed IPv6 header.<br> >> ><br> >> > * The push of the SRH MAY be omitted when the SRv6 policy onl= y contains one segment.<br> >> ><br> >> > Three new "Endpoint with decapsulation and bit-stream cr= oss-connect" behaviors called End.DX1, End.DX1 with NEXT-CSID and End.= DX1 with REPLACE-CSID are defined in this document.<br> >> ><br> >> > These new behaviors are variants of End.DX2 defined in {{?RFC= 8986}}, End.DX2 with REPLACE-CSID defined in {{?I-D.draft-ietf-spring-srv6-= srh-compression}} and End.DX2 with NEXT-CSID defined in {{?I-D.draft-filsfi= ls-spring-net-pgm-extension-srv6-usid}} and all have the following procedures in common<br> </blockquote> </div> </div> </blockquote> </div> <br> </div> </div> </blockquote> </div> </div> </blockquote> </div> <br> </div> </div> </blockquote></div> --000000000000ebac77061bf6130f-- --===============6427051354294055629== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KUGFscyBtYWls aW5nIGxpc3QgLS0gcGFsc0BpZXRmLm9yZwpUbyB1bnN1YnNjcmliZSBzZW5kIGFuIGVtYWlsIHRv IHBhbHMtbGVhdmVAaWV0Zi5vcmcK --===============6427051354294055629==--