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 PM
To: [email protected]; Dhruv Dhody <[email protected]>
Cc: pce-chairs <[email protected]>;
[email protected]
Subject: Re: [Pce] WGLC for draft-ietf-pce-stateful-pce-vendor-03
Hi 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,
Boris
On 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]
To unsubscribe send an email to [email protected]
_______________________________________________
Pce mailing list -- [email protected]
To unsubscribe send an email to [email protected]
