Yeah Samuel,
The early names in PCEP did not foresee any future metrics that would need disambiguation. So the names are not very good. That’s a shame. But we don’t need to repeat the mistake :-) Think about it a bit, and pick the names you think are right. A From: Samuel Sidor (ssidor) <ssi...@cisco.com> Sent: 24 June 2024 09:12 To: adr...@olddog.co.uk; 'Dhruv Dhody' <d...@dhruvdhody.com>; pce@ietf.org Cc: 'pce-chairs' <pce-cha...@ietf.org>; draft-ietf-pce-sid-a...@ietf.org Subject: RE: [Pce] Early code point allocation for draft-ietf-pce-sid-algo-10 Hi Adrian, I’m fine with renaming it, but in general, I don’t see same naming convention being followed often in PCEP. See for example – IGP or TE metric in PCEP – those would be also called as “Summed Path IGP metric” or “Summed Path TE metric” if we want to follow same convention. Same thing for “Worst Leaf Summed …” – see for example “P2MP Path Delay metric”: https://www.rfc-editor.org/rfc/rfc8233.html#section-3.1.6.1 It is also computed as worst leaf cumulative cost of all paths, but such naming convention was not used. What about just adding word “Path” into Bandwidth metric name, so it is clear that it is not link BW metric? So instead of currently used “Bandwidth Metric”, it would be “Path Bandwidth Metric”? That way name will be aligned with existing naming conventions in PCEP and name will be also indicating that it is not link BW. (but I’m fine even with your proposal if you still prefer to explicitly indicate way to compute that metric in the name, maybe with just small modification and replacing “Summed” with “Cumulative”). Thanks, Samuel From: Adrian Farrel <adr...@olddog.co.uk <mailto:adr...@olddog.co.uk> > Sent: Saturday, June 22, 2024 1:29 PM To: 'Dhruv Dhody' <d...@dhruvdhody.com <mailto:d...@dhruvdhody.com> >; pce@ietf.org <mailto:pce@ietf.org> Cc: 'pce-chairs' <pce-cha...@ietf.org <mailto:pce-cha...@ietf.org> >; draft-ietf-pce-sid-a...@ietf.org <mailto:draft-ietf-pce-sid-a...@ietf.org> Subject: RE: [Pce] Early code point allocation for draft-ietf-pce-sid-algo-10 Although, I might be slightly wrong about the second metric because it is even more than that. Perhaps “Worst Leaf Summed Path Bandwidth”? A From: Adrian Farrel <adr...@olddog.co.uk <mailto:adr...@olddog.co.uk> > Sent: 22 June 2024 12:13 To: 'Dhruv Dhody' <d...@dhruvdhody.com <mailto:d...@dhruvdhody.com> >; 'pce@ietf.org' <pce@ietf.org <mailto:pce@ietf.org> > Cc: 'pce-chairs' <pce-cha...@ietf.org <mailto:pce-cha...@ietf.org> >; 'draft-ietf-pce-sid-a...@ietf.org' <draft-ietf-pce-sid-a...@ietf.org <mailto:draft-ietf-pce-sid-a...@ietf.org> > Subject: RE: [Pce] Early code point allocation for draft-ietf-pce-sid-algo-10 No objection, Dhruv, although it might be helpful to distinguish between the Bandwidth metric advertised per link and the new PCEP metric type. Perhaps call the new metrics “Summed Path Bandwidth” and “Summed P2PM Path Bandwidth” because it is more descriptive? Cheers, Adrian From: Dhruv Dhody <d...@dhruvdhody.com <mailto:d...@dhruvdhody.com> > Sent: 22 June 2024 09:41 To: pce@ietf.org <mailto:pce@ietf.org> Cc: pce-chairs <pce-cha...@ietf.org <mailto:pce-cha...@ietf.org> >; draft-ietf-pce-sid-a...@ietf.org <mailto:draft-ietf-pce-sid-a...@ietf.org> Subject: [Pce] Early code point allocation for draft-ietf-pce-sid-algo-10 Hi WG, We have received a request from the authors of draft-ietf-pce-sid-algo for an early code point allocation for the codepoints listed in - https://www.ietf.org/archive/id/draft-ietf-pce-sid-algo-10.html#table-7 These are the codepoints for the latest changes made to align with draft-ietf-lsr-flex-algo-bw-con as per - https://mailarchive.ietf.org/arch/msg/pce/U2AIec7Vk9LomZM-LlvhxGywQgA/ The chairs would like to know if there are any objections to adding these new metric types and keeping a range aside for user defined metrics. Further, 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 Monday, July 8th, we will kick off the early allocation request. Note that there was an earlier allocation request where some codepoints were already allocated by IANA - https://mailarchive.ietf.org/arch/msg/pce/8jv4slxI_K3p4qqUPRlAjSgScOA/ Thanks! Dhruv & Julien
_______________________________________________ Pce mailing list -- pce@ietf.org To unsubscribe send an email to pce-le...@ietf.org
