Re: [Pce] WGLC for draft-ietf-pce-segment-routing-policy-cp-12
Hi Everyone, I read through the document and have the following comments. 1. In Abstract, there are three references (one [RFC9256 ], two [RFC8664]s). It seems better to remove these references by rephrasing. 2. It seems that an SR Policy has one identifier which consists of Headend, color and endpoint. * Should "SR Policy Identifiers uniquely identify the SR Policy within the network." in section 3.1 be changed to "An SR Policy Identifier uniquely identifies an SR Policy within the network. "? * Should "SR Policy Identifiers consist of:" in section 3.1 be changed to "An SR Policy Identifier consists of:"? * "Identifiers" in other sections may be changed accordingly. 1. It seems that an SR Policy Candidate Path has one Identifier, which consists of Protocol Origin, Originator and Discriminator. * Should "SR Policy Candidate Path Identifiers uniquely identify the SR Policy Candidate Path within the context of an SR Policy." in section 3.2 be changed to "An SR Policy Candidate Path Identifier uniquely identifies an SR Policy Candidate Path within the context of an SR Policy."? * Should "SR Policy Candidate Path Identifiers consist of:" be changed to "An SR Policy Candidate Path Identifiers consists of:"? * "Identifiers" in other sections (e.g., section 4.2.2) may be changed accordingly. 1. In the second sentence of section 5.4, "streering" seems a typo. Best Regards, Huaimo From: Pce On Behalf Of Dhruv Dhody Sent: Monday, January 8, 2024 5:29 AM To: pce@ietf.org Cc: pce-chairs ; draft-ietf-pce-segment-routing-policy...@ietf.org Subject: [Pce] WGLC for draft-ietf-pce-segment-routing-policy-cp-12 Hi WG, This email starts a 2-weeks working group last call for draft-ietf-pce-segment-routing-policy-cp-12. https://datatracker.ietf.org/doc/draft-ietf-pce-segment-routing-policy-cp/ Please indicate your support or concern for this draft. If you are opposed to the progression of the draft to RFC, please articulate your concern. If you support it, please indicate that you have read the latest version and it is ready for publication in your opinion. As always, review comments and nits are most welcome. The WG LC will end on Monday 22nd January 2024. A general reminder to the WG to be more vocal during the last-call/adoption. Thanks, Dhruv & Julien ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
[Pce] Early code point allocation for draft-ietf-pce-segment-routing-policy-cp-12
Hi WG, We have received a request from the authors of draft-ietf-pce-segment-routing-policy-cp for an early code point allocation for the codepoints listed in - https://www.ietf.org/archive/id/draft-ietf-pce-segment-routing-policy-cp-12.html#section-6.2 (TBD1-4) https://www.ietf.org/archive/id/draft-ietf-pce-segment-routing-policy-cp-12.html#section-6.3 (TBD6-8) https://www.ietf.org/archive/id/draft-ietf-pce-segment-routing-policy-cp-12.html#section-6.4 (TBD9) Note that there was an earlier allocation request where some codepoints were already allocated by IANA - https://mailarchive.ietf.org/arch/msg/pce/8GtjtxNWeA9MxpySx6J7XZKmlUc/ Note that the draft is also undergoing a parallel WGLC - https://mailarchive.ietf.org/arch/msg/pce/ert_k7k5iYq3LWbaTc-aMwRRAbs/ RFC 7120 requires one to meet the following criteria to proceed: b. The format, semantics, processing, and other rules related to handling the protocol entities defined by the code points (henceforth called "specifications") must be adequately described in an Internet-Draft. c. The specifications of these code points must be stable; i.e., if there is a change, implementations based on the earlier and later specifications must be seamlessly interoperable. If anyone believes that the draft does not meet these criteria or believes that early allocation is not appropriate for any other reason, please send an email to the PCE mailing list explaining why. If the chairs hear no objections by Wednesday, Jan 24th, we will kick off the early allocation request. Thanks! Dhruv & Julien ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] Any missed comments for draft-ietf-pce-sid-algo
Hi Tom, WG, Speaking as a WG member... On Wed, Jan 10, 2024 at 4:30 PM tom petch wrote: > From: Pce on behalf of Samuel Sidor (ssidor) > > 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/ > > > 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. > 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. > 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. Thanks! Dhruv > Tom Petch > > > > Thanks a lot, > Samuel > > ___ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] Any missed comments for draft-ietf-pce-sid-algo
Thanks a lot Tom for your comment.
Please see inline .
Regards,
Samuel
-Original Message-
From: Pce On Behalf Of tom petch
Sent: Wednesday, January 10, 2024 12:01 PM
To: Samuel Sidor (ssidor) ; pce@ietf.org
Subject: Re: [Pce] Any missed comments for draft-ietf-pce-sid-algo
From: Pce on behalf of Samuel Sidor (ssidor)
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/
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.
I'm calling it "SR Algorithm" in that draft, so I assume that you
are pointing to missing "-". Sure, I can modify it. Thanks for pointing it out.
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.
Sorry, maybe I missed your point, but do you mean that a lot of
other RFCs, e.g.
https://datatracker.ietf.org/doc/html/rfc5440#section-9.2
https://datatracker.ietf.org/doc/html/rfc9552#section-7.1.1
which are also pointing to itself, when new IANA registry is created are
incorrect? I interpret it only as specification of initial set of values, which
are supposed to be created in new registry and not complete list of values in
that registry, which will be created there in the future.
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.
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?
s.3.4 is describing F flag. If flag is set, valid values for
SR-Algorithm field in PCEP are 128-255, so those allocated for specific subset
of SR-Algorithm values called "Flexible Algorithms" and s.4.2.1 is applicable
only for such cases. That section may then refer to specific subset of values
("Flexible Algorithms") instead of referring to complete set.
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...?
In all other sections, we are talking about complete set of values
so "SR-Algorithm". I agree that it would be better that this document does not
have any reference to "IGP Algorithm":
https://www.iana.org/assignments/igp-parameters/igp-parameters.xhtml#igp-algorithm-types
I can add it for example to s.1 after references to RFC8665 and RF8667. Do you
have any other suggestion how to improve it?
Tom Petch
Thanks a lot,
Samuel
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] Any missed comments for draft-ietf-pce-sid-algo
From: Pce on behalf of Samuel Sidor (ssidor) 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/ 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. 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. 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...? Tom Petch Thanks a lot, Samuel ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
[Pce] Any missed comments for draft-ietf-pce-sid-algo
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/ Thanks a lot, Samuel ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] WGLC for draft-ietf-pce-segment-routing-policy-cp-12
Hi all, Thanks a lot, to authors for doing this work. It is really important for supporting SR policies in PCEP. I support progress of this document to RFC. A few minor comments: * For TLVs in association section, there is explicitly mentioned that those are “single instance” TLVs (single instance processed, other instances ignored), but I don’t see it mentioned for TLVs in Section 5. Are those “single instance” TLVs as well? * “SR Policy Capability TLV” is defining capabilities for TLVs/functionality in Section 5. It may be good to specify how those capabilities should be handled – e.g. if P flag (indicates support for “COMPUTATION-PRIORITY TLV”) is not set in “SR Policy Capability TLV”, but PCEP peer received that TLV. Is PCEP peer supposed to reject it or it is still acceptable to use it? If it should be rejected, what should be the PCError to reject it (unknown TLVs should be ignored by default)? * “SR Policy name” is defined as CP attribute in section “SR Policy Candidate Path Attributes”. Is there any reason for that? I would assume that it is policy attribute and not CP attribute. Can policy name be different for different candidate-path of same policy? * Terminology section is defining abbreviation “SRPA” for SR Policy Association, but “SR Policy Association (SRPA)” or “SR Policy Association”is then used in a few places in the document. It may be better to replace it. * “SR-POLICY-CAPABLITY” -> “SR-POLICY-CAPABILITY” in section 5.1 (typo) Thanks a lot, Samuel From: Pce On Behalf Of Dhruv Dhody Sent: Monday, January 8, 2024 11:29 AM To: pce@ietf.org Cc: pce-chairs ; draft-ietf-pce-segment-routing-policy...@ietf.org Subject: [Pce] WGLC for draft-ietf-pce-segment-routing-policy-cp-12 Hi WG, This email starts a 2-weeks working group last call for draft-ietf-pce-segment-routing-policy-cp-12. https://datatracker.ietf.org/doc/draft-ietf-pce-segment-routing-policy-cp/ Please indicate your support or concern for this draft. If you are opposed to the progression of the draft to RFC, please articulate your concern. If you support it, please indicate that you have read the latest version and it is ready for publication in your opinion. As always, review comments and nits are most welcome. The WG LC will end on Monday 22nd January 2024. A general reminder to the WG to be more vocal during the last-call/adoption. Thanks, Dhruv & Julien ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
