[Pals] Re: RtgDir Last Call review: draft-ietf-pals-ple
"Andrew G. Malis" <[email protected]> Sun, 16 Jun 2024 15:28:11 -0400
| Newsgroups | gmane.ietf.pwe3 |
|---|---|
| Message-ID | <CAA=duU2D4=xVz7yTevn5Qff-PuQ3E3NRe0ha8amnUax15CLNdQ@mail.gmail.com> |
--===============0384810471540089323== Content-Type: multipart/alternative; boundary="000000000000685ee4061b06da25" --000000000000685ee4061b06da25 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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@gmail.= 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]= m> 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 makin= g > 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 w= ay > 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@gm= ail.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 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 IESG > >> > review, and sometimes on special request. The purpose of the review = is > >> > to provide assistance to the Routing ADs. For more information about > >> > 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 structura= l > >> > 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 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 similar > to [RFC4553] but expanding the applicability beyond the narrow set of PDH > interfaces (T1, E1, T3 and E3) and allow the transport of signals from ma= ny > 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 (SAToP= ) > defined in [RFC4553]. The the applicability is expanded beyond the narrow > set of PDH interfaces (T1, E1, T3 and E3) to allow the transport of signa= ls > from many different technologies such as Ethernet, Fibre Channel, SONET/S= DH > [GR253]/[G.707] and OTN [G.709] at gigabit speeds. The signals are treate= d > 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 th= e > reverse direction decapsulates PLE packets and reconstructs bit streams. > >> > > >> > > >> > > >> > Issues: > >> > - The target audience of the document should be clarified, preferabl= y > >> > 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 th= e > encapsulation of high-speed bit-streams into virtual private wire service= s > (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 synchronizatio= n, > >> > 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 m= ay > >> > 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-ordered > or delayed beyond the limit of the CE-bound IWF's dejitter buffer leading > 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 IPv= 6 > 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 i= n > 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-CSI= D > defined in {{?I-D.draft-filsfils-spring-net-pgm-extension-srv6-usid}} and > all have the following procedures in common > --000000000000685ee4061b06da25 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">Tal,<div><br></div><div>That sounds good to me, thanks!</d= iv><div><br></div><div>Christian, how about you?</div><div><br></div><div>C= heers,</div><div>Andy</div><div><br></div></div><br><div class=3D"gmail_quo= te"><div dir=3D"ltr" class=3D"gmail_attr">On Sun, Jun 16, 2024 at 2:10=E2= =80=AFPM Tal Mizrahi <<a href=3D"mailto:[email protected]">tal.m= [email protected]</a>> wrote:<br></div><blockquote class=3D"gmail_quo= te" 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 referenc= e would hold up publishing this draft for quite a while, unless we get spec= ial 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 [G= R253]/[G.707] and OTN [G.709] at gigabit speeds by treating them as bit-str= eam 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 s= ignals from many different technologies such as Ethernet, Fibre Channel, SO= NET/SDH [GR253]/[G.707] and OTN [G.709] at gigabit speeds. The signals are = treated as bit-stream payload which was defined in the Pseudo Wire Emulatio= n Edge-to-Edge (PWE3) architecture in [RFC3985] sections 3.3.3 and 3.3.4.<b= r> >> ><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-spring-srv6-srh-compression}} can be u= sed.<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 procedur= es in common<br> </blockquote></div> --000000000000685ee4061b06da25-- --===============0384810471540089323== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KUGFscyBtYWls aW5nIGxpc3QgLS0gcGFsc0BpZXRmLm9yZwpUbyB1bnN1YnNjcmliZSBzZW5kIGFuIGVtYWlsIHRv IHBhbHMtbGVhdmVAaWV0Zi5vcmcK --===============0384810471540089323==--