Re: [Pce] Mail regarding draft-ietf-pce-pcep
Hi Samuel! Many thanks for your detailed answer! Many thanks to Dhruv and Pavan for all input and discussion. From: Samuel Sidor (ssidor) Date: Thursday, 3. August 2023 at 19:30 To: Vishnu Pavan Beeram Cc: Dhruv Dhody , Dhruv Dhody , Marcel Reuter (External) , pce@ietf.org , draft-ietf-pce-stateful-pce-ven...@ietf.org Subject: RE: [Pce] Mail regarding draft-ietf-pce-pcep Hi Pavan, Please see inline . Regards, Samuel From: Vishnu Pavan Beeram Sent: Thursday, August 3, 2023 4:40 PM To: Samuel Sidor (ssidor) Cc: Dhruv Dhody ; Dhruv Dhody ; Marcel Reuter (External) ; pce@ietf.org; draft-ietf-pce-stateful-pce-ven...@ietf.org Subject: Re: [Pce] Mail regarding draft-ietf-pce-pcep Samuel, Hi! The requirement is to be able to carry "vendor specific information" in the OPEN message. Some of this information may be relevant for deciding whether the session should be established or not while some other information may become relevant only later when processing LSPs (and has no bearing on "opening" the session). An implementation should be able to use the VENDOR_INFO TLV in the OPEN object for the former and the VENDOR_INFO Object (marked optional like in any other message) for the latter. I don't understand why this usage/flexibility needs to be prohibited. I don’t think it was explicitly prohibited for vendor info object. It is inheriting default rules, which are applied for all PCEP objects. RC5440 clearly stated that content of PCEP message is described in BNF – so all mandatory and optional objects, which can be included are explicitly listed. Each RFC, which is defining new PCEP object is explicitly specifying where that PCEP object can be included (PCEP message, ordering,…). I assume that when RFC7470 introduced vendor info object, there was no valid use-case for including that PCEP object in Open message, so it was not explicitly added – same way like it was not added to other PCEP messages. If we want to allow it now, then logical questions are: * What has changed since RFC7470? Is there really new use-case which cannot be covered with existing vendor TLV? If we will allow use only in Open message, how we will make sure that in 5 months somebody else will not need it in any other PCEP message? * How to handle backward compatibility? E.g. what will happen if you will start including Vendor Info object in Open message, but existing implementations, which are complaint with all existing RFCs will reject those Open messages (you need to consider those with support for RFC7470, but also those without support)? If extension required is for other PCEP messages, then you we can have capability advertised in Open message to figure out, whether extension is supported, but since you need to extend PCEP Open message, you don’t have simple way to figure it out. * Where such extension should be included? As Dhruv mentioned, logically it does not belong into stateful vendor info draft, so we have 2 options: * New draft * Re-working stateful draft to include this change, rename it,… That said, if the WG concludes that the "vendor specific information" should ONLY exist in TLV form in the OPEN message, I would like it to be explicitly specified somewhere. As described above – for PCEP objects, it is always explicitly specified which PCEP object is allowed in which PCEP message. For TLV, RFC7470 is already saying: https://www.rfc-editor.org/rfc/rfc7470.html#section-1 This document also defines a new PCEP TLV, the VENDOR-INFORMATION-TLV that can be used to carry arbitrary information within any existing or future PCEP object that supports TLVs. … - Clarification that the TLV is available for use in any PCEP object (existing or future) that supports TLVs. But maybe other WG members knows about some other statements, which can still block it for Open message. Regards, -Pavan On Thu, Aug 3, 2023 at 1:45 PM Samuel Sidor (ssidor) mailto:ssi...@cisco.com>> wrote: Hi Pavan, Is it possible to specify usecase a bit? I’m not against allowing Vendor Info object in OPEN message, but I personally tend to agree with Dhruv’s explanation. In general, PCEP open message is supposed to exchange/negotiate various capabilities of PCEP peers, timer values, path-setup-types,… but all of them seems to be related to Open object, so vendor TLV seems to be sufficient for something like that. In general, I can see benefit in using PCEP object over PCEP TLV (on top of logical association with underlaying object) in already defined flags in object header (P/I flags), which can help if you want to mark that object as mandatory/optional while TLV is always optional and can be ignored during parsing. In case of Vendor Info object, I don’t see good reason to mark it as mandatory, so flags are not adding any extra value. If you will mark vendor object as mandatory, then you will restrict processi
Re: [Pce] Mail regarding draft-ietf-pce-pcep
Hi Marcel, Thanks for the discussion. It seems that we do not need to update the draft-ietf-pce-stateful-pce-vendor if I do not understand wrongly. If you have any thoughts, please feel free to share further. Thanks, Li Cheng From: Marcel Reuter (External) Sent: Friday, August 4, 2023 4:03 PM To: Samuel Sidor (ssidor) ; Vishnu Pavan Beeram Cc: Dhruv Dhody ; Dhruv Dhody ; pce@ietf.org; draft-ietf-pce-stateful-pce-ven...@ietf.org Subject: Re: [Pce] Mail regarding draft-ietf-pce-pcep Hi Samuel! Many thanks for your detailed answer! Many thanks to Dhruv and Pavan for all input and discussion. From: Samuel Sidor (ssidor) mailto:ssi...@cisco.com>> Date: Thursday, 3. August 2023 at 19:30 To: Vishnu Pavan Beeram mailto:vishnupa...@gmail.com>> Cc: Dhruv Dhody mailto:d...@dhruvdhody.com>>, Dhruv Dhody mailto:dhruv.i...@gmail.com>>, Marcel Reuter (External) mailto:marcel.reuter.exter...@telefonica.com>>, pce@ietf.org<mailto:pce@ietf.org> mailto:pce@ietf.org>>, draft-ietf-pce-stateful-pce-ven...@ietf.org<mailto:draft-ietf-pce-stateful-pce-ven...@ietf.org> mailto:draft-ietf-pce-stateful-pce-ven...@ietf.org>> Subject: RE: [Pce] Mail regarding draft-ietf-pce-pcep Hi Pavan, Please see inline . Regards, Samuel From: Vishnu Pavan Beeram mailto:vishnupa...@gmail.com>> Sent: Thursday, August 3, 2023 4:40 PM To: Samuel Sidor (ssidor) mailto:ssi...@cisco.com>> Cc: Dhruv Dhody mailto:d...@dhruvdhody.com>>; Dhruv Dhody mailto:dhruv.i...@gmail.com>>; Marcel Reuter (External) mailto:marcel.reuter.exter...@telefonica.com>>; pce@ietf.org<mailto:pce@ietf.org>; draft-ietf-pce-stateful-pce-ven...@ietf.org<mailto:draft-ietf-pce-stateful-pce-ven...@ietf.org> Subject: Re: [Pce] Mail regarding draft-ietf-pce-pcep Samuel, Hi! The requirement is to be able to carry "vendor specific information" in the OPEN message. Some of this information may be relevant for deciding whether the session should be established or not while some other information may become relevant only later when processing LSPs (and has no bearing on "opening" the session). An implementation should be able to use the VENDOR_INFO TLV in the OPEN object for the former and the VENDOR_INFO Object (marked optional like in any other message) for the latter. I don't understand why this usage/flexibility needs to be prohibited. I don’t think it was explicitly prohibited for vendor info object. It is inheriting default rules, which are applied for all PCEP objects. RC5440 clearly stated that content of PCEP message is described in BNF – so all mandatory and optional objects, which can be included are explicitly listed. Each RFC, which is defining new PCEP object is explicitly specifying where that PCEP object can be included (PCEP message, ordering,…). I assume that when RFC7470 introduced vendor info object, there was no valid use-case for including that PCEP object in Open message, so it was not explicitly added – same way like it was not added to other PCEP messages. If we want to allow it now, then logical questions are: * What has changed since RFC7470? Is there really new use-case which cannot be covered with existing vendor TLV? If we will allow use only in Open message, how we will make sure that in 5 months somebody else will not need it in any other PCEP message? * How to handle backward compatibility? E.g. what will happen if you will start including Vendor Info object in Open message, but existing implementations, which are complaint with all existing RFCs will reject those Open messages (you need to consider those with support for RFC7470, but also those without support)? If extension required is for other PCEP messages, then you we can have capability advertised in Open message to figure out, whether extension is supported, but since you need to extend PCEP Open message, you don’t have simple way to figure it out. * Where such extension should be included? As Dhruv mentioned, logically it does not belong into stateful vendor info draft, so we have 2 options: * New draft * Re-working stateful draft to include this change, rename it,… That said, if the WG concludes that the "vendor specific information" should ONLY exist in TLV form in the OPEN message, I would like it to be explicitly specified somewhere. As described above – for PCEP objects, it is always explicitly specified which PCEP object is allowed in which PCEP message. For TLV, RFC7470 is already saying: https://www.rfc-editor.org/rfc/rfc7470.html#section-1 This document also defines a new PCEP TLV, the VENDOR-INFORMATION-TLV that can be used to carry arbitrary information within any existing or future PCEP object that supports TLVs. … - Clarification that the TLV is available for use in any PCEP object (existing or future) that supports TLVs. But maybe other W
Re: [Pce] Mail regarding draft-ietf-pce-pcep
Hi Pavan, Ack, that is my interpretation as well – it should be possible to use TLV in OPEN object. Regards, Samuel From: Vishnu Pavan Beeram Sent: Thursday, August 3, 2023 7:48 PM To: Samuel Sidor (ssidor) Cc: Dhruv Dhody ; Dhruv Dhody ; Marcel Reuter (External) ; pce@ietf.org; draft-ietf-pce-stateful-pce-ven...@ietf.org Subject: Re: [Pce] Mail regarding draft-ietf-pce-pcep If we can conclude that the use of the VENDOR-INFORMATION-TLV in OPEN object is not precluded by any of the existing documents (and that seems to be what Dhruv is saying as well), that is good enough for me. Regards, -Pavan On Thu, Aug 3, 2023 at 10:04 PM Samuel Sidor (ssidor) mailto:ssi...@cisco.com>> wrote: Hi Pavan, Please see inline . Regards, Samuel From: Vishnu Pavan Beeram mailto:vishnupa...@gmail.com>> Sent: Thursday, August 3, 2023 4:40 PM To: Samuel Sidor (ssidor) mailto:ssi...@cisco.com>> Cc: Dhruv Dhody mailto:d...@dhruvdhody.com>>; Dhruv Dhody mailto:dhruv.i...@gmail.com>>; Marcel Reuter (External) mailto:marcel.reuter.exter...@telefonica.com>>; pce@ietf.org<mailto:pce@ietf.org>; draft-ietf-pce-stateful-pce-ven...@ietf.org<mailto:draft-ietf-pce-stateful-pce-ven...@ietf.org> Subject: Re: [Pce] Mail regarding draft-ietf-pce-pcep Samuel, Hi! The requirement is to be able to carry "vendor specific information" in the OPEN message. Some of this information may be relevant for deciding whether the session should be established or not while some other information may become relevant only later when processing LSPs (and has no bearing on "opening" the session). An implementation should be able to use the VENDOR_INFO TLV in the OPEN object for the former and the VENDOR_INFO Object (marked optional like in any other message) for the latter. I don't understand why this usage/flexibility needs to be prohibited. I don’t think it was explicitly prohibited for vendor info object. It is inheriting default rules, which are applied for all PCEP objects. RC5440 clearly stated that content of PCEP message is described in BNF – so all mandatory and optional objects, which can be included are explicitly listed. Each RFC, which is defining new PCEP object is explicitly specifying where that PCEP object can be included (PCEP message, ordering,…). I assume that when RFC7470 introduced vendor info object, there was no valid use-case for including that PCEP object in Open message, so it was not explicitly added – same way like it was not added to other PCEP messages. If we want to allow it now, then logical questions are: * What has changed since RFC7470? Is there really new use-case which cannot be covered with existing vendor TLV? If we will allow use only in Open message, how we will make sure that in 5 months somebody else will not need it in any other PCEP message? * How to handle backward compatibility? E.g. what will happen if you will start including Vendor Info object in Open message, but existing implementations, which are complaint with all existing RFCs will reject those Open messages (you need to consider those with support for RFC7470, but also those without support)? If extension required is for other PCEP messages, then you we can have capability advertised in Open message to figure out, whether extension is supported, but since you need to extend PCEP Open message, you don’t have simple way to figure it out. * Where such extension should be included? As Dhruv mentioned, logically it does not belong into stateful vendor info draft, so we have 2 options: * New draft * Re-working stateful draft to include this change, rename it,… That said, if the WG concludes that the "vendor specific information" should ONLY exist in TLV form in the OPEN message, I would like it to be explicitly specified somewhere. As described above – for PCEP objects, it is always explicitly specified which PCEP object is allowed in which PCEP message. For TLV, RFC7470 is already saying: https://www.rfc-editor.org/rfc/rfc7470.html#section-1 This document also defines a new PCEP TLV, the VENDOR-INFORMATION-TLV that can be used to carry arbitrary information within any existing or future PCEP object that supports TLVs. … - Clarification that the TLV is available for use in any PCEP object (existing or future) that supports TLVs. But maybe other WG members knows about some other statements, which can still block it for Open message. Regards, -Pavan On Thu, Aug 3, 2023 at 1:45 PM Samuel Sidor (ssidor) mailto:ssi...@cisco.com>> wrote: Hi Pavan, Is it possible to specify usecase a bit? I’m not against allowing Vendor Info object in OPEN message, but I personally tend to agree with Dhruv’s explanation. In general, PCEP open message is supposed to exchange/negotiate various capabilities of PCEP peers, timer values, path-setup-types,… but all of them seems to be r
Re: [Pce] Mail regarding draft-ietf-pce-pcep
If we can conclude that the use of the VENDOR-INFORMATION-TLV in OPEN object is not precluded by any of the existing documents (and that seems to be what Dhruv is saying as well), that is good enough for me. Regards, -Pavan On Thu, Aug 3, 2023 at 10:04 PM Samuel Sidor (ssidor) wrote: > Hi Pavan, > > > > Please see inline . > > > > Regards, > > Samuel > > > > *From:* Vishnu Pavan Beeram > *Sent:* Thursday, August 3, 2023 4:40 PM > *To:* Samuel Sidor (ssidor) > *Cc:* Dhruv Dhody ; Dhruv Dhody ; > Marcel Reuter (External) ; > pce@ietf.org; draft-ietf-pce-stateful-pce-ven...@ietf.org > *Subject:* Re: [Pce] Mail regarding draft-ietf-pce-pcep > > > > Samuel, Hi! > > > > The requirement is to be able to carry "vendor specific information" in > the OPEN message. Some of this information may be relevant for deciding > whether the session should be established or not while some other > information may become relevant only later when processing LSPs (and has no > bearing on "opening" the session). An implementation should be able to use > the VENDOR_INFO TLV in the OPEN object for the former and the VENDOR_INFO > Object (marked optional like in any other message) for the latter. I don't > understand why this usage/flexibility needs to be prohibited. > > > > I don’t think it was explicitly prohibited for vendor info object. It > is inheriting default rules, which are applied for all PCEP objects. RC5440 > clearly stated that content of PCEP message is described in BNF – so all > mandatory and optional objects, which can be included are explicitly > listed. Each RFC, which is defining new PCEP object is explicitly > specifying where that PCEP object can be included (PCEP message, > ordering,…). > > > > I assume that when RFC7470 introduced vendor info object, there was no > valid use-case for including that PCEP object in Open message, so it was > not explicitly added – same way like it was not added to other PCEP > messages. If we want to allow it now, then logical questions are: > >- What has changed since RFC7470? Is there really new use-case which >cannot be covered with existing vendor TLV? If we will allow use only in >Open message, how we will make sure that in 5 months somebody else will not >need it in any other PCEP message? >- How to handle backward compatibility? E.g. what will happen if you >will start including Vendor Info object in Open message, but existing >implementations, which are complaint with all existing RFCs will reject >those Open messages (you need to consider those with support for RFC7470, >but also those without support)? If extension required is for other PCEP >messages, then you we can have capability advertised in Open message to >figure out, whether extension is supported, but since you need to extend >PCEP Open message, you don’t have simple way to figure it out. >- Where such extension should be included? As Dhruv mentioned, >logically it does not belong into stateful vendor info draft, so we have 2 >options: > > >- New draft > - Re-working stateful draft to include this change, rename it,… > > > > That said, if the WG concludes that the "vendor specific information" > should ONLY exist in TLV form in the OPEN message, I would like it to be > explicitly specified somewhere. > > > > As described above – for PCEP objects, it is always explicitly > specified which PCEP object is allowed in which PCEP message. For TLV, > RFC7470 is already saying: > > > > https://www.rfc-editor.org/rfc/rfc7470.html#section-1 > > > >This document also defines a new PCEP TLV, the VENDOR-INFORMATION-TLV > >that can be used to carry arbitrary information within any existing > >or future PCEP object that supports TLVs. > > … > >- Clarification that the TLV is available for use in any PCEP object > > (existing or future) that supports TLVs. > > > > But maybe other WG members knows about some other statements, which can > still block it for Open message. > > > > Regards, > > -Pavan > > > > On Thu, Aug 3, 2023 at 1:45 PM Samuel Sidor (ssidor) > wrote: > > Hi Pavan, > > > > Is it possible to specify usecase a bit? > > > > I’m not against allowing Vendor Info object in OPEN message, but I > personally tend to agree with Dhruv’s explanation. In general, PCEP open > message is supposed to exchange/negotiate various capabilities of PCEP > peers, timer values, path-setup-types,… but all of them seems to be related > to Open object, so vendor TLV seems to be sufficient for something like >
Re: [Pce] Mail regarding draft-ietf-pce-pcep
Hi Pavan, Please see inline . Regards, Samuel From: Vishnu Pavan Beeram Sent: Thursday, August 3, 2023 4:40 PM To: Samuel Sidor (ssidor) Cc: Dhruv Dhody ; Dhruv Dhody ; Marcel Reuter (External) ; pce@ietf.org; draft-ietf-pce-stateful-pce-ven...@ietf.org Subject: Re: [Pce] Mail regarding draft-ietf-pce-pcep Samuel, Hi! The requirement is to be able to carry "vendor specific information" in the OPEN message. Some of this information may be relevant for deciding whether the session should be established or not while some other information may become relevant only later when processing LSPs (and has no bearing on "opening" the session). An implementation should be able to use the VENDOR_INFO TLV in the OPEN object for the former and the VENDOR_INFO Object (marked optional like in any other message) for the latter. I don't understand why this usage/flexibility needs to be prohibited. I don’t think it was explicitly prohibited for vendor info object. It is inheriting default rules, which are applied for all PCEP objects. RC5440 clearly stated that content of PCEP message is described in BNF – so all mandatory and optional objects, which can be included are explicitly listed. Each RFC, which is defining new PCEP object is explicitly specifying where that PCEP object can be included (PCEP message, ordering,…). I assume that when RFC7470 introduced vendor info object, there was no valid use-case for including that PCEP object in Open message, so it was not explicitly added – same way like it was not added to other PCEP messages. If we want to allow it now, then logical questions are: * What has changed since RFC7470? Is there really new use-case which cannot be covered with existing vendor TLV? If we will allow use only in Open message, how we will make sure that in 5 months somebody else will not need it in any other PCEP message? * How to handle backward compatibility? E.g. what will happen if you will start including Vendor Info object in Open message, but existing implementations, which are complaint with all existing RFCs will reject those Open messages (you need to consider those with support for RFC7470, but also those without support)? If extension required is for other PCEP messages, then you we can have capability advertised in Open message to figure out, whether extension is supported, but since you need to extend PCEP Open message, you don’t have simple way to figure it out. * Where such extension should be included? As Dhruv mentioned, logically it does not belong into stateful vendor info draft, so we have 2 options: * New draft * Re-working stateful draft to include this change, rename it,… That said, if the WG concludes that the "vendor specific information" should ONLY exist in TLV form in the OPEN message, I would like it to be explicitly specified somewhere. As described above – for PCEP objects, it is always explicitly specified which PCEP object is allowed in which PCEP message. For TLV, RFC7470 is already saying: https://www.rfc-editor.org/rfc/rfc7470.html#section-1 This document also defines a new PCEP TLV, the VENDOR-INFORMATION-TLV that can be used to carry arbitrary information within any existing or future PCEP object that supports TLVs. … - Clarification that the TLV is available for use in any PCEP object (existing or future) that supports TLVs. But maybe other WG members knows about some other statements, which can still block it for Open message. Regards, -Pavan On Thu, Aug 3, 2023 at 1:45 PM Samuel Sidor (ssidor) mailto:ssi...@cisco.com>> wrote: Hi Pavan, Is it possible to specify usecase a bit? I’m not against allowing Vendor Info object in OPEN message, but I personally tend to agree with Dhruv’s explanation. In general, PCEP open message is supposed to exchange/negotiate various capabilities of PCEP peers, timer values, path-setup-types,… but all of them seems to be related to Open object, so vendor TLV seems to be sufficient for something like that. In general, I can see benefit in using PCEP object over PCEP TLV (on top of logical association with underlaying object) in already defined flags in object header (P/I flags), which can help if you want to mark that object as mandatory/optional while TLV is always optional and can be ignored during parsing. In case of Vendor Info object, I don’t see good reason to mark it as mandatory, so flags are not adding any extra value. If you will mark vendor object as mandatory, then you will restrict processing of PCEP messages for specific LSPs to specific vendor only (logical assumption is that other vendors will not be able to process vendor object from other vendors), other vendors will have to reject it (if you want to do that, then you don’t need any standardization at all as you can use any private format). So is there really any reason to use vendor info object instead of ven
Re: [Pce] Mail regarding draft-ietf-pce-pcep
Samuel, Hi! The requirement is to be able to carry "vendor specific information" in the OPEN message. Some of this information may be relevant for deciding whether the session should be established or not while some other information may become relevant only later when processing LSPs (and has no bearing on "opening" the session). An implementation should be able to use the VENDOR_INFO TLV in the OPEN object for the former and the VENDOR_INFO Object (marked optional like in any other message) for the latter. I don't understand why this usage/flexibility needs to be prohibited. That said, if the WG concludes that the "vendor specific information" should ONLY exist in TLV form in the OPEN message, I would like it to be explicitly specified somewhere. Regards, -Pavan On Thu, Aug 3, 2023 at 1:45 PM Samuel Sidor (ssidor) wrote: > Hi Pavan, > > > > Is it possible to specify usecase a bit? > > > > I’m not against allowing Vendor Info object in OPEN message, but I > personally tend to agree with Dhruv’s explanation. In general, PCEP open > message is supposed to exchange/negotiate various capabilities of PCEP > peers, timer values, path-setup-types,… but all of them seems to be related > to Open object, so vendor TLV seems to be sufficient for something like > that. > > > > In general, I can see benefit in using PCEP object over PCEP TLV (on top > of logical association with underlaying object) in already defined flags in > object header (P/I flags), which can help if you want to mark that object > as mandatory/optional while TLV is always optional and can be ignored > during parsing. In case of Vendor Info object, I don’t see good reason to > mark it as mandatory, so flags are not adding any extra value. If you will > mark vendor object as mandatory, then you will restrict processing of PCEP > messages for specific LSPs to specific vendor only (logical assumption is > that other vendors will not be able to process vendor object from other > vendors), other vendors will have to reject it (if you want to do that, > then you don’t need any standardization at all as you can use any private > format). > > > > So is there really any reason to use vendor info object instead of vendor > TLV, which should be already allowed? > > > > For argument about consistency – would it be really consistent even after > that change? My understanding (but others can correct me) that TLVs can be > included in a lot of PCEP objects (still probably not all as some objects > are specifying explicitly that optional TLVs can be included, but some PCEP > objects have fixed length) and all PCEP messages, where PCEP objects with > optional TLVs can be included. But including any PCEP object MUST be > explicitly allowed - including potential expected ordering of objects in > that PCEP message (considering draft-dhody-pce-pcep-object-order). > > > > Thanks, > > Samuel > > > > *From:* Vishnu Pavan Beeram > *Sent:* Wednesday, August 2, 2023 7:01 PM > *To:* Dhruv Dhody > *Cc:* Dhruv Dhody ; Marcel Reuter (External) < > marcel.reuter.exter...@telefonica.com>; pce@ietf.org; > draft-ietf-pce-stateful-pce-ven...@ietf.org > *Subject:* Re: [Pce] Mail regarding draft-ietf-pce-pcep > > > > 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 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 > wrote: > > Please see inline.. > > > > On Wed, Aug 2, 2023 at 7:19 PM Dhruv Dhody wrote: > > Hi Pavan, > > > > On Wed, Aug 2, 2023 at 8:39 AM Vishnu Pavan Beeram > wrote: > > Marcel, Hi! > > Thanks for bringing this to the list! I interp
Re: [Pce] Mail regarding draft-ietf-pce-pcep
Good morning Dhruv ! Good morning Pavan! Thanks for taking this point and having an active discussion. Question inline From: Dhruv Dhody Date: Wednesday, 2. August 2023 at 16:49 To: Vishnu Pavan Beeram Cc: Dhruv Dhody , Marcel Reuter (External) , pce@ietf.org Subject: Re: [Pce] Mail regarding draft-ietf-pce-pcep Hi Pavan, On Wed, Aug 2, 2023 at 8:39 AM Vishnu Pavan Beeram mailto:vishnupa...@gmail.com>> 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? Also, is there anything that cannot be achieved via the TLV, and you would need the Object in the Open message case? Just wondering... Thanks! Dhruv [MR]: Would it be maybe more clear, if there could be a separate "VENDOR-INFORMATION" object in the Open message, so the open object stays only with standard options / TLV’s? Regards, -Pavan On Wed, Aug 2, 2023 at 6:51 PM Dhruv Dhody mailto:dhruv.i...@gmail.com>> 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) mailto:marcel.reuter.exter...@telefonica.com>> 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: ::= 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 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
Re: [Pce] Mail regarding draft-ietf-pce-pcep
Hi Pavan, Is it possible to specify usecase a bit? I’m not against allowing Vendor Info object in OPEN message, but I personally tend to agree with Dhruv’s explanation. In general, PCEP open message is supposed to exchange/negotiate various capabilities of PCEP peers, timer values, path-setup-types,… but all of them seems to be related to Open object, so vendor TLV seems to be sufficient for something like that. In general, I can see benefit in using PCEP object over PCEP TLV (on top of logical association with underlaying object) in already defined flags in object header (P/I flags), which can help if you want to mark that object as mandatory/optional while TLV is always optional and can be ignored during parsing. In case of Vendor Info object, I don’t see good reason to mark it as mandatory, so flags are not adding any extra value. If you will mark vendor object as mandatory, then you will restrict processing of PCEP messages for specific LSPs to specific vendor only (logical assumption is that other vendors will not be able to process vendor object from other vendors), other vendors will have to reject it (if you want to do that, then you don’t need any standardization at all as you can use any private format). So is there really any reason to use vendor info object instead of vendor TLV, which should be already allowed? For argument about consistency – would it be really consistent even after that change? My understanding (but others can correct me) that TLVs can be included in a lot of PCEP objects (still probably not all as some objects are specifying explicitly that optional TLVs can be included, but some PCEP objects have fixed length) and all PCEP messages, where PCEP objects with optional TLVs can be included. But including any PCEP object MUST be explicitly allowed - including potential expected ordering of objects in that PCEP message (considering draft-dhody-pce-pcep-object-order). Thanks, Samuel From: Vishnu Pavan Beeram Sent: Wednesday, August 2, 2023 7:01 PM To: Dhruv Dhody Cc: Dhruv Dhody ; Marcel Reuter (External) ; pce@ietf.org; draft-ietf-pce-stateful-pce-ven...@ietf.org Subject: Re: [Pce] Mail regarding draft-ietf-pce-pcep 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 mailto:d...@dhruvdhody.com>> 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 mailto:vishnupa...@gmail.com>> wrote: Please see inline.. On Wed, Aug 2, 2023 at 7:19 PM Dhruv Dhody mailto:d...@dhruvdhody.com>> wrote: Hi Pavan, On Wed, Aug 2, 2023 at 8:39 AM Vishnu Pavan Beeram mailto:vishnupa...@gmail.com>> 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 bot
Re: [Pce] Mail regarding draft-ietf-pce-pcep
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 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 > wrote: > >> Please see inline.. >> >> On Wed, Aug 2, 2023 at 7:19 PM Dhruv Dhody wrote: >> >>> Hi Pavan, >>> >>> On Wed, Aug 2, 2023 at 8:39 AM Vishnu Pavan Beeram < >>> vishnupa...@gmail.com> 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 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) < > marcel.reuter.exter...@telefonica.com> 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: >> >>::= >> >> 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 mess
Re: [Pce] Mail regarding draft-ietf-pce-pcep
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 wrote: > Please see inline.. > > On Wed, Aug 2, 2023 at 7:19 PM Dhruv Dhody wrote: > >> Hi Pavan, >> >> On Wed, Aug 2, 2023 at 8:39 AM Vishnu Pavan Beeram >> 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 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) < marcel.reuter.exter...@telefonica.com> 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: > >::= > > 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 > > marcel.reuter.exter...@telefonica.com > > > > Este mensaje y sus adjuntos se dirigen exclusivamente a su > destinatario, puede contener infor
Re: [Pce] Mail regarding draft-ietf-pce-pcep
Please see inline.. On Wed, Aug 2, 2023 at 7:19 PM Dhruv Dhody wrote: > Hi Pavan, > > On Wed, Aug 2, 2023 at 8:39 AM Vishnu Pavan Beeram > 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 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) < >>> marcel.reuter.exter...@telefonica.com> 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: ::= 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 marcel.reuter.exter...@telefonica.com 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 communi
Re: [Pce] Mail regarding draft-ietf-pce-pcep
Hi Pavan, On Wed, Aug 2, 2023 at 8:39 AM Vishnu Pavan Beeram 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? Also, is there anything that cannot be achieved via the TLV, and you would need the Object in the Open message case? Just wondering... Thanks! Dhruv > Regards, > -Pavan > > On Wed, Aug 2, 2023 at 6:51 PM Dhruv Dhody 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) < >> marcel.reuter.exter...@telefonica.com> 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: >>> >>>::= >>> >>> 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 >>> >>> marcel.reuter.exter...@telefonica.com >>> >>> >>> >>> 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 e
Re: [Pce] Mail regarding draft-ietf-pce-pcep
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. Regards, -Pavan On Wed, Aug 2, 2023 at 6:51 PM Dhruv Dhody 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) < > marcel.reuter.exter...@telefonica.com> 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: >> >>::= >> >> 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 >> >> marcel.reuter.exter...@telefonica.com >> >> >> >> 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 >> Pce@ietf.org >> https://www.ietf.org/mailman/listinfo/pce >> > ___ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] Mail regarding draft-ietf-pce-pcep
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) < marcel.reuter.exter...@telefonica.com> 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: > >::= > > 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 > > marcel.reuter.exter...@telefonica.com > > > > 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 > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
[Pce] Mail regarding draft-ietf-pce-pcep
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: ::= 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 Thanks a lot Marcel :-) VG Marcel Reuter -- Marcel Reuter Im Auftrag der Telefónica Germany GmbH & Co. OHG Überseering 33a 22297 Hamburg marcel.reuter.exter...@telefonica.com 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 Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
