I'm asking for the usage of the VENDOR_INFORMATION object to be allowed in the OPEN message (and not in notification, close and any other message where it is not already included). I would let the WG decide if it needs to be part of draft-ietf-pce-stateful-pce-vendor (case can be made to include it) or be discussed separately.
Regards, -Pavan On Wed, Aug 2, 2023 at 9:45 PM Dhruv Dhody <[email protected]> wrote: > Hi Pavan, > > In my personal opinion, the vendor TLV makes sense when the TLV is > associated with an existing PCEP Object (and it allows optional TLV) and > the vendor Object for something new! I would mostly consider anything sent > in Open message to be related to existing OPEN object :) > > Just to be clear, do you want this for OPEN message only or ALL PCEP > messages (that would additionally include notification and close message as > well)? If we go this route, we may need to change the name of the draft as > it is no longer just stateful! > > Thanks! > Dhruv (no hats) > > > > > > > On Wed, Aug 2, 2023 at 10:19 AM Vishnu Pavan Beeram <[email protected]> > wrote: > >> Please see inline.. >> >> On Wed, Aug 2, 2023 at 7:19 PM Dhruv Dhody <[email protected]> wrote: >> >>> Hi Pavan, >>> >>> On Wed, Aug 2, 2023 at 8:39 AM Vishnu Pavan Beeram < >>> [email protected]> wrote: >>> >>>> Marcel, Hi! >>>> Thanks for bringing this to the list! I interpret the text in RFC5440 >>>> regarding "one OPEN object" to just mean that the Open Message cannot carry >>>> more than one "OPEN" object. >>>> >>>> Dhruv, Hi! >>>> I would propose updating draft-ietf-pce-stateful-pce-vendor to >>>> explicitly allow the use of the "VENDOR-INFORMATION" object in the Open >>>> message. For example, implementations may choose to carry "versioning" >>>> information in this object during the Open message exchange (this >>>> information may or may not have any impact on the establishment of the PCEP >>>> session). As you mentioned, carrying the "VENDOR-INFORMATION" TLV in the >>>> Open Object is already allowed. I don't see any good reason to preclude the >>>> use of the "VENDOR-INFORMATION" object in the Open message. >>>> >>>> >>> Hmm, with that reasoning do we need to do that for all PCEP messages? >>> >> [VPB] It is hard to envision what proprietary use-case someone may come >> up with. But allowing the VENDOR-INFORMATION usage in Open message along >> with PCReq, PCReply, PCRpt, PCUpd and PCInitiate messages seems reasonable >> to me. >> >> Also, is there anything that cannot be achieved via the TLV, and you >>> would need the Object in the Open message case? Just wondering... >>> >> [VPB] You can achieve everything by using just the Object or just the TLV >> (this is true for other messages as well). I'm advocating a consistent >> semantic -- allow for the use of both VENDOR-INFORMATION object and TLV in >> all the aforementioned messages. >> >> >>> >>> Thanks! >>> Dhruv >>> >>> >>> >>> >>>> Regards, >>>> -Pavan >>>> >>>> On Wed, Aug 2, 2023 at 6:51 PM Dhruv Dhody <[email protected]> >>>> wrote: >>>> >>>>> Hi Marcel, >>>>> >>>>> Welcome, please consider joining the PCE mailing list so that we >>>>> don't have to manually approve your email to the list - >>>>> https://www.ietf.org/mailman/listinfo/pce >>>>> >>>>> See inline... >>>>> >>>>> On Wed, Aug 2, 2023 at 8:11 AM Marcel Reuter (External) < >>>>> [email protected]> wrote: >>>>> >>>>>> Aloha, >>>>>> >>>>>> dear colleagues! >>>>>> >>>>>> This is my very first E-mail ever to IETF. >>>>>> So please forgive me, if I dont follow all rules. >>>>>> >>>>>> I have a question about the RFC5440 >>>>>> Section 6-2 >>>>>> >>>>>> >>>>>> https://www.rfc-editor.org/rfc/rfc5440.html#section-6.2 >>>>>> >>>>>> The RFC says: >>>>>> >>>>>> 6.2. Open Message >>>>>> >>>>>> ... >>>>>> The format of an Open message is as follows: >>>>>> >>>>>> <Open Message>::= <Common Header> >>>>>> <OPEN> >>>>>> The Open message MUST contain exactly one OPEN object (see >>>>>> Section 7.3). >>>>>> >>>>>> >>>>>> Unfortunately, Im not very firm in BNF syntax >>>>>> My question here is to understand the last sentence. >>>>>> >>>>>> Is it allowed, just from a pure protocol standpoint, >>>>>> to send in the open message >>>>>> 1 (one) open object >>>>>> AND also >>>>>> 1(one) VENDOR-INFORMATION object with the P-flag not set? >>>>>> >>>>>> >>>>>> We are an operator and using PCE from one vendor and router from >>>>>> different other vendors and have currently some interesting discussing >>>>>> about that topic >>>>>> >>>>>> >>>>> RFC 7470 (https://datatracker.ietf.org/doc/rfc7470/) added a >>>>> VENDOR-INFORMATION Object for PCReq and PCRep messages! >>>>> https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-pce-vendor/ >>>>> addes the same for PCRpt and PCUpd messages! >>>>> >>>>> We have not specified the use of the Object within the Open message! >>>>> If there is a need to carry vendor specific information, then using >>>>> the VENDOR-INFORMATION-TLV within the Open object is allowed. >>>>> >>>>> In case they have a need for the object within the Open message, >>>>> please provide a usecase and perhaps it can be added in the draft! >>>>> >>>>> Hope this helps! >>>>> >>>>> Thanks! >>>>> Dhruv >>>>> >>>>> >>>>> >>>>>> >>>>>> Thanks a lot >>>>>> Marcel >>>>>> >>>>>> :-) >>>>>> >>>>>> >>>>>> VG >>>>>> Marcel Reuter >>>>>> >>>>>> -- >>>>>> Marcel Reuter >>>>>> Im Auftrag der Telefónica Germany GmbH & Co. OHG >>>>>> Überseering 33a >>>>>> 22297 Hamburg >>>>>> >>>>>> [email protected] >>>>>> >>>>>> ________________________________ >>>>>> >>>>>> Este mensaje y sus adjuntos se dirigen exclusivamente a su >>>>>> destinatario, puede contener información privilegiada o confidencial y es >>>>>> para uso exclusivo de la persona o entidad de destino. Si no es usted. el >>>>>> destinatario indicado, queda notificado de que la lectura, utilización, >>>>>> divulgación y/o copia sin autorización puede estar prohibida en virtud de >>>>>> la legislación vigente. Si ha recibido este mensaje por error, le rogamos >>>>>> que nos lo comunique inmediatamente por esta misma vía y proceda a su >>>>>> destrucción. >>>>>> >>>>>> The information contained in this transmission is confidential and >>>>>> privileged information intended only for the use of the individual or >>>>>> entity named above. If the reader of this message is not the intended >>>>>> recipient, you are hereby notified that any dissemination, distribution >>>>>> or >>>>>> copying of this communication is strictly prohibited. If you have >>>>>> received >>>>>> this transmission in error, do not read it. Please immediately reply to >>>>>> the >>>>>> sender that you have received this communication in error and then delete >>>>>> it. >>>>>> >>>>>> Esta mensagem e seus anexos se dirigem exclusivamente ao seu >>>>>> destinatário, pode conter informação privilegiada ou confidencial e é >>>>>> para >>>>>> uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o >>>>>> destinatário indicado, fica notificado de que a leitura, utilização, >>>>>> divulgação e/ou cópia sem autorização pode estar proibida em virtude da >>>>>> legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que >>>>>> nos >>>>>> o comunique imediatamente por esta mesma via e proceda a sua destruição >>>>>> >>>>>> _______________________________________________ >>>>>> Pce mailing list >>>>>> [email protected] >>>>>> https://www.ietf.org/mailman/listinfo/pce >>>>>> >>>>> _______________________________________________ >>>>> Pce mailing list >>>>> [email protected] >>>>> https://www.ietf.org/mailman/listinfo/pce >>>>> >>>> _______________________________________________ >>>> Pce mailing list >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/pce >>>> >>>
_______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
