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
--- Begin Message ---Internet-Draft draft-ietf-pce-sid-algo-07.txt is now available. It is a work item of the Path Computation Element (PCE) WG of the IETF. Title: Carrying SR-Algorithm information in PCE-based Networks. Authors: Samuel Sidor Alex Tokar Shaofu Peng Shuping Peng Andrew Stone Name: draft-ietf-pce-sid-algo-07.txt Pages: 18 Dates: 2024-01-15 Abstract: The SR-Algorithm associated with a Prefix Segment-ID (SID) defines the path computation algorithm used by Interior Gateway Protocols (IGPs). This information is available to controllers such as the Path Computation Element (PCE) via topology learning. This document proposes an approach for informing headend routers regarding the SR- Algorithm associated with each Prefix SID used in PCE-computed paths, as well as signalling a specific SR-Algorithm as a constraint to the PCE. The IETF datatracker status page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-sid-algo/ There is also an HTMLized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-pce-sid-algo-07 A diff from the previous version is available at: https://author-tools.ietf.org/iddiff?url2=draft-ietf-pce-sid-algo-07 Internet-Drafts are also available by rsync at: rsync.ietf.org::internet-drafts _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
--- End Message ---
_______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
