[Pals] Re: RtgDir Last Call review: draft-ietf-pals-ple
"Andrew G. Malis" <[email protected]> Mon, 17 Jun 2024 08:33:01 -0400
| Newsgroups | gmane.ietf.pwe3 |
|---|---|
| Message-ID | <CAA=duU2Bpha6QuC3qL=rUtkjG4jDGy0xpC30R-MJCEijZRFAgg@mail.gmail.com> |
--===============6516151342361155871== Content-Type: multipart/alternative; boundary="000000000000864ab4061b152bfe" --000000000000864ab4061b152bfe Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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@gmai= l.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 <[email protected]= om> >> 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 maki= ng >> 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@g= mail.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 (cschmutz= ) >> >> <[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 wil= l >> 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 IESG >> >> > review, and sometimes on special request. The purpose of the review >> is >> >> > to provide assistance to the Routing ADs. For more information abou= t >> >> > 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 structur= al >> >> > perspective. However, there is a very long list of normative >> >> > references that are cited in almost every paragraph of the document= , >> >> > 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 o= f >> 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 similar >> to [RFC4553] but expanding the applicability beyond the narrow set of PD= H >> interfaces (T1, E1, T3 and E3) and allow the transport of signals from m= any >> 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 similar >> to Structure-Agnostic Time Division Multiplexing (TDM) over Packet (SATo= P) >> defined in [RFC4553]. The the applicability is expanded beyond the narro= w >> set of PDH interfaces (T1, E1, T3 and E3) to allow the transport of sign= als >> from many different technologies such as Ethernet, Fibre Channel, SONET/= SDH >> [GR253]/[G.707] and OTN [G.709] at gigabit speeds. The signals are treat= ed >> 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 t= he >> reverse direction decapsulates PLE packets and reconstructs bit streams. >> >> > >> >> > >> >> > >> >> > Issues: >> >> > - The target audience of the document should be clarified, preferab= ly >> >> > 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 switched >> 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 b= e >> >> > 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 RFC >> >> > 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 th= e >> 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-ordered >> or delayed beyond the limit of the CE-bound IWF's dejitter buffer leadin= g >> 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 require= d >> encaps description. We have reworded this section as follows (in markdow= n >> 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 IP= v6 >> address format defined in {{?RFC8986}} and compressed SIDs (C-SIDs) with >> format defined in {{?I-D.draft-ietf-spring-srv6-srh-compression}} can be >> used. >> >> > >> >> > Two new encapsulation behaviors H.Encaps.L1 and H.Encaps.L1.Red are >> defined in this document. The behavior procedures are applicable to both >> 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-CS= ID >> defined in {{?I-D.draft-filsfils-spring-net-pgm-extension-srv6-usid}} an= d >> all have the following procedures in common >> > > --000000000000864ab4061b152bfe Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">Christian,<div><br></div><div>Thanks. I look forward to th= e next revision, after=C2=A0which we can start getting ready for IESG submi= ssion.</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=AFAM Christian Schmutzer (cschmutz) <= <a href=3D"mailto:[email protected]">[email protected]</a>> wrote:<br>= </div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;b= order-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_-5452698716363092946lineBreakAtBeginningOfMessage= "> <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> --000000000000864ab4061b152bfe-- --===============6516151342361155871== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KUGFscyBtYWls aW5nIGxpc3QgLS0gcGFsc0BpZXRmLm9yZwpUbyB1bnN1YnNjcmliZSBzZW5kIGFuIGVtYWlsIHRv IHBhbHMtbGVhdmVAaWV0Zi5vcmcK --===============6516151342361155871==--