[Pce] Re: WGLC for draft-ietf-pce-pcep-color-04

[Vishnu Pavan Beeram]

Dhruv, Hi!,
I support publication of the document. The document should be ready to
progress to the next stage after addressing the comments raised by Adrian.

Regards,
-Pavan (as a co-author).

On Tue, Jun 4, 2024 at 9:21 AM Dhruv Dhody  wrote:

> Hi WG,
>
> This email starts a 2-weeks working group last call
> for draft-ietf-pce-pcep-color-04.
>
> https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-color/
>
> Please 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 Tuesday 18 June 2024.
>
> A general reminder to the WG to be more vocal during the
> last-call/adoption.
>
> Thanks,
> Dhruv & Julien
> ___
> Pce mailing list -- pce@ietf.org
> To unsubscribe send an email to pce-le...@ietf.org
>
___
Pce mailing list -- pce@ietf.org
To unsubscribe send an email to pce-le...@ietf.org

[Pce] Re: IPR poll for draft-ietf-pce-pcep-color

[Vishnu Pavan Beeram]

 I am not aware of any IPR applicable to this draft that should be
disclosed in accordance with IETF IPR rules.

Regards,
-Pavan

On Wed, Jun 5, 2024 at 1:23 AM Andrew Stone (Nokia)  wrote:

> Hi Authors,
>
>
>
> In preparation for WGLC on this draft, we'd like all authors and
> contributors to confirm on the list that they are in compliance with IETF
> IPR rules.
>
>
>
> Please respond (copying the mailing list) to say one of:
>
>
>
> - I am not aware of any IPR applicable to this draft that should be
> disclosed in accordance with IETF IPR rules.
>
>
>
> - I am aware of the IPR applicable to this draft, and it has already been
> disclosed to the IETF.
>
>
>
> - I am aware of IPR applicable to this draft, but that has not yet been
> disclosed to the IETF. I will work to ensure that it will be disclosed in a
> timely manner.
>
>
>
>
>
> Thanks,
>
> Andrew
> ___
> Pce mailing list -- pce@ietf.org
> To unsubscribe send an email to pce-le...@ietf.org
>
___
Pce mailing list -- pce@ietf.org
To unsubscribe send an email to pce-le...@ietf.org

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

[Vishnu Pavan Beeram]

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
> that

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

[Vishnu Pavan Beeram]

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 interpret the te

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

[Vishnu Pavan Beeram]

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:
>>>>>>
>>>>>>::= 
>>>>&g

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

[Vishnu Pavan Beeram]

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
>>>

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

[Vishnu Pavan Beeram]

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] A small issue with the use of ERO and RRO in RSVP-TE and PCEP

[Vishnu Pavan Beeram]

Adrian, Hi!

Thanks for bringing this to the WG's attention!

I don't think this issue warrants anything other than (1) from your list of
actions.
This isn't much of an issue from a deployment/operational point of view. If
an RSVP-TE implementation chose to add (either deliberately or erroneously)
a sub-object of type 36 (or 40 or some other PCEP-only type that gets added
in the future) in the ERO/SERO, there is sufficient text in RFC3209
(sections 4.3.4.1 and 4.3.6) that explains what a recipient-node needs to
do when it encounters an unknown sub-object. If an unknown sub-object shows
up in the RRO/SRRO, the expected behavior on the node processing the
recorded information is to ignore the sub-object (Section 4.4.5 of RFC3209).

Regards,
-Pavan (as a WG participant)

On Tue, Feb 21, 2023 at 2:14 AM Adrian Farrel  wrote:

> Hi,
>
> You may recall that, back in the early days, the plan for PCEP was that it
> was used to determine the paths that were to be signalled in MPLS-TE and to
> report on those paths.
>
> To that end, the ERO and RRO in PCEP messages follow the same construction
> as those used in RSVP-TE. That is, they are made up of an ordered list of
> subobjects as specified in the IANA registries for RSVP
> (
> https://www.iana.org/assignments/rsvp-parameters/rsvp-parameters.xhtml#rsvp
> -parameters-25
> 
> and
>
> https://www.iana.org/assignments/rsvp-parameters/rsvp-parameters.xhtml#rsvp-
> parameters-26
> 
> )
>
> RFC 5440 says of the PCEP objects that, "PCEP ERO sub-object types
> correspond to RSVP-TE ERO sub-object types," and that, "Since the explicit
> path is available for immediate signaling by the MPLS or GMPLS control
> plane, the meanings of all of the sub-objects and fields in this object are
> identical to those defined for the ERO."
>
> We should also consider that the two registries reference RFC 3209, and
> also
> RFC 7571 (for the ERO) to describe the meaning of the registries. Of
> course,
> individual subobjects in the registries also reference the RFCs that define
> those subobjects, but there is (I think) an assumption that the registries
> list subobjects that can be used in RSVP-TE signaling.
>
> Now (finally) to the point.
>
> PCEP is being used for determining paths in Segment Routing networks. SR
> (of
> course) does not use RSVP-TE signaling, but there is still a desire to
> describe paths to be used and that have been used. To achieve that, RFC
> 8664
> (for SR-MPLS) and draft-ietf-pce-segment-routing-ipv6 (for SRv6) have
> defined the use of the PCEP ERO and RRO for SR paths. In doing so, they
> needed to define new subobjects (to contain SR-MPLS SIDs and SRv6 SIDs)
> within the ERO and RRO.
>
> This led to those subobjects being added to the RSVP-TE IANA registries
> (using IANA early allocation in the case of
> draft-ietf-pce-segment-routing-ipv6).
>
> This leaves me a bit uneasy.
>
> While the entries for draft-ietf-pce-segment-routing-ipv6 (#40 for SRv6)
> show "(PCEP-specific)" the entry for RFC 8664 (#36 for SR) don't say
> anything extra. Of course, there are references to the defining documents,
> but neither document mentions what happens when those subobjects are found
> in an RSVP-TE message. Nothing tells an RSVP-TE implementer what to expect
> with these subobjects.
>
> This problem propagates to the SERO and SRRO in RSVP-TE since they inherit
> subobjects from the ERO and RRO.
>
> Possibly, this is all covered by RFC 3209 section 4.3.4.1 step 1) and
> should
> result in a "Routing Problem" error code with "Bad initial subobject" error
> value. In this case, there is not so much for me to worry about and
> (perhaps) we just need to:
>
> 1. Fix the registries to say "(PCEP only)" for #36. I think an AD action
> can
> do this without the need to write any drafts, etc.
> 2. Decide it is too late to put any note in RFC 8664 to clarify that the
> #36
> subobjects are not for use in RSVP-TE.
> 3. Add a note to draft-ietf-segment-routing-ipv6 to say that the #40
> subobjects are not for use in RSVP-TE.
> 4. Consider whether there is a need to document that the registries have
> entries that are only for PCEP. A way to do this would be a short draft to
> add two columns to the registries and populate them for existing subobjects
> to show "may be used in RSVP-TE" and "may be used in PCEP". I'd be willing
> to write that up.
>
> Of course an (unpopular) option would be to tell the PCE WG that it is not
> acceptable to use the RSVP-TE registries in this way, and let them know
> that
> if they want to specify paths for other uses they should use a new PCEP ERO
> and RRO Object-Type and a new registry of subobjects. In many ways, that
> would be so much cleaner, but it would break RFC 8664 implementations.
>
> Opinions?
>
> Cheers,
> Adrian
>
> 

Re: [Pce] Question on draft-ietf-pce-local-protection-enforcement

[Vishnu Pavan Beeram]

Dhruv, Hi!

Thanks for the response! Please see inline..

Regards,
-Pavan

On Wed, Jan 11, 2023 at 12:03 PM Dhruv Dhody  wrote:

> Hi Pavan,
>
> On Wed, Jan 11, 2023 at 11:02 AM Vishnu Pavan Beeram <
> vishnupa...@gmail.com> wrote:
>
>> I would like to get some clarification on the text below (understand that
>> a publication request has been made for the draft).
>>
>> **
>> From Section 5:
>>
>>When L-flag is not set and E-flag is not set then PCE SHOULD consider
>>the protection eligibility as UNPROTECTED PREFERRED but MAY consider
>>protection eligibility as UNPROTECTED MANDATORY constraint.
>>
>>When L-flag is not set and E-flag is set then PCE MUST consider the
>>protection eligibility as UNPROTECTED MANDATORY constraint.
>>
>>
>>
>> **
>> For the scenario where both the L-flag and the E-flag are not set (first
>> statement above), it seems okay to just say
>> that the "PCE MUST consider the protection eligibility as UNPROTECTED
>> PREFERRED". Is there a good reason
>> for both the "SHOULD (UNPROTECTED PREFERRED)" and "MAY (UNPROTECTED
>> MANDATORY)" clauses to
>> be included here (and keep things ambiguous)?
>>
>>
> Dhruv: If I recall correctly (and the authors can confirm that), this was
> done for the sake of backward compatibility. I remember it being discussed
> on the mailing list as well.
>
> [VPB] Thanks for the pointer to the mailing list thread (should have
searched there first; apologies for re-opening the topic) -- it was useful!
However, the backwards compatibility section (5.1) seems to be silent about
this particular scenario.

If a PCEP speaker does not understand this document (and thus ignores the E
> flag) and L flag is set to 0, would behave as per RFC 5440 where the
> concept of enforcement is undefined and some implementation could
> understand it to be handled as UNPROTECTED MANDATORY instead of UNPROTECTED
> PREFERRED. And the text allows for it.
>

[VPB] I understand that there was ambiguity with how the (presence/absence
of the) L-flag was interpreted prior to this draft. I was hoping that there
would be no ambiguity left when this draft is implemented -- but that
doesn't seem to be the case. Let's say a PCC implementation assumes [L 0, E
0] to mean "UNPROTECTED PREFERRED" (SHOULD clause), while the PCE
implementation assumes it to mean "UNPROTECTED MANDATORY" (MAY clause) --
this may result in no path being returned (if only protected SIDs are
available on some links along the viable paths). Do we need to retain this
ambiguity?


>
> Happy to get additional eyes and confirm if it still makes sense!
>
> Thanks!
> Dhruv
>
>
>
>> Regards,
>> -Pavan
>> ___
>> 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] Question on draft-ietf-pce-local-protection-enforcement

[Vishnu Pavan Beeram]

I would like to get some clarification on the text below (understand that a
publication request has been made for the draft).

**
>From Section 5:

   When L-flag is not set and E-flag is not set then PCE SHOULD consider
   the protection eligibility as UNPROTECTED PREFERRED but MAY consider
   protection eligibility as UNPROTECTED MANDATORY constraint.

   When L-flag is not set and E-flag is set then PCE MUST consider the
   protection eligibility as UNPROTECTED MANDATORY constraint.



**
For the scenario where both the L-flag and the E-flag are not set (first
statement above), it seems okay to just say
that the "PCE MUST consider the protection eligibility as UNPROTECTED
PREFERRED". Is there a good reason
for both the "SHOULD (UNPROTECTED PREFERRED)" and "MAY (UNPROTECTED
MANDATORY)" clauses to
be included here (and keep things ambiguous)?

Regards,
-Pavan
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] WG Adoption of draft-rajagopalan-pce-pcep-color-02

[Vishnu Pavan Beeram]

As a co-author, I would like to see the document get adopted by the WG.

The use of "color" to associate a TE tunnel/policy with an intent has been
widely discussed in other routing area WGs -- the PCEP extension proposed
in this document to carry the "color" attribute is a useful addition to the
service-mapping toolkit. As far as the authors are concerned, there are no
open issues.

Regards,
-Pavan

On Thu, Dec 1, 2022 at 10:37 AM Dhruv Dhody  wrote:

> Hi WG,
>
> This email begins the WG adoption poll for
> draft-rajagopalan-pce-pcep-color-02.
>
> https://datatracker.ietf.org/doc/draft-rajagopalan-pce-pcep-color/
>
> Should this draft be adopted by the PCE WG? Please state your reasons -
> Why / Why not? What needs to be fixed before or after adoption? Are you
> willing to work on this draft? Review comments should be posted to the list.
>
> Please respond by Friday 16th Dec 2022.
>
> Please be more vocal during WG polls!
>
> Thanks!
> Dhruv & Julien
> ___
> 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] IPR Poll on draft-rajagopalan-pce-pcep-color-02

[Vishnu Pavan Beeram]

Hari, Chairs,

I am not aware of any IPR applicable to this draft that should be disclosed
in accordance with IETF IPR rules.

Regards,
-Pavan

On Fri, Dec 2, 2022 at 2:53 AM Hariharan Ananthakrishnan  wrote:

> Hi Authors,
>
> In preparation for WG adoption on this draft, I'd like all
> authors and contributors to confirm on the list that they are in compliance
> with IETF IPR rules.
>
> Please respond (copying the mailing list) to say one of:
>
> I am not aware of any IPR applicable to this draft that should be disclosed
> in accordance with IETF IPR rules.
>
> I am aware of the IPR applicable to this draft, and it has already been
> disclosed to the IETF.
>
> I am aware of IPR applicable to this draft, but that has not yet been
> disclosed to the IETF. I will work to ensure that it will be disclosed in a
> timely manner.
>
> Thanks,
> - Hari
>
> ___
> 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] IPR Poll on draft-ietf-pce-pcep-yang

[Vishnu Pavan Beeram]

I am not aware of any IPR applicable to this draft that should be
disclosed in accordance with IETF IPR rules.

Regards,

-Pavan



On Mon, Sep 26, 2022 at 9:49 PM Hariharan Ananthakrishnan  wrote:

> Hi Authors,
>
> In preparation for WG LC on this draft, I'd like all
> authors and contributors to confirm on the list that they are in compliance
> with IETF IPR rules.
>
> Please respond (copying the mailing list) to say one of:
>
> I am not aware of any IPR applicable to this draft that should be disclosed
> in accordance with IETF IPR rules.
>
> I am aware of the IPR applicable to this draft, and it has already been
> disclosed to the IETF.
>
> I am aware of IPR applicable to this draft, but that has not yet been
> disclosed to the IETF. I will work to ensure that it will be disclosed in a
> timely manner.
>
> Thanks,
> - Hari
>
> ___
> 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] Fwd: WG Last Call: draft-ietf-teas-pcecc-use-cases-10

[Vishnu Pavan Beeram]

FYI -- The TEAS WG Last Call for draft-ietf-teas-pcecc-use-cases-10 will
end on July 13th. Please send review comments (if any) by responding to the
LC thread on the TEAS mailing list.
https://mailarchive.ietf.org/arch/msg/teas/0uHwQ0m_7sI7UB_YxyfwEYE3zAM/

Regards,
Pavan and Lou (TEAS WG chairs)

-- Forwarded message -
From: Vishnu Pavan Beeram 
Date: Fri, Jun 17, 2022 at 12:42 PM
Subject: WG Last Call: draft-ietf-teas-pcecc-use-cases-10
To: TEAS WG 
Cc: TEAS WG Chairs 


All,

This starts a two-week working group last call on
https://datatracker.ietf.org/doc/draft-ietf-teas-pcecc-use-cases/

The working group last call ends on July 1st, 2022.
Please send your comments to the working group mailing list.

Positive comments, e.g., "I've reviewed this document
and believe it is ready for publication", are welcome!
This is useful and important, even from authors.

Note: IPR has been disclosed on this document

Thank you,
Pavan and Lou
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Question on differentiating between "intended metrics" and "actual metrics" in a PCRpt message

[Vishnu Pavan Beeram]

Dhruv, Hi!

Thanks for the quick clarification!

The mandate that I was missing is that the PCC MUST not include the
 in the PCRpt if it does not include the RRO. I
thought the SR-RRO was optional (even if the LSP is UP/ACTIVE), but it
doesn't seem to be the case.

Regards,
-Pavan


On Mon, Feb 21, 2022 at 10:21 AM Dhruv Dhody  wrote:

> Hi Pavan,
>
> An important factor to distinguish between the actual and intended
> attribute list is the presence of RRO (i.e. ) and the order
> of objects in the PCRpt message.
>
> If the RRO is present, any attributes encoded before it, are to be
> considered as part of  and those after it, as part
> of .
>
> If the RRO is absent, all attributes are part
> of .
>
> Am I missing something?
>
> Thanks!
> Dhruv
>
> On Mon, Feb 21, 2022 at 8:11 PM Vishnu Pavan Beeram 
> wrote:
>
>> WG,
>>
>>
>> As per RFC8231, a PCRpt message can carry a list of 
>> entries, where:
>>
>>::= []
>>  
>>  
>>   where:
>>   ::= 
>> []
>> 
>>
>>   ::=[]
>> []
>>
>> When the report carries both "actual attributes" and "intended
>> attributes", there needs to be a way to unambiguously distinguish between
>> the attributes in each list. With BANDWIDTH, the distinction is provided by
>> the ObjectType (1 vs 2). The METRIC object, however, does not have that
>> distinction provided via ObjectType. When intended metric objects and actual
>> metric objects are contiguous (other objects between these are optional),
>> there doesn't seem to be a clear way to do the demarcation.
>>
>>
>> Section 6.1 of RFC8231 seems to hint at the use of the C flag for this.
>> **
>>
>>When included as part of the actual-attribute-list,
>>Object-Type 2 [RFC5440 <https://datatracker.ietf.org/doc/html/rfc5440>] 
>> SHOULD be used for the BANDWIDTH object, and
>>the C flag SHOULD be set in the METRIC object [RFC5440 
>> <https://datatracker.ietf.org/doc/html/rfc5440>].
>>
>>
>> **
>>
>>
>> But this section does not preclude the use of the C flag in the METRIC
>> object listed in the "intended-attribute-list" block of the PCRpt message.
>> An implementation may use the C flag in the intended-metric carried in the
>> PCRpt as a means to request the PCE to send the "computed metric" in the
>> PCUpd message. If it is mandated that the C flag should not be set in
>> the METRIC object when listed as part of the "intended-attribute-list",
>> then the PCC loses the ability to request the PCE to send the "computed
>> metric".
>>
>>
>> Looking through packet traces from various interoperability reports, I do
>> see that there is no consistent interpretation of this flag. Any thoughts
>> on what should be the best practice for this?
>>
>>
>> Regards,
>>
>> -Pavan
>> ___
>> 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] Question on differentiating between "intended metrics" and "actual metrics" in a PCRpt message

[Vishnu Pavan Beeram]

WG,


As per RFC8231, a PCRpt message can carry a list of  entries,
where:

   ::= []
 
 
  where:
  ::= 
[]


  ::=[]
[]

When the report carries both "actual attributes" and "intended attributes",
there needs to be a way to unambiguously distinguish between the attributes
in each list. With BANDWIDTH, the distinction is provided by the ObjectType
(1 vs 2). The METRIC object, however, does not have that distinction
provided via ObjectType. When intended metric objects and actual metric
objects are contiguous (other objects between these are optional), there
doesn't seem to be a clear way to do the demarcation.


Section 6.1 of RFC8231 seems to hint at the use of the C flag for this.
**

   When included as part of the actual-attribute-list,
   Object-Type 2 [RFC5440
] SHOULD be used for
the BANDWIDTH object, and
   the C flag SHOULD be set in the METRIC object [RFC5440
].


**


But this section does not preclude the use of the C flag in the METRIC
object listed in the "intended-attribute-list" block of the PCRpt message.
An implementation may use the C flag in the intended-metric carried in the
PCRpt as a means to request the PCE to send the "computed metric" in the
PCUpd message. If it is mandated that the C flag should not be set in the
METRIC object when listed as part of the "intended-attribute-list", then
the PCC loses the ability to request the PCE to send the "computed metric".


Looking through packet traces from various interoperability reports, I do
see that there is no consistent interpretation of this flag. Any thoughts
on what should be the best practice for this?


Regards,

-Pavan
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

[Pce] draft-rajagapolan-pce-pcep-color-00 -- Placement of the color TLV

[Vishnu Pavan Beeram]

Dhruv had a question in today's session on where the color TLV needs to be
placed. The placement of the TLV depends on the use-case. For the RSVP-TE
service-mapping use-case discussed in this document, the TLV would be
placed in the LSP object. For the multipath use-case, it would be
in PATH-ATTRIB object.

Section 3 of the document does says this:

   The actual color value itself is carried in a newly defined TLV in
   the LSP Object defined in [RFC8231
].


This needs to move to Section 2.


Regards,

-Pavan
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] IPR Poll on draft-koldychev-pce-multipath-05

[Vishnu Pavan Beeram]

I am not aware of any IPR applicable to this draft that should be disclosed in 
accordance with IETF IPR rules.

Regards,
-Pavan


From: Hariharan Ananthakrishnan 
Date: Monday, April 19, 2021 at 8:34 AM
To: Mike Koldychev (mkoldych) , ssiva...@ciena.com 
, Tarek Saad , Vishnu Pavan Beeram 
, hooman.bidg...@nokia.com , 
bya...@ciena.com , pengshup...@huawei.com 

Cc: pce@ietf.org 
Subject: IPR Poll on draft-koldychev-pce-multipath-05
[External Email. Be cautious of content]


Hi Authors,



In preparation for WG adoption on this draft, I'd like all

authors and contributors to confirm on the list that they are in compliance

with IETF IPR rules.

Please respond (copying the mailing list) to say one of:

I am not aware of any IPR applicable to this draft that should be disclosed

in accordance with IETF IPR rules.



I am aware of the IPR applicable to this draft, and it has already been

disclosed to the IETF.



I am aware of IPR applicable to this draft, but that has not yet been

disclosed to the IETF. I will work to ensure that it will be disclosed in a

timely manner.



Thanks,

- Hari


Juniper Business Use Only
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] WG Adoption of draft-koldychev-pce-multipath-05

[Vishnu Pavan Beeram]

Yes, the draft should be adopted. It addresses a crucial gap in the TE
multipath toolkit.

Regards,
-Pavan (as a co-author)

On Wed, Apr 14, 2021 at 9:53 AM Dhruv Dhody  wrote:

> Hi WG,
>
> This email begins the WG adoption poll for
> draft-koldychev-pce-multipath-05.
>
> https://datatracker.ietf.org/doc/html/draft-koldychev-pce-multipath-05
>
> Should this draft be adopted by the PCE WG? Please state your reasons -
> Why / Why not? What needs to be fixed before or after adoption? Are you
> willing to work on this draft? Review comments should be posted to the
> list.
>
> Please respond by Wednesday 28th April.
>
> Thanks!
> Dhruv & Julien
> ___
> 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] WG adoption poll for draft-stone-pce-local-protection-enforcement-02.

[Vishnu Pavan Beeram]

Dhruv, Hi!

Yes, RFC5420 is the correct reference. I was referring to how the
“Attribute Flags TLV” is processed when present in the LSP_ATTRIBUTES and
LSP_REQUIRED_ATTRIBUTES objects.


A similar approach can be employed for the PCEP LSPA object. This would
need us to (a) Introduce a new flags TLV and (b) Introduce a new
LSPA_REQUIRED/LSPA_ENFORCED object that can carry this TLV when needed.
This can be done now or later when there are more flags defined.



Regards,

-Pavan



On Sun, Nov 8, 2020 at 8:03 AM Dhruv Dhody  wrote:

> Hi Pavan,
>
> Thanks for participating in the adoption call. Some clarification
> questions...
>
> Could you point the WG to the right reference in RSVP-TE? Is it RFC 5420?
>
> The Stateful-PCE-optional draft is a generic mechanism to mark whole
> PCEP objects as mandatory and optional to process. You are right that
> it doesn't cover local protection enforcement at the granularity of
> the per-attribute in the LSPA object. Please confirm if my
> understanding is correct?
>
> Note that there is a single flag defined in the LSPA object so far, so
> generalizing would help a future flag when and if it gets added. Could
> you suggest what change you would make to turn this procedure generic?
>
> Thanks!
> Dhruv
>
> On Sun, Nov 8, 2020 at 6:06 PM Vishnu Pavan Beeram
>  wrote:
> >
> > Support adoption! The draft addresses a hole in the existing protection
> toolkit.
> >
> > It would however be useful to have a generic way of requesting or
> mandating each LSP/path attribute (similar to RSVP LSP/HOP attributes). I
> haven't read draft-dhody-pce-stateful-pce-optional, but I'm assuming that
> it doesn't cover local protection enforcement.
> >
> > Regards,
> > -Pavan
> >
> > On Wed, Oct 21, 2020 at 8:41 AM Dhruv Dhody  wrote:
> >>
> >> Hi WG,
> >>
> >> This email begins the WG adoption poll for
> >> draft-stone-pce-local-protection-enforcement-02.
> >>
> >>
> https://datatracker.ietf.org/doc/html/draft-stone-pce-local-protection-enforcement-02
> >>
> >> Should this draft be adopted by the PCE WG? Please state your reasons
> >> - Why / Why not? What needs to be fixed before or after adoption? Are
> >> you willing to work on this draft? Review comments should be posted to
> >> the list.
> >>
> >> This adoption poll will end on 9th Nov 2020 (Monday).
> >>
> >> Thanks!
> >> Dhruv & Julien
> >>
> >> ___
> >> 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] WG adoption poll for draft-stone-pce-local-protection-enforcement-02.

[Vishnu Pavan Beeram]

Support adoption! The draft addresses a hole in the existing protection
toolkit.

It would however be useful to have a generic way of requesting or mandating
each LSP/path attribute (similar to RSVP LSP/HOP attributes). I haven't
read draft-dhody-pce-stateful-pce-optional, but I'm assuming that it
doesn't cover local protection enforcement.

Regards,
-Pavan

On Wed, Oct 21, 2020 at 8:41 AM Dhruv Dhody  wrote:

> Hi WG,
>
> This email begins the WG adoption poll for
> draft-stone-pce-local-protection-enforcement-02.
>
>
> https://datatracker.ietf.org/doc/html/draft-stone-pce-local-protection-enforcement-02
>
> Should this draft be adopted by the PCE WG? Please state your reasons
> - Why / Why not? What needs to be fixed before or after adoption? Are
> you willing to work on this draft? Review comments should be posted to
> the list.
>
> This adoption poll will end on 9th Nov 2020 (Monday).
>
> Thanks!
> Dhruv & Julien
>
> ___
> 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] WG adoption poll for draft-barth-pce-segment-routing-policy-cp-06

[Vishnu Pavan Beeram]

Support the adoption of this document -- this is a critical piece for
realizing controller driven SR policies.

Regards,
-Pavan

On Sun, Jun 7, 2020 at 2:46 AM Dhruv Dhody  wrote:

> Hi WG,
>
> This email begins the WG adoption poll for
> draft-barth-pce-segment-routing-policy-cp-06.
>
>
> https://datatracker.ietf.org/doc/draft-barth-pce-segment-routing-policy-cp/06/
>
> Should this draft be adopted by the PCE WG? Please state your reasons
> - Why / Why not? What needs to be fixed before or after adoption? Are
> you willing to work on this draft? Review comments should be posted to
> the list.
>
> This adoption poll will end on 22nd June 2020.
>
> Thanks!
> Dhruv & Julien
>
> ___
> 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] I-D Action: draft-ietf-pce-pcep-flowspec-09.txt

[Vishnu Pavan Beeram]

I have reviewed the latest version of this draft and I do believe that it
is ready to progress to the next stage of the publication process.

Regards,
-Pavan

On Mon, Jun 1, 2020 at 10:34 AM  wrote:

>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Path Computation Element WG of the IETF.
>
> Title   : PCEP Extension for Flow Specification
> Authors : Dhruv Dhody
>   Adrian Farrel
>   Zhenbin Li
> Filename: draft-ietf-pce-pcep-flowspec-09.txt
> Pages   : 33
> Date: 2020-06-01
>
> Abstract:
>The Path Computation Element (PCE) is a functional component capable
>of selecting paths through a traffic engineering network.  These
>paths may be supplied in response to requests for computation, or may
>be unsolicited instructions issued by the PCE to network elements.
>Both approaches use the PCE Communication Protocol (PCEP) to convey
>the details of the computed path.
>
>Traffic flows may be categorized and described using "Flow
>Specifications".  RFC  defines the Flow Specification and
>describes how Flow Specification Components are used to describe
>traffic flows.  RFC  also defines how Flow Specifications may be
>distributed in BGP to allow specific traffic flows to be associated
>with routes.
>
>This document specifies a set of extensions to PCEP to support
>dissemination of Flow Specifications.  This allows a PCE to indicate
>what traffic should be placed on each path that it is aware of.
>
>RFC Editor Note: Please replace  in the Abstract with the RFC
>number assigned to draft-ietf-idr-rfc5575bis when it is published.
>Please remove this note.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-flowspec/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-pce-pcep-flowspec-09
> https://datatracker.ietf.org/doc/html/draft-ietf-pce-pcep-flowspec-09
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-pcep-flowspec-09
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
>
> ___
> 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] A discussion point for draft-ietf-pce-pcep-flowspec

[Vishnu Pavan Beeram]

Adrian, Hi!

Please see inline..

Regards,
-Pavan

On Fri, Jan 10, 2020 at 10:32 AM Adrian Farrel  wrote:

> Thanks Pavan,
>
> It’s good to have this documented clearly.
>
>
>
> Personally, I am amused/confused that **how** packets are intercepted for
> classification (via a routing entry or via a data plane filter) is
> important to the specification of this protocol. That is, the protocol says
> “packets that match this flowspec MUST be placed on this LSP/path”. How an
> implementation chooses to achieve that is, IMHO, not material to the
> on-the-wire behaviour. That is, the packets will come in and will be placed
> on the path, and the protocol instructions to achieve it do not need to
> tell anyone how to achieve it.
>
>
>
> This is probably closest to your option 1. That is, an implementation may
> choose to implement this however it wants.
>
>
>
> It would be wrong, also IMHO, to imply that an implementation must install
> a data plane filter to handle PCEP flowspecs. That depends (of course) on
> how you define a data plane filter.
>

Existing (network element) implementations have config knobs that
distinguish between adding a filter rule to steer traffic onto the path of
a tunnel and installing a resolver route (LPM based forwarding). And like
with most TE-Tunnel/TE-Policy specific config knobs, there seems to be a
strong desire to let the Controller push/control these knobs. That is where
my options 2 and 3 come in.


>
> As to draft-ietf-pce-binding-label-sid, I fear I detect mission creep.
> What was originally a simple association of a binding SID to a PCEP message
> now also has an element of flowspec built in. I wonder whether that
> document shouldn’t refer to draft-ietf-pce-flowspec if it wants to describe
> what traffic to associate with a path.
>

I'm not sure about mission creep, but the association of a binding type to
a path does (already) describe the type of traffic steered onto the path.
It results in the installation of a keyed entry in the forwarding plane
with the action of steering the packets matching this entry to the selected
path of the policy. Given the precedent, adding a couple of new binding
types for destination prefixes seems appropriate.


>
> Like you, I would like to hear more from the working group.
>

Yeah, looking forward to see some opinions come in on this.

>
>
> Cheers,
>
> Adrian
>
>
>
> *From:* Vishnu Pavan Beeram 
> *Sent:* 10 January 2020 05:45
> *To:* Adrian Farrel 
> *Cc:* pce@ietf.org; draft-ietf-pce-pcep-flows...@ietf.org
> *Subject:* Re: [Pce] A discussion point for draft-ietf-pce-pcep-flowspec
>
>
>
> Adrian, Hi!
>
>
>
> Much Thanks for starting this thread! There are multiple implementations
> that support user-triggered installation/uninstallation of
> destination-IPv4/IPv6 prefixes bound to a TE Path (installation of routes
> subject to longest prefix match based forwarding) and it is important to
> have this behavior covered in PCEP.
>
>
>
> I’m listing 3 options that were considered for addressing this item:
>
>1. Add a new sub-section to Section 8 of
> stating that an implementation receiving a
>FLOWSPEC object that carries only destination IPv4/IPv6 TLVs may choose to
>not install any data-plane filters and instead install routes that are
>subject to longest prefix match (LPM) based forwarding. With this option,
>the controller has no say in how the network element processes these
>destination IPV4/IPv6 TLVs.
>2. Introduce a new flag in the FLOWSPEC object to explicitly indicate
>that routes subject to LPM based forwarding MUST be installed. When this
>flag is set, the FLOWSPEC object MUST carry only destination IPv4/IPv6 
> TLVs.
>3. Do not use the FLOWSPEC object at all for this; Use the
>TE-PATH-BINDING TLV (introduced by draft-ietf-pce-binding-label-sid)
>instead. This requires the addition of a couple of new Binding Types (BT)
>to indicate destination-IPV4 and destination-IPv6 bindings. This also
>requires us to add the ability to encode multiple Path Bindings (list)
>in the same message and the ability to remove specific Path Bindings in a
>given message.
>
>
>
> Based on some offline conversations with interested parties, there is a
> strong need to have an explicit indication for this type of behavior (avoid
> ambiguity with respect to filtering) -- so that makes Option 1 undesirable.
> There is also a requirement to carry a mix of install and uninstall
> destination prefixes associated with a path in the same message. The way
> the FLOWSPEC object is currently defined (the R flag is specified per
> FLOWSPEC object and not per TLV; parity with BGP), you would need one
>

Re: [Pce] A discussion point for draft-ietf-pce-pcep-flowspec

[Vishnu Pavan Beeram]

Adrian, Hi!



Much Thanks for starting this thread! There are multiple implementations
that support user-triggered installation/uninstallation of
destination-IPv4/IPv6 prefixes bound to a TE Path (installation of routes
subject to longest prefix match based forwarding) and it is important to
have this behavior covered in PCEP.



I’m listing 3 options that were considered for addressing this item:

   1. Add a new sub-section to Section 8 of 
   stating that an implementation receiving a FLOWSPEC object that carries
   only destination IPv4/IPv6 TLVs may choose to not install any data-plane
   filters and instead install routes that are subject to longest prefix match
   (LPM) based forwarding. With this option, the controller has no say in how
   the network element processes these destination IPV4/IPv6 TLVs.
   2. Introduce a new flag in the FLOWSPEC object to explicitly indicate
   that routes subject to LPM based forwarding MUST be installed. When this
   flag is set, the FLOWSPEC object MUST carry only destination IPv4/IPv6 TLVs.
   3. Do not use the FLOWSPEC object at all for this; Use the
   TE-PATH-BINDING TLV (introduced by draft-ietf-pce-binding-label-sid)
   instead. This requires the addition of a couple of new Binding Types (BT)
   to indicate destination-IPV4 and destination-IPv6 bindings. This also
   requires us to add the ability to encode multiple Path Bindings (list)
   in the same message and the ability to remove specific Path Bindings in a
   given message.



Based on some offline conversations with interested parties, there is a
strong need to have an explicit indication for this type of behavior (avoid
ambiguity with respect to filtering) -- so that makes Option 1 undesirable.
There is also a requirement to carry a mix of install and uninstall
destination prefixes associated with a path in the same message. The way
the FLOWSPEC object is currently defined (the R flag is specified per
FLOWSPEC object and not per TLV; parity with BGP), you would need one
object to carry the install prefixes and one more to carry the uninstall
prefixes. Given all this, there is some consensus among interested parties
to implement this behavior using the TE-PATH-BINDING TLV. Note that this
also means that draft-ietf-pce-pcep-flowspec can proceed as is.



@WG -- Any thoughts?



Regards,

-Pavan

On Sun, Jan 5, 2020 at 4:14 PM Adrian Farrel  wrote:

> Hi WG,
>
> I received a couple of private emails about draft-ietf-pce-pcep-flowspec.
>
> Since they were private, I will try to be circumspect about who they were
> from.
>
> The sender asked to have a flag attached to a flow specification that
> indicates that it can be installed as a static route and thus not subject
> to
> a firewall rule so the longest prefix matching can be performed to
> manipulate route resolution for an LSP.
>
> The request also said that traditionally flow-specifications result in
> firewall rules and those rules operate on packets before longest prefix
> match. We want to install static routes, the equivalent of installing a
> prefix for an LSP and if we treat a flowspec as a static route we can mess
> things up like rule ordering and so on.
>
> The sender suggested that there are currently some draft(s) regarding this
> behavior for BGP flowspec as well, but was not able to point me at them.
>
> I asked for some clarifications and got back:
>
> "What BGP-FS does is install data-plane filters.  We handle that by
> installing RIB entries (that's what BGP carries) into a RIB. Those entries
> are transformed into firewall filters.  What I am asking for is not
> currently supported by BGP-flowspec.
>
> "What I am asking for is an indication that a flow-specification NOT be
> transformed into a data-plane filter.  In other words, installed as a
> normal
> route where the route is subject to longest prefix match based forwarding..
> If you consider how we had to implement the multicast support for PCEP
> flowspec, it is quite similar.  So, in my mind, the 'flag' is an indicator
> to do LPM for a destination.  Presence of the flag also means that no other
> fields can be present in the flowspec, e.g. source address or dest/src L4
> ports, etc."
>
> In my view, it should not be too hard to add a flag to the PCEP flow
> specification.
>
> But a couple of questions for the working group and my co-authors:
> - Does anyone else have interest in this work?
> - Can anyone else identify the related BGP work?
> - Does anyone want to suggest text for this?
> - Is this something we should leave as a future extension that can be
> proposed if/when someone cares about it?
>
> I suspect that the default position is "do nothing" and ask Julien to move
> the draft forward, so if you care please speak up.
>
> Thanks,
> Adrian
>
> ___
> Pce mailing list
> Pce@ietf.org
> https://www.ietf.org/mailman/listinfo/pce
>
___
Pce mailing list
Pce@ietf.org

Re: [Pce] IPR check on draft-ietf-pce-stateful-pce-p2mp

[Vishnu Pavan Beeram]

I am not aware of any IPR that applies to this draft.

Regards,
-Pavan

On Tue, Oct 2, 2018 at 4:42 AM Jonathan Hardwick  wrote:

> Dear authors of draft-ietf-pce-stateful-pce-p2mp,
>
>
>
> Could you please send an email to the PCE mailing list saying whether you
> are aware of any IPR that applies to draft-ietf-pce-stateful-pce-p2mp and,
> if so, if it has been disclosed in compliance with IETF IPR rules? (See
> RFCs 3979, 4879, 3669 and 5378 for more details.) If you are not aware of
> any IPR that applies, please reply saying "I am not aware of any IPR that
> applies to this draft".
>
>
>
> A reply is required from each of you before publication can proceed.
>
>
>
> Thanks,
>
>
>
> Jon & Julien
>
>
>
>
> ___
> 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] Adoption of draft-pkd-pce-pcep-yang-06

[Vishnu Pavan Beeram]

Support.

-Pavan

On Fri, Aug 12, 2016 at 5:43 AM, Julien Meuric 
wrote:

> Hi all,
>
> During the joint TEAS-MPLS-PCE Yang session in Berlin, we had a clear
> consensus in the room on the interest for the aforementioned I-D. We now
> need to see if the mailing list confirms this consensus. As a result, do
> you think that draft-pkd-pce-pcep-yang-06 is a right foundation for a PCE
> WG document? As usual, comments are very welcome, especially if you do not
> support the adoption.
>
> Thanks,
>
> JP, Jon & Julien
>
> ___
> 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] Poll for adoption: draft-palle-pce-stateful-pce-p2mp-09

[Vishnu Pavan Beeram]

Yes/Support!

-Pavan (Co-Author)

*From:* Pce [mailto:pce-boun...@ietf.org] *On Behalf Of *Jonathan Hardwick
> *Sent:* 28 June 2016 22:29
> *To:* pce@ietf.org
> *Cc:* draft-palle-pce-stateful-pce-p...@ietf.org; pce-cha...@ietf.org
> *Subject:* [Pce] Poll for adoption: draft-palle-pce-stateful-pce-p2mp-09
>
>
>
> All,
>
>
>
> This is start of a two week poll on making
> draft-palle-pce-stateful-pce-p2mp-09 a PCE working group document.  This
> draft fills a gap in explaining how stateful PCE can be applied to P2MP
> paths.
>
> https://datatracker.ietf.org/doc/draft-palle-pce-stateful-pce-p2mp/
>
>
>
> Please review the draft and send an email to the list indicating
> “yes/support” or “no/do not support”.  If indicating no, please state your
> reasons.  If yes, please also feel free to provide comments you'd like to
> see addressed once the document is a WG document.
>
>
>
> The poll ends on Tuesday July 12.
>
>
>
> Thanks,
>
> Jon, JP and Julien
>
>
>
>
>
> ___
> 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] Fwd: WG Last Call on draft-ietf-teas-rsvp-te-domain-subobjects-01

[Vishnu Pavan Beeram]

Fwding this WGLC to PCE for additional commentary (Note, this TEAS draft is
related to draft-ietf-pce-pcep-domain-sequence).

- Pavan and Lou

-- Forwarded message --
From: Vishnu Pavan Beeram vishnupa...@gmail.com
Date: Tue, May 19, 2015 at 5:20 PM
Subject: WG Last Call on draft-ietf-teas-rsvp-te-domain-subobjects-01
To: t...@ietf.org t...@ietf.org


All,

This starts a two week working group last call on
draft-ietf-teas-rsvp-te-domain-subobjects-01.

This working group last call ends on Tuesday, June 2nd. Please send your
comments to the TEAS mailing list.

Note, IPR has been disclosed on this draft. All the IPR declarations from
authors and contributors have been collected and can be found in the
history of the document:
https://datatracker.ietf.org/doc/draft-ietf-ccamp-flexi-grid-fwk/history/
https://datatracker.ietf.org/doc/draft-ietf-teas-rsvp-te-domain-subobjects/history/

Pavan and Lou.
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Poll for Adoption of draft-crabbe-pce-pce-initiated-lsp-03

[Vishnu Pavan Beeram]

Support.


On Tue, Nov 12, 2013 at 9:14 AM, Julien Meuric julien.meu...@orange.comwrote:

 Hi all.

 Following the opposition expressed on merging MPLS and GMPLS documents for
 stateful PCE, the sense of the room was in favor of adopting the
 aforementionned I-D.
 Now we would like to get the feedback of the mailing list: do you support
 draft-crabbe-pce-pce-initiated-lsp-03 to become a foundation for a PCE WG
 document?

 As usual, reasons for your preference are welcome (not to say mandatory in
 case of opposition).

 Thanks,

 JP  Julien

 ___
 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