Hi Samuel, Thank you once again.
I thought mainly about its usage and optimization for a SR Policy case. Yes, may be we can start from small optimization step - use it for whole SR Policy Association instead of usage per Candidate Path, so map/link it to the Extend association ID for example. In regards to my 2nd concern, iI brought it because t was very painful experience when I had many issues and troubles with all the cases which you mentioned (experimental codepoints etc.) during the testing and developing an in-house PCE for multivendor environment. So I see that customer side picture very well. Thus if we can make even small optimization in the future version, it would be great and I support such approach. SY, Boris On Monday, July 15, 2024 at 04:45:57 PM GMT+3, Samuel Sidor (ssidor) <[email protected]> wrote: Hi Boris, We can discuss that optimization with other co-authors, but I personally don’t see good reason for doing it specifically for vendor information object. If that object is used for encoding operational state (like example with LSP statistics, which I mentioned in my last mail), then there is no way to optimize it as content of Vendor Information object is (or at least may be) different for each LSP. If it is used for constraints, optimization metric,…, then there is no difference, when compared with existing constraints, which are also repeated for every LSP (e.g. if I have 2k LSPs with same affinity, then PCC will encode same LSPA object 2k times – separately in each PCRpt). If size of encoded/repeated objects in PCEP message is really concern, then existing policy association (link) can be used to group LSPs together, encode association group only and translate it to configuration on other PCEP peer, but even that really makes sense if size of encoded Vendor Information object is higher than size of Association object itself. For your second concern – yes, that can happen, but same thing can happen even without having Vendor Info object. Anybody can use experimental range for PCEP objects or even completely non-standard codepoints and disable/enable advertisement of that object based on local configuration or based on some capability. Regards, Samuel From: Boris Hassanov <[email protected]> Sent: Saturday, July 13, 2024 8:07 AMTo: [email protected]; Dhruv Dhody <[email protected]>; Samuel Sidor (ssidor) <[email protected]>Cc: pce-chairs <[email protected]>; [email protected]: Re: [Pce] WGLC for draft-ietf-pce-stateful-pce-vendor-03 Hi Samuel, I got your points and clarifications. I would only think can we somehow optimize the quantity of Vendor Information Objects, to reduce the signaling overhead, may be use the same one for N LSPs etc.? Secondly, I just afraid "ships in the night" situation when we could have several parallel universes: one per each vendor in the network, where each vendor will encode as much info as he can into Vendor Information Object (because it is faster) and common PCEP with lack of additional info (so less optimal calculations for example). Thank you. SY, Boris On Monday, July 8, 2024 at 12:30:00 PM GMT+3, Samuel Sidor (ssidor) <[email protected]> wrote: Hi Boris,At least my understanding is that:1) As indicated later in that draft "Different instances of the object can have different Enterprise Numbers" - Enterprise ID can be different, but it can be same as well, so you can decide to include 2 vendor info objects with same Enterprise number if you want as well (e.g. if each of them represent some future standard object with not allocated codepoints and you want to simplify parsing). " if we have big/huge amount of LSPs in that PCRpt message, will we have Vendor Information Object per each object per each LSP?"Correct. Let's use one example - you want to report per LSP statistics in PCEP - since there is no standard object, you can encode it into vendor specific object. If there is 3rd party PCE, then it will just ignore it (because Enterprise ID is not matching). 2) Since format of vendor object/TLV used by each vendor is not published/standardized (this is answering you other question as well), then at least I'm really assuming that in vast majority of cases, vendor objects for multiple different vendors will not be advertised. E.g. Cisco PCC will use vendor info object with cisco enterprise number only. " https://www.rfc-editor.org/rfc/rfc7470.html#section-6.1"; is already even suggesting making advertisement of vendor object configurable, so it can be blocked if 3rd party PCE is used. See also https://www.ietf.org/archive/id/draft-ietf-pce-stateful-pce-vendor-03.html#section-4 - draft is already inheriting all manageability considerations from RFC7470.3) Enterprise numbers are not PCEP specific. See:https://www.iana.org/assignments/enterprise-numbers/Regards,Samuel -----Original Message-----From: Boris Hassanov <[email protected]> Sent: Sunday, July 7, 2024 4:24 PMTo: [email protected]; Dhruv Dhody <[email protected]>Cc: pce-chairs <[email protected]>; [email protected]: Re: [Pce] WGLC for draft-ietf-pce-stateful-pce-vendor-03Hi Dhruv and WG,I read the latest version of draft. Indeed It adds more flexibility to provide vendor-specific information for PCEs using different messages.I support the further work on this draft. But I would like to see the following clarifications:1) The draft says : "Multiple instances of the object MAY be used on a single PCRpt message.". Does it mean the addition of different Vendor Information objects (with different Enterprise numbers) per each PCEP object in PCRpt ? If I got it correct. if we have big/huge amount of LSPs in that PCRpt message, will we have Vendor Information Object per each object per each LSP?2) RFC 7470 has section 6.6 Impact on Network Operation which says: " On the other hand, the presence of additional vendor-specific information in PCEP messages may congest the operation of the protocol especially if the PCE does not support the information supplied by the PCC. ".I would like to see some analysis in the draft about potential impact of increasing the amount of Vendor Information objects on network operations too. IMO similar section as in RFC 7470 is needed.3) RFC 7470 also says: "Enterprise Numbers are assigned by IANA and managed through an IANA registry ". But they are absent so far (at least here: https://www.iana.org/assignments/pcep/pcep.xhtml ).How can customers which develop their own PCEs or open source PCEs can know the details of that vendor specific information into Vendor Information objects to consider that in their path calculation algos?Will vendors disclose it somehow as their good will or it will be just sort of black box approach?Thank you in advance.SY,BorisOn Thursday, July 4, 2024 at 04:18:29 PM GMT+3, Dhruv Dhody <[email protected]> wrote: Hi WG,This email starts a 2-weeks working group last call for draft-ietf-pce-stateful-pce-vendor-03.https://www.ietf.org/archive/id/draft-ietf-pce-stateful-pce-vendor-03.htmlPlease 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 Thursday 18 July 2024.A general reminder to the WG to be more vocal during the last-call/adoption.Thanks,Dhruv & Julien_______________________________________________Pce mailing list -- [email protected] unsubscribe send an email to [email protected] _______________________________________________ Pce mailing list -- [email protected] To unsubscribe send an email to [email protected] _______________________________________________ Pce mailing list -- [email protected] To unsubscribe send an email to [email protected]
