Hi Samuel, Noted!
One comment from my side -- PLease add some analysis in the security consideration, an empty security consideration is bound to raise eyebrows! Thanks! Dhruv On Fri, Jan 26, 2024 at 7:01 PM Samuel Sidor (ssidor) <ssi...@cisco.com> wrote: > Hi PCE-chairs, > > Since we haven't received any other comments for this draft, I would like > to ask for WGLC for this draft: > https://www.ietf.org/archive/id/draft-ietf-pce-sid-algo-07.html > > Thanks a lot, > Samuel > > -----Original Message----- > From: Samuel Sidor (ssidor) <ssidor=40cisco....@dmarc.ietf.org> > Sent: Monday, January 15, 2024 1:11 PM > To: Samuel Sidor (ssidor) <ssi...@cisco.com>; tom petch < > ie...@btconnect.com>; Dhruv Dhody <dhruv.i...@gmail.com> > Cc: pce@ietf.org > Subject: RE: [Pce] Any missed comments for draft-ietf-pce-sid-algo > > Just small update - 07 version submitted now. > > Regards, > Samuel > > -----Original Message----- > From: Pce <pce-boun...@ietf.org> On Behalf Of Samuel Sidor (ssidor) > Sent: Friday, January 12, 2024 1:43 PM > To: tom petch <ie...@btconnect.com>; Dhruv Dhody <dhruv.i...@gmail.com> > Cc: pce@ietf.org > Subject: Re: [Pce] Any missed comments for draft-ietf-pce-sid-algo > > Hi Tom, > > Attached updated document + diff. I'll submit it tomorrow in case of no > further comments. > > Regards, > Samuel > > -----Original Message----- > From: tom petch <ie...@btconnect.com> > Sent: Friday, January 12, 2024 12:33 PM > To: Samuel Sidor (ssidor) <ssi...@cisco.com>; Dhruv Dhody < > dhruv.i...@gmail.com> > Cc: pce@ietf.org > Subject: Re: [Pce] Any missed comments for draft-ietf-pce-sid-algo > > From: Samuel Sidor (ssidor) <ssi...@cisco.com> > Sent: 12 January 2024 10:53 > > Thanks Tom, > > I'll send updated draft in this mail thread soon. > > By the way - there is already big mess in naming of that algorithm across > multiple RFCs (I really don't want to cause headache to you 😊 ): > > <tp> > I know! That is why I was keen to get it right in PCE. Some WG are less > responsive than others to outside comments so I leave them to get into > whatever knots they want to:-( I see LSR as the owner of the algorithm > work, as least initially, so think that they should be followed. That > said, I think that RFC9350 culd have done more but that is water under the > bridge. Sometimes you have to say something along the lines of 'xxx whcih > is referred to as zxyx in the Normative reference' > > Tom Petch > > > IGP RFCs are talking about "SR-Algorithm" (as we already discussed in this > thread), e.g. > https://datatracker.ietf.org/doc/html/rfc8665#name-sr-algorithm-tlv > > SR policy architecture RFC is talking about "SR Algorithm": > https://datatracker.ietf.org/doc/html/rfc9256#name-segment-types > > SR architecture RFC is talking calling it "Prefix SID Algorithm": > https://datatracker.ietf.org/doc/html/rfc8402#section-3.1.1 > > And IANA registry is calling it "IGP Algorithm": > > https://www.iana.org/assignments/igp-parameters/igp-parameters.xhtml#igp-algorithm-types > > ...and they are all talking about same thing. > > I'll follow naming from IGP as we are relying a lot on those RFCs and we > are inheriting already defined Flex-algo behavior from those as well, but > it is hard to be correct now. I'll add pointers to SR policy architecture > and SR architecture RFCs as well. > > Regards, > Samuel > > -----Original Message----- > From: tom petch <ie...@btconnect.com> > Sent: Friday, January 12, 2024 11:10 AM > To: Samuel Sidor (ssidor) <ssi...@cisco.com>; Dhruv Dhody < > dhruv.i...@gmail.com> > Cc: pce@ietf.org > Subject: Re: [Pce] Any missed comments for draft-ietf-pce-sid-algo > > Samuel > > Yes the comments at the end work for me > > Tom Petch > > ________________________________________ > From: Samuel Sidor (ssidor) <ssi...@cisco.com> > Sent: 11 January 2024 12:50 > To: tom petch; Dhruv Dhody > Cc: pce@ietf.org > Subject: RE: [Pce] Any missed comments for draft-ietf-pce-sid-algo > > Hi Tom, > > Since you responded to both mails (from me and from Dhruv) together, I'll > respond here. > > Please see inline <S2>. > > Regards, > Samuel > > -----Original Message----- > From: tom petch <ie...@btconnect.com> > Sent: Thursday, January 11, 2024 1:25 PM > To: Dhruv Dhody <dhruv.i...@gmail.com> > Cc: Samuel Sidor (ssidor) <ssi...@cisco.com>; pce@ietf.org > Subject: Re: [Pce] Any missed comments for draft-ietf-pce-sid-algo > > inline <tp2> > > ________________________________________ > From: Dhruv Dhody <dhruv.i...@gmail.com> > Sent: 10 January 2024 13:06 > > Hi Tom, WG, > > Speaking as a WG member... > > On Wed, Jan 10, 2024 at 4:30 PM tom petch <ie...@btconnect.com<mailto: > ie...@btconnect.com>> wrote: > Sent: 10 January 2024 10:18 > > Hi PCE WG, > > I would like to ask for WG LC for draft-ietf-pce-sid-algo on behalf of > authors. Are there any remaining issues/comments/questions which I (or > co-authors) missed and which are not handled yet? > > URL: https://datatracker.ietf.org/doc/draft-ietf-pce-sid-algo/ > > <tp> > Well new to the PCE list may be I fear but I have a basic problem about > 'algorithm'. > > You reference RFC8665 and RFC 8667. In those it is always SR-Algorithm so > I think that that should be the spelling here. > > > Dhruv: The container is SR-ERO and SRv6-ERO where the field "Algorithm" is > being added. To me it is clear it is an SR-Algorithm. You will find the > similar usage in other RFC i.e.the TLV is called SR-Algorithm TLV but the > field inside is just Algorithm. > > <tp2> > You miss my point. in the two RFC it is always SR-Algorithm and never SR > Algorithm. The I-D has 53 or so uses of SR Algorithm. I think that they > all need changing to SR-Algorithm. This is not grammar; this is being > consistent in terminology across the IETF. > > <S2> Ack, in my previous mail I confirmed that I can change it. I'm for > consistency here as well (and especially since it does not cost us anything > now). > > More fundamentally, 8665 sets up an IANA registry with two values, 0 and > 1, which tells me that 8665 is out of date as soon as it is published and > that all references should be to IANA and not the RFC. The update policy > is Standards Action. ADs regard additions to IANA registries as not > updating the RFC creating the registry so reading 8665 will not tell you > that it is out of date unless you read between the lines of the IANA > Considerations and go see what is current. > > > Dhruv: It is usual for one to reference the RFC that created the registry, > it is evident there will be future RFCs or documents that add more > codepoints; the reference to the original RFC that created the registry is > still valid. I don't recall anyone asking to explicitly reference the > registry. That said, there is no harm in adding an additional reference to > IANA. > > <tp2> > Well I have been around long enough to see multiple IETF WG get into a > tangle over IANA registries and then spend a lot of effort trying to clear > the confusion. When this I-D is specifying the values that must appear in > a protocol field from an IANA registry, e.g. s.3.2, then the reference > must be to the IANA registry. The RFC setting up the registry will > likeleyo contain additional information about the values and their uses so > the RFC should be referenced, sometimes even after the RFC is obsoleted, > but not for the protocol field; that way brings trouble in the future from > those who are not thorough enough to spot the use of a IANA registry and > understand the implications therof. > > <S2> In my previous response, I confirmed that I should add explicit > reference to registry itself. I originally added reference to > RFC8665/RFC8667 as those are describing purpose and details of > SR-Algorithm, but I agree that finally any value from IANA registry can be > used in PCEP as well, so we need to reference registry itself as well. > > It gets more problematic. The IANA registry was updated by RFC9350 which > keeps the same update criteria but splits the range into two 0-127 and > 128-255, the latter being flexible. > > s.4.2.1 talks of Flexible Algorithm with a Normative reference to RFC9350 > which begs the question as to the relationship between SR Algorithm and > Flexible Algorithm when used in this document. Either/or, Synonyms? > > Here and now it may all be obvious but in years to come with multiple > algorithms in use it will likely be unclear what you are referencing in > s.3.2, s.3.3, s.3.4; is it the range 0-127 or 0-255 or 128-255 or...? > > > Dhruv: It is 0-255! Authors can make that explicit in the I-D. > <tp2> > Well yes and no. I think but am not sure that Flexible Algorithm is > values 128-255 and s.3.4 supports that view, at least implicitly. I think > that 4.2.1 should be explicit e.g. > 'When the value of fthe Algorithm is in the range 128-255, i.e. Flexible > Algorithm, ...' > > Tom Petch > </tp2> > <S2> This document is by default talking about complete SR-Algorithm > range. Only exception is s.4.2.1, which is specified to 128-255 and that is > already clarified in s.3.4 (which is explicitly excluding 0-127 and > explicitly pointing to s.4.2.1). I can still add explicit statement to the > beginning of s.4.2.1 to limit scope to Flexible Algorithms. > > To summarize - changes to be done to this draft: > - replace "SR algorithm" with "SR-Algorithm" > - add explicit reference to IANA registry on top of existing > references to RFCs, which are defining values in that registry > - add explicit statement to beginning of s.4.2.1 to clarify that > it is applicable to 128-255 range only > > Would that work for you? > > </S2> > > Thanks! > Dhruv > > > Tom Petch > > > > Thanks a lot, > Samuel > > _______________________________________________ > Pce mailing list > Pce@ietf.org<mailto:Pce@ietf.org> > https://www.ietf.org/mailman/listinfo/pce >
_______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
