Re: [Pce] Mail regarding draft-ietf-pce-pcep

[Vishnu Pavan Beeram <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]>
> wrote:
>
>> Please see inline..
>>
>> On Wed, Aug 2, 2023 at 7:19 PM Dhruv Dhody <[e-mail]> wrote:
>>
>>> Hi Pavan,
>>>
>>> On Wed, Aug 2, 2023 at 8:39 AM Vishnu Pavan Beeram <
>>> [e-mail]> 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 <[e-mail]>
>>>> 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) <
>>>>> [e-mail]> 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
>>>>>>
>>>>>> [e-mail]
>>>>>>
>>>>>> ________________________________
>>>>>>
>>>>>> 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
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/pce
>>>>>>
>>>>> _______________________________________________
>>>>> Pce mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/pce
>>>>>
>>>> _______________________________________________
>>>> Pce mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/pce
>>>>
>>>