Re: [Pce] WGLC for draft-ietf-pce-stateful-pce-optional-07

[Cheng Li]

Hi Shaofu,

Sorry for my delay. Yes, you are correct! We have updated the draft to fix this 
typo.

Thank you so much!
Cheng



https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-pce-optional/



There is also an HTMLized version available at:

https://datatracker.ietf.org/doc/html/draft-ietf-pce-stateful-pce-optional-09



A diff from the previous version is available at:

https://author-tools.ietf.org/iddiff?url2=draft-ietf-pce-stateful-pce-optional-09


From: peng.sha...@zte.com.cn 
Sent: Friday, March 22, 2024 9:16 AM
To: Cheng Li 
Cc: pce@ietf.org; pce-cha...@ietf.org; 
draft-ietf-pce-stateful-pce-optio...@ietf.org; d...@dhruvdhody.com
Subject: Re: [Pce] WGLC for draft-ietf-pce-stateful-pce-optional-07




Hi Cheng,



Thanks for your response.



For the objects of intended-attribute-list and actual-attribute-list, I didn't 
treat them as mandatory ones. But just think that the document should also give 
some guidance text on those non mandatory objects. However, I don't insist on 
this point. Perhaps without this guidance, developers can handle it correctly.



BTW, I notice the updated version(08) section "3.2.2.  The PCUpd Message and 
the PCInitiate Message" may have a spelling mistake:

... ... ignored by the PCE or the object itself conveys informational ... ...

should PCE => PCC ?



Regards,

PSF








Original
From: ChengLi mailto:c...@huawei.com>>
To: 彭少富10053815;
Cc: pce@ietf.org<mailto:pce@ietf.org> 
mailto:pce@ietf.org>>;pce-cha...@ietf.org 
mailto:pce-cha...@ietf.org>>;draft-ietf-pce-stateful-pce-optio...@ietf.org
 
mailto:draft-ietf-pce-stateful-pce-optio...@ietf.org>>;Dhruv
 Dhody mailto:d...@dhruvdhody.com>>;
Date: 2024年03月13日 11:35
Subject: RE: [Pce] WGLC for draft-ietf-pce-stateful-pce-optional-07
Hi Shaofu,

Many thanks for your supports and comments.

Please see our reply below.

Thanks,
Cheng



On Fri, Mar 1, 2024 at 12:25 PM 
mailto:peng.sha...@zte.com.cn>> wrote:



Hi Chairs, WG,



I have read this document and find it is useful and support its forwarding.

Please see some comments as below:



[1]

In section 3.1. STATEFUL-PCE-CAPABILITY TLV, it said that



"When the PCEP session is established, a PCC sends an Open message with an OPEN 
object that contains the STATEFUL-PCE-CAPABILITY TLV, as defined in [RFC8231]."



This mislead us to understand it is after the session established. May change to



"During the PCEP initialization phase, ..."



[Cheng]Thanks! This is a good suggestion!



or change to

"When the TCP connection is established, ..."



[2]

In section 3.1. STATEFUL-PCE-CAPABILITY TLV, it said that



"R (RELAX bit - TBD1): If set to 1 by a PCEP Speaker, the R flag indicates that 
the PCEP Speaker is willing to send and receive PCEP objects with the P and I 
flags in the PCEP common object header for the stateful PCE messages."



This sentence is not clear because the P and I flags fields are already 
included in the PCEP objects. May change to



"R (RELAX bit - TBD1): If set to 1 by a PCEP Speaker, the R flag indicates that 
the PCEP Speaker is willing to handle the P and I flags in the PCEP common 
object header for the stateful PCE messages."



[Cheng]Another good suggestion.



[3]

For seciton 3.2.1. The PCRpt Message, it emphasizes that the P flag of 
mandatory object must be set. It may be more meaningful to provide guidance on 
the setting of the P flag for each object in intended-attribute-list and 
actual-attribute-list, that actually contain the constraints (e.g, bandwidth, 
metric) used for path computation .



[Cheng] Note that all the objects in both the intended-attribute-list and 
actual-attribute-list are optional as per the RBNF and thus would be incorrect 
to club them with mandatory objects.
Overall I don't think we can add any specifics. We can add an example but I am 
unsure how useful that is.



[4]

In 3.3.1. The PCUpd Message, it said that



"Note that when a PCE is unable to find the path that meets all the constraints 
as per the PCEP Object that cannot be ignored (i.e. P flag is set), the PCUpd 
message MAY optionally include the PCEP Objects that caused the path 
computation to fail along with the with the empty ERO."



"with the" in this paragraph is repeated.

[Cheng]Thanks!



Do you think that this paragraph should be moved to section 3.2.1 The PCRpt 
Message ? It seems actually to describe the procesing of P flag in PCRpt. If 
so, may changed to



[Cheng] No, we are following the format as set by RFC 5440 where this is 
described under the handling of I flag. Thus I would leave this unchanged.



"Note that when a PCE is unable to find the path that meets all the constraints 
as per the PCEP Object (carried in PCRpt message) that cannot be ignored (i.e. 
P flag is set), the subsequent PCUpd message MAY optionally include the PCEP 
Objects that caused the path computation t

Re: [Pce] WGLC for draft-ietf-pce-stateful-pce-optional-07

[peng.shaofu]

Hi Cheng,

Thanks for your response.

For the objects of intended-attribute-list and actual-attribute-list, I didn't 
treat them as mandatory ones. But just think that the document should also give 
some guidance text on those non mandatory objects. However, I don't insist on 
this point. Perhaps without this guidance, developers can handle it correctly.

BTW, I notice the updated version(08) section "3.2.2.  The PCUpd Message and 
the PCInitiate Message" may have a spelling mistake:
... ... ignored by the PCE or the object itself conveys informational ... ...
should PCE => PCC ?

Regards,
PSF





Original


From: ChengLi 
To: 彭少富10053815;
Cc: pce@ietf.org ;pce-cha...@ietf.org 
;draft-ietf-pce-stateful-pce-optio...@ietf.org 
;Dhruv Dhody 
;
Date: 2024年03月13日 11:35
Subject: RE: [Pce] WGLC for draft-ietf-pce-stateful-pce-optional-07



Hi Shaofu,
 
Many thanks for your supports and comments.
 
Please see our reply below.
 
Thanks,
Cheng
 
 
 

On Fri, Mar 1, 2024 at 12:25 PM  wrote:


 
Hi Chairs, WG,
 
I have read this document and find it is useful and support its forwarding.
Please see some comments as below:
 
[1]
In section 3.1. STATEFUL-PCE-CAPABILITY TLV, it said that 
 
"When the PCEP session is established, a PCC sends an Open message with an OPEN 
object that contains the STATEFUL-PCE-CAPABILITY TLV, as defined in [RFC8231]."
 
This mislead us to understand it is after the session established. May change to
 
"During the PCEP initialization phase, ..."
 



 

[Cheng]Thanks! This is a good suggestion! 


 


 

or change to 
"When the TCP connection is established, ..."
 
[2]
In section 3.1. STATEFUL-PCE-CAPABILITY TLV, it said that 
 
"R (RELAX bit - TBD1): If set to 1 by a PCEP Speaker, the R flag indicates that 
the PCEP Speaker is willing to send and receive PCEP objects with the P and I 
flags in the PCEP common object header for the stateful PCE messages."
 
This sentence is not clear because the P and I flags fields are already 
included in the PCEP objects. May change to
 
"R (RELAX bit - TBD1): If set to 1 by a PCEP Speaker, the R flag indicates that 
the PCEP Speaker is willing to handle the P and I flags in the PCEP common 
object header for the stateful PCE messages."
 



 

[Cheng]Another good suggestion.


 


 

[3]
For seciton 3.2.1. The PCRpt Message, it emphasizes that the P flag of 
mandatory object must be set. It may be more meaningful to provide guidance on 
the setting of the P flag for each object in intended-attribute-list and 
actual-attribute-list, that actually contain the constraints (e.g, bandwidth, 
metric) used for path computation .
 



 

[Cheng] Note that all the objects in both the intended-attribute-list and 
actual-attribute-list are optional as per the RBNF and thus would be incorrect 
to club them with mandatory objects. 



Overall I don't think we can add any specifics. We can add an example but I am 
unsure how useful that is. 


 


 

[4]
In 3.3.1. The PCUpd Message, it said that
 
"Note that when a PCE is unable to find the path that meets all the constraints 
as per the PCEP Object that cannot be ignored (i.e. P flag is set), the PCUpd 
message MAY optionally include the PCEP Objects that caused the path 
computation to fail along with the with the empty ERO."
 
"with the" in this paragraph is repeated. 



 

[Cheng]Thanks! 


 


 

Do you think that this paragraph should be moved to section 3.2.1 The PCRpt 
Message ? It seems actually to describe the procesing of P flag in PCRpt. If 
so, may changed to 
 



 

[Cheng] No, we are following the format as set by RFC 5440 where this is 
described under the handling of I flag. Thus I would leave this unchanged. 


 


 

"Note that when a PCE is unable to find the path that meets all the constraints 
as per the PCEP Object (carried in PCRpt message) that cannot be ignored (i.e. 
P flag is set), the subsequent PCUpd message MAY optionally include the PCEP 
Objects that caused the path computation to fail along with the with the empty 
ERO."
 
 
[5]
In 3.3.2. The PCRpt Message, it said that
 
"Note that when a PCC is unable to setup the path that meets all the parameters 
as per the PCEP Object that cannot be ignored (i.e. P flag is set), the PCRpt 
message MAY optionally include the PCEP Objects that caused the path setup to 
fail along with the LSP-ERROR-CODE TLV [RFC8231] indicating the reason for the 
failure."
 
Dos this paragraph also be moved to section 3.2.2. The PCUpd Message and the 
PCInitiate Message ? It seems actually to describe the procesing of P flag in 
PCUpd. If so, may changed to 
 



[Cheng] Lets leave this unchanged for the same reason as above! 


 


 

"Note that when a PCC is unable to setup the path that meets all the parameters 
as per the PCEP Object (carried in PCUpd message) that cannot be ignored (i.e. 
P flag is set), the subsequent PCRpt message MAY optiona

Re: [Pce] WGLC for draft-ietf-pce-stateful-pce-optional-07

[Cheng Li]

Thank you Chairs! We will update the draft according to the discussion in the 
Mailing list and post it when the window is reopen.

Best Regards,
Cheng


From: Dhruv Dhody 
Sent: Saturday, March 16, 2024 10:22 PM
To: pce@ietf.org
Cc: pce-chairs ; 
draft-ietf-pce-stateful-pce-optio...@ietf.org
Subject: Re: WGLC for draft-ietf-pce-stateful-pce-optional-07

Hi WG,

The WGLC is closed. Thanks for everyone's comments and feedback. The I-D is on 
agenda for IETF 119 to discuss the resolution for comments received.

The authors should update the draft based on the comment received and we will 
take the draft forward.

Thanks!
Dhruv & Julien

On Thu, Mar 7, 2024 at 8:21 PM Dhruv Dhody 
mailto:d...@dhruvdhody.com>> wrote:
Hi WG,

Considering this is a busy time just before the IETF meeting, we are extending 
the WGLC for a week. Please respond by Thursday March 14th. It is important to 
be explicitly vocal during the last call and we request you to please respond 
to this thread.

Thanks!
Dhruv

On Wed, Feb 21, 2024 at 3:02 PM Dhruv Dhody 
mailto:d...@dhruvdhody.com>> wrote:
Hi WG,

This email starts a 3-weeks working group last call for 
draft-ietf-pce-stateful-pce-optional-07.

https://www.ietf.org/archive/id/draft-ietf-pce-stateful-pce-optional-07.html

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 Wednesday 13 March 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
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] WGLC for draft-ietf-pce-stateful-pce-optional-07

[Samuel Sidor (ssidor)]

Hi Dhruv,

Yes, updated text is clear – thanks for providing it.

(and sorry for delay).

Regards,
Samuel

From: Dhruv Dhody 
Sent: Friday, March 15, 2024 7:06 AM
To: Samuel Sidor (ssidor) 
Cc: Cheng Li ; draft-ietf-pce-stateful-pce-optio...@ietf.org; 
pce-chairs ; pce@ietf.org
Subject: Re: [Pce] WGLC for draft-ietf-pce-stateful-pce-optional-07

Hi Samuel,

On Wed, Mar 13, 2024 at 6:44 PM Samuel Sidor (ssidor) 
mailto:ssi...@cisco.com>> wrote:
Hi Cheng,

Thanks a lot for your responses. Ack for all of them, new proposed version 
looks fine to me.

For “3.1 STATEFUL-PCE-CAPABILITY TLV section” I was really talking about 
objects defined in RFC5440, but used in stateful messages. Isn’t that behavior 
really “undefined” (before this draft)? Because RFC8231 is really talking only 
about new objects defined in that RFC (SRP, LSP,…) and not about older objects 
re-used in new PCEP messages.


Dhruv: You are correct - https://datatracker.ietf.org/doc/html/rfc8231#section-7

How about we extend the text like this -

   The R flag MUST be set by both a PCC and a PCE to indicate support
   for the handling of the P and I flag in the PCEP common object header
   to allow relaxing some constraints by marking objects as optional to
   process.  If the PCEP speaker did not set the R flag but receives
   PCEP objects with P or I bit set, it MUST behave as per the
   processing rule in [RFC8231].  Note that while [RFC8231] stated that
   P and I flags of the PCEP objects defined in [RFC8231] are set to 0
   on and ignored on receipt, it did not say anything about already
   existing PCEP objects and thus the behaviour remained undefined.  To
   safely use this future, both peers need to set the R flag.

Thanks!
Dhruv


Thanks,
Samuel

From: Cheng Li mailto:c...@huawei.com>>
Sent: Wednesday, March 13, 2024 4:46 AM
To: Samuel Sidor (ssidor) mailto:ssi...@cisco.com>>; 
draft-ietf-pce-stateful-pce-optio...@ietf.org<mailto:draft-ietf-pce-stateful-pce-optio...@ietf.org>
Cc: pce-chairs mailto:pce-cha...@ietf.org>>; 
pce@ietf.org<mailto:pce@ietf.org>; Dhruv Dhody 
mailto:d...@dhruvdhody.com>>
Subject: RE: [Pce] WGLC for draft-ietf-pce-stateful-pce-optional-07

Hi Samuel,

Many thanks for your quick review and support,.
Please see our reply below.

BTW, we post the proposed update to address your comments and Shaofu’s comments 
in Github:  https://github.com/muzixing/draft-ietf-pce-stateful-pce-optional

Thanks,
Cheng


From: Samuel Sidor (ssidor) mailto:ssi...@cisco.com>>
Sent: Tuesday, March 12, 2024 11:00 PM
To: 
draft-ietf-pce-stateful-pce-optio...@ietf.org<mailto:draft-ietf-pce-stateful-pce-optio...@ietf.org>
Cc: pce-chairs mailto:pce-cha...@ietf.org>>; 
pce@ietf.org<mailto:pce@ietf.org>; Dhruv Dhody 
mailto:d...@dhruvdhody.com>>
Subject: RE: [Pce] WGLC for draft-ietf-pce-stateful-pce-optional-07

Hi authors of this draft,

I support this draft, but I still have a few minor comments:

1.Introduction section:

  *   “Generalzied MPLS (GMPLS) tunnels.” -> typo
[Cheng]Ack.

  *   “…allow a PCC to specify in a Path Computation Request (PCReq) message 
(sent to a PCE) whether the object must be taken into account by the PCE during 
path computation or is optional” -> do we even need to specify that PCReq is 
sent to PCE?
[Cheng] I don’t see any harm .


2.1 Usage Example section:

  *   Is really “Disjoint Association” good example as that constraint itself 
has T flag defined in 
https://www.rfc-editor.org/rfc/rfc8800.html#name-disjoint-tlvs, which is 
allowing relaxing disjointness constraint completely as well (so P=0 for 
association object is not really required for that specific case) Maybe 
consider using some other constraint as an example, why we need this.
[Cheng] A good point! I think we can remove the association example itself for 
simplicity's sake.


3.1 STATEFUL-PCE-CAPABILITY TLV section

  *   “In case the bit is unset, it indicates that the PCEP Speaker would not 
handle the P and I flags in the PCEP common object header for stateful PCE 
messages” – At least “Introduction” section is saying that behavior was not 
defined before this draft was written for older PCEP objects in Stateful 
messages, so isn’t it actually required to fallback to original “undefined” 
behavior if flag is not set instead of doing fallback to “PCEP peer is not 
using them”? We should probably have some “backward compatibility” section as 
we don’t have simple way to figure out whether flag is explicitly cleared or 
just not supported.

[Cheng]  No, the introduction says -
   Stateful PCE
   [RFC8231] specified that the P and I flags of the PCEP objects
   defined in [RFC8231] is to be set to zero on transmission and ignored
   on receipt, since they are exclusively related to path computation
   requests.

Maybe the word 'clarify' later on is misleading and I have changed that 
everywhere!

Since the behavior is not undefined any legacy implementation will 

Re: [Pce] WGLC for draft-ietf-pce-stateful-pce-optional-07

[Dhruv Dhody]

Hi WG,

The WGLC is closed. Thanks for everyone's comments and feedback. The I-D is
on agenda for IETF 119 to discuss the resolution for comments received.

The authors should update the draft based on the comment received and we
will take the draft forward.

Thanks!
Dhruv & Julien

On Thu, Mar 7, 2024 at 8:21 PM Dhruv Dhody  wrote:

> Hi WG,
>
> Considering this is a busy time just before the IETF meeting, we are
> extending the WGLC for a week. Please respond by Thursday March 14th. It is
> important to be explicitly vocal during the last call and we request you to
> please respond to this thread.
>
> Thanks!
> Dhruv
>
> On Wed, Feb 21, 2024 at 3:02 PM Dhruv Dhody  wrote:
>
>> Hi WG,
>>
>> This email starts a 3-weeks working group last call for
>> draft-ietf-pce-stateful-pce-optional-07.
>>
>>
>> https://www.ietf.org/archive/id/draft-ietf-pce-stateful-pce-optional-07.html
>>
>> 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 Wednesday 13 March 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
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] WGLC for draft-ietf-pce-stateful-pce-optional-07

[Dhruv Dhody]

Hi Samuel,

On Wed, Mar 13, 2024 at 6:44 PM Samuel Sidor (ssidor) 
wrote:

> Hi Cheng,
>
>
>
> Thanks a lot for your responses. Ack for all of them, new proposed version
> looks fine to me.
>
>
>
> For “3.1 STATEFUL-PCE-CAPABILITY TLV section” I was really talking about
> objects defined in RFC5440, but used in stateful messages. Isn’t that
> behavior really “undefined” (before this draft)? Because RFC8231 is really
> talking only about new objects defined in that RFC (SRP, LSP,…) and not
> about older objects re-used in new PCEP messages.
>
>
>

Dhruv: You are correct -
https://datatracker.ietf.org/doc/html/rfc8231#section-7

How about we extend the text like this -

   The R flag MUST be set by both a PCC and a PCE to indicate support
   for the handling of the P and I flag in the PCEP common object header
   to allow relaxing some constraints by marking objects as optional to
   process.  If the PCEP speaker did not set the R flag but receives
   PCEP objects with P or I bit set, it MUST behave as per the
   processing rule in [RFC8231].  Note that while [RFC8231] stated that
   P and I flags of the PCEP objects defined in [RFC8231] are set to 0
   on and ignored on receipt, it did not say anything about already
   existing PCEP objects and thus the behaviour remained undefined.  To
   safely use this future, both peers need to set the R flag.

Thanks!
Dhruv



> Thanks,
>
> Samuel
>
>
>
> *From:* Cheng Li 
> *Sent:* Wednesday, March 13, 2024 4:46 AM
> *To:* Samuel Sidor (ssidor) ;
> draft-ietf-pce-stateful-pce-optio...@ietf.org
> *Cc:* pce-chairs ; pce@ietf.org; Dhruv Dhody <
> d...@dhruvdhody.com>
> *Subject:* RE: [Pce] WGLC for draft-ietf-pce-stateful-pce-optional-07
>
>
>
> Hi Samuel,
>
>
>
> Many thanks for your quick review and support,.
>
> Please see our reply below.
>
>
>
> BTW, we post the proposed update to address your comments and Shaofu’s
> comments in Github:
> https://github.com/muzixing/draft-ietf-pce-stateful-pce-optional
>
>
>
> Thanks,
>
> Cheng
>
>
>
>
>
> *From:* Samuel Sidor (ssidor) 
> *Sent:* Tuesday, March 12, 2024 11:00 PM
> *To:* draft-ietf-pce-stateful-pce-optio...@ietf.org
> *Cc:* pce-chairs ; pce@ietf.org; Dhruv Dhody <
> d...@dhruvdhody.com>
> *Subject:* RE: [Pce] WGLC for draft-ietf-pce-stateful-pce-optional-07
>
>
>
> Hi authors of this draft,
>
>
>
> I support this draft, but I still have a few minor comments:
>
>
>
> 1.Introduction section:
>
>- “Generalzied MPLS (GMPLS) tunnels.” -> typo
>
> [Cheng]Ack.
>
>- “…allow a PCC to specify in a Path Computation Request (PCReq)
>message *(sent to a PCE)* whether the object must be taken into
>account *by the PCE* during path computation or is optional” -> do we
>even need to specify that PCReq is sent to PCE?
>
> [Cheng] I don’t see any harm .
>
>
>
>
>
> 2.1 Usage Example section:
>
>- Is really “Disjoint Association” good example as that constraint
>itself has T flag defined in
>https://www.rfc-editor.org/rfc/rfc8800.html#name-disjoint-tlvs, which
>is allowing relaxing disjointness constraint completely as well (so P=0 for
>association object is not really required for that specific case) Maybe
>consider using some other constraint as an example, why we need this.
>
> [Cheng] A good point! I think we can remove the association example itself
> for simplicity's sake.
>
>
>
>
>
> 3.1 STATEFUL-PCE-CAPABILITY TLV section
>
>- “In case the bit is unset, it indicates that the PCEP Speaker would
>not handle the P and I flags in the PCEP common object header for stateful
>PCE messages” – At least “Introduction” section is saying that
>behavior was not defined before this draft was written for older PCEP
>objects in Stateful messages, so isn’t it actually required to fallback to
>original “undefined” behavior if flag is not set instead of doing fallback
>to “PCEP peer is not using them”? We should probably have some “backward
>compatibility” section as we don’t have simple way to figure out whether
>flag is explicitly cleared or just not supported.
>
>
>
> [Cheng]  No, the introduction says -
>Stateful PCE
>[RFC8231] specified that the P and I flags of the PCEP objects
>defined in [RFC8231] is to be set to zero on transmission and ignored
>on receipt, since they are exclusively related to path computation
>requests.
>
>
>
> Maybe the word 'clarify' later on is misleading and I have changed that
> everywhere!
>
>
>
> Since the behavior is not undefined any legacy implementation will always
> ignore it and wit

Re: [Pce] WGLC for draft-ietf-pce-stateful-pce-optional-07

[????????????]

Hi All,

I have read the latest version and support the publication of this 
draft.
Best regards
Xinxin Yi


Re: [Pce] WGLC for draft-ietf-pce-stateful-pce-optional-07

Dhruv Dhody  Thu, 07 March 2024 10:22 UTCShow 
header<https://mailarchive.ietf.org/arch/browse/pce/?q=draft-ietf-pce-stateful-pce-optional#>

Hi WG,
Considering this is a busy time just before the IETF meeting, we are
extending the WGLC for a week. Please respond by Thursday March 14th. It is
important to be explicitly vocal during the last call and we request you to
please respond to this thread.
Thanks!
Dhruv
On Wed, Feb 21, 2024 at 3:02 PM Dhruv Dhody 
<mailto:d...@dhruvdhody.com;> wrote:
> Hi WG,
>
> This email starts a 3-weeks working group last call for
> draft-ietf-pce-stateful-pce-optional-07.
>
>
> https://www.ietf.org/archive/id/draft-ietf-pce-stateful-pce-optional-07.html
>
> 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 Wednesday 13 March 2024.
>
> A general reminder to the WG to be more vocal during the
> last-call/adoption.
>
> Thanks,
> Dhruv & Julien
>

如果您错误接收了该邮件，请通过电子邮件立即通知我们。请回复邮件到 
hqs-s...@chinaunicom.cn，即可以退订此邮件。我们将立即将您的信息从我们的发送目录中删除。 If you have received 
this email in error please notify us immediately by e-mail. Please reply to 
hqs-s...@chinaunicom.cn ,you can unsubscribe from this mail. We will 
immediately remove your information from send catalogue of our.
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] WGLC for draft-ietf-pce-stateful-pce-optional-07

[Chongfeng Xie]

Hi folks,
I support the WG LC of this document and think it ready for publication.

Best regards
Chongfeng
 
From: Dhruv Dhody
Date: 2024-02-21 17:32
To: pce@ietf.org
CC: pce-chairs; draft-ietf-pce-stateful-pce-optio...@ietf.org
Subject: WGLC for draft-ietf-pce-stateful-pce-optional-07
Hi WG,

This email starts a 3-weeks working group last call for 
draft-ietf-pce-stateful-pce-optional-07.

https://www.ietf.org/archive/id/draft-ietf-pce-stateful-pce-optional-07.html

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 Wednesday 13 March 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
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] WGLC for draft-ietf-pce-stateful-pce-optional-07

[岳胜男]

 Hi All,I read the latest version and support the publication of this 
draft. 
Best Regards,Shengnan Yue

-- Forwarded message -From: Pce  On 
Behalf Of Dhruv Dhody
Sent: Wednesday, February 21, 2024 5:33 PM
To: pce@ietf.org
Cc: pce-chairs  
draft-ietf-pce-stateful-pce-optio...@ietf.org
Subject: [Pce] WGLC for draft-ietf-pce-stateful-pce-optional-07

Hi WG,

This email starts a 3-weeks working group last call for 
draft-ietf-pce-stateful-pce-optional-07.

https://www.ietf.org/archive/id/draft-ietf-pce-stateful-pce-optional-07.html

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 Wednesday 13 March 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
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] WGLC for draft-ietf-pce-stateful-pce-optional-07

[Samuel Sidor (ssidor)]

Hi Cheng,

Thanks a lot for your responses. Ack for all of them, new proposed version 
looks fine to me.

For “3.1 STATEFUL-PCE-CAPABILITY TLV section” I was really talking about 
objects defined in RFC5440, but used in stateful messages. Isn’t that behavior 
really “undefined” (before this draft)? Because RFC8231 is really talking only 
about new objects defined in that RFC (SRP, LSP,…) and not about older objects 
re-used in new PCEP messages.

Thanks,
Samuel

From: Cheng Li 
Sent: Wednesday, March 13, 2024 4:46 AM
To: Samuel Sidor (ssidor) ; 
draft-ietf-pce-stateful-pce-optio...@ietf.org
Cc: pce-chairs ; pce@ietf.org; Dhruv Dhody 

Subject: RE: [Pce] WGLC for draft-ietf-pce-stateful-pce-optional-07

Hi Samuel,

Many thanks for your quick review and support,.
Please see our reply below.

BTW, we post the proposed update to address your comments and Shaofu’s comments 
in Github:  https://github.com/muzixing/draft-ietf-pce-stateful-pce-optional

Thanks,
Cheng


From: Samuel Sidor (ssidor) mailto:ssi...@cisco.com>>
Sent: Tuesday, March 12, 2024 11:00 PM
To: 
draft-ietf-pce-stateful-pce-optio...@ietf.org<mailto:draft-ietf-pce-stateful-pce-optio...@ietf.org>
Cc: pce-chairs mailto:pce-cha...@ietf.org>>; 
pce@ietf.org<mailto:pce@ietf.org>; Dhruv Dhody 
mailto:d...@dhruvdhody.com>>
Subject: RE: [Pce] WGLC for draft-ietf-pce-stateful-pce-optional-07

Hi authors of this draft,

I support this draft, but I still have a few minor comments:

1.Introduction section:

  *   “Generalzied MPLS (GMPLS) tunnels.” -> typo
[Cheng]Ack.

  *   “…allow a PCC to specify in a Path Computation Request (PCReq) message 
(sent to a PCE) whether the object must be taken into account by the PCE during 
path computation or is optional” -> do we even need to specify that PCReq is 
sent to PCE?
[Cheng] I don’t see any harm .


2.1 Usage Example section:

  *   Is really “Disjoint Association” good example as that constraint itself 
has T flag defined in 
https://www.rfc-editor.org/rfc/rfc8800.html#name-disjoint-tlvs, which is 
allowing relaxing disjointness constraint completely as well (so P=0 for 
association object is not really required for that specific case) Maybe 
consider using some other constraint as an example, why we need this.
[Cheng] A good point! I think we can remove the association example itself for 
simplicity's sake.


3.1 STATEFUL-PCE-CAPABILITY TLV section

  *   “In case the bit is unset, it indicates that the PCEP Speaker would not 
handle the P and I flags in the PCEP common object header for stateful PCE 
messages” – At least “Introduction” section is saying that behavior was not 
defined before this draft was written for older PCEP objects in Stateful 
messages, so isn’t it actually required to fallback to original “undefined” 
behavior if flag is not set instead of doing fallback to “PCEP peer is not 
using them”? We should probably have some “backward compatibility” section as 
we don’t have simple way to figure out whether flag is explicitly cleared or 
just not supported.

[Cheng]  No, the introduction says -
   Stateful PCE
   [RFC8231] specified that the P and I flags of the PCEP objects
   defined in [RFC8231] is to be set to zero on transmission and ignored
   on receipt, since they are exclusively related to path computation
   requests.

Maybe the word 'clarify' later on is misleading and I have changed that 
everywhere!

Since the behavior is not undefined any legacy implementation will always 
ignore it and with the help of this flag in capability exchange we can be sure 
that there is no backward compatibility issue.



3.2.2 The PCUpd Message and the PCInitiate Message

  *   Is it really required to assume P flag set to all PCEP objects in 
PCUpd/PCinit messages? Consider PCE including for example accumulated metric or 
constraints used in the path-computation for policies configured on PCC – why 
PCC would need to support all of those objects even if really just 
“SRP/LSP/ERO” is really required in most of the cases? I would say that even 
“SHOULD” may be too strong here.

[Cheng]  I can soften this to say - "On a PCEP session on which R bit was set 
by both peers, the PCE SHOULD set the P flag by default, unless a local 
configuration/policy indicates that some constraints (corresponding PCEP 
objects) can be marked as optional and could be ignored by the PCE or the 
object itself conveys informational parameters that can be safely ignored."


3.4 Delegation

  *   “Note that for the delegated LSPs, the PCE can update and mark some 
objects as ignored even when the PCC had set the P flag during delegation. 
Similarly, the PCE can update…” – Is there valid use-case for this behavior? At 
least to me it seems that it actually opening doors for bugs/misinterpretation 
rather than really adding any value.
[Cheng] There was feedback for this to keep it aligned with the definition of 
delegation in RFC 8231 where PCE ought to have control over all parame

Re: [Pce] WGLC for draft-ietf-pce-stateful-pce-optional-07

[Shihang(Vincent)]

Hi WG,
I have read the draft and support its publication. It is a simple and useful 
extension.

Thanks,
Hang

From: Pce  On Behalf Of Dhruv Dhody
Sent: Wednesday, February 21, 2024 5:33 PM
To: pce@ietf.org
Cc: pce-chairs ; 
draft-ietf-pce-stateful-pce-optio...@ietf.org
Subject: [Pce] WGLC for draft-ietf-pce-stateful-pce-optional-07

Hi WG,

This email starts a 3-weeks working group last call for 
draft-ietf-pce-stateful-pce-optional-07.

https://www.ietf.org/archive/id/draft-ietf-pce-stateful-pce-optional-07.html

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 Wednesday 13 March 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
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] WGLC for draft-ietf-pce-stateful-pce-optional-07

[Maojianwei (Mao)]

Hi WG,

I have read through this draft. The extensions are simple and efficient. I 
support that it is ready to be published.


Cheers,
Mao


发件人: Dhruv Dhody 
发送时间: 2024年2月21日 17:33
收件人: pce@ietf.org
抄送: pce-chairs ; 
draft-ietf-pce-stateful-pce-optio...@ietf.org
主题: WGLC for draft-ietf-pce-stateful-pce-optional-07

Hi WG,

This email starts a 3-weeks working group last call for 
draft-ietf-pce-stateful-pce-optional-07.

https://www.ietf.org/archive/id/draft-ietf-pce-stateful-pce-optional-07.html

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 Wednesday 13 March 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
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] WGLC for draft-ietf-pce-stateful-pce-optional-07

[Zhangka]

Hi WG,

I have read the latest version of draft-ietf-pce-stateful-pce-optional-07 and I 
think it is ready for publication.
So I support the last call of it.

Thanks,
Ka


From: Dhruv Dhody [mailto:d...@dhruvdhody.com]
Sent: Wednesday, February 21, 2024 5:33 PM
To: pce@ietf.org
Cc: pce-chairs ; 
draft-ietf-pce-stateful-pce-optio...@ietf.org
Subject: WGLC for draft-ietf-pce-stateful-pce-optional-07

Hi WG,

This email starts a 3-weeks working group last call for 
draft-ietf-pce-stateful-pce-optional-07.

https://www.ietf.org/archive/id/draft-ietf-pce-stateful-pce-optional-07.html

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 Wednesday 13 March 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
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] WGLC for draft-ietf-pce-stateful-pce-optional-07

[Cheng Li]

Hi Samuel,

Many thanks for your quick review and support,.
Please see our reply below.

BTW, we post the proposed update to address your comments and Shaofu’s comments 
in Github:  https://github.com/muzixing/draft-ietf-pce-stateful-pce-optional

Thanks,
Cheng


From: Samuel Sidor (ssidor) 
Sent: Tuesday, March 12, 2024 11:00 PM
To: draft-ietf-pce-stateful-pce-optio...@ietf.org
Cc: pce-chairs ; pce@ietf.org; Dhruv Dhody 

Subject: RE: [Pce] WGLC for draft-ietf-pce-stateful-pce-optional-07

Hi authors of this draft,

I support this draft, but I still have a few minor comments:

1.Introduction section:

  *   “Generalzied MPLS (GMPLS) tunnels.” -> typo
[Cheng]Ack.

  *   “…allow a PCC to specify in a Path Computation Request (PCReq) message 
(sent to a PCE) whether the object must be taken into account by the PCE during 
path computation or is optional” -> do we even need to specify that PCReq is 
sent to PCE?
[Cheng] I don’t see any harm .


2.1 Usage Example section:

  *   Is really “Disjoint Association” good example as that constraint itself 
has T flag defined in 
https://www.rfc-editor.org/rfc/rfc8800.html#name-disjoint-tlvs, which is 
allowing relaxing disjointness constraint completely as well (so P=0 for 
association object is not really required for that specific case) Maybe 
consider using some other constraint as an example, why we need this.
[Cheng] A good point! I think we can remove the association example itself for 
simplicity's sake.


3.1 STATEFUL-PCE-CAPABILITY TLV section

  *   “In case the bit is unset, it indicates that the PCEP Speaker would not 
handle the P and I flags in the PCEP common object header for stateful PCE 
messages” – At least “Introduction” section is saying that behavior was not 
defined before this draft was written for older PCEP objects in Stateful 
messages, so isn’t it actually required to fallback to original “undefined” 
behavior if flag is not set instead of doing fallback to “PCEP peer is not 
using them”? We should probably have some “backward compatibility” section as 
we don’t have simple way to figure out whether flag is explicitly cleared or 
just not supported.

[Cheng]  No, the introduction says -
   Stateful PCE
   [RFC8231] specified that the P and I flags of the PCEP objects
   defined in [RFC8231] is to be set to zero on transmission and ignored
   on receipt, since they are exclusively related to path computation
   requests.

Maybe the word 'clarify' later on is misleading and I have changed that 
everywhere!

Since the behavior is not undefined any legacy implementation will always 
ignore it and with the help of this flag in capability exchange we can be sure 
that there is no backward compatibility issue.



3.2.2 The PCUpd Message and the PCInitiate Message

  *   Is it really required to assume P flag set to all PCEP objects in 
PCUpd/PCinit messages? Consider PCE including for example accumulated metric or 
constraints used in the path-computation for policies configured on PCC – why 
PCC would need to support all of those objects even if really just 
“SRP/LSP/ERO” is really required in most of the cases? I would say that even 
“SHOULD” may be too strong here.

[Cheng]  I can soften this to say - "On a PCEP session on which R bit was set 
by both peers, the PCE SHOULD set the P flag by default, unless a local 
configuration/policy indicates that some constraints (corresponding PCEP 
objects) can be marked as optional and could be ignored by the PCE or the 
object itself conveys informational parameters that can be safely ignored."


3.4 Delegation

  *   “Note that for the delegated LSPs, the PCE can update and mark some 
objects as ignored even when the PCC had set the P flag during delegation. 
Similarly, the PCE can update…” – Is there valid use-case for this behavior? At 
least to me it seems that it actually opening doors for bugs/misinterpretation 
rather than really adding any value.
[Cheng] There was feedback for this to keep it aligned with the definition of 
delegation in RFC 8231 where PCE ought to have control over all parameters 
including this relaxation.


7.1 Control of Function and Policy

  *   “An operator MUST be allowed to configure the capability to support 
relaxation of constraints in the stateful PCEP message exchange.” – So any 
implementation which would decide to enable it by default in that PCEP session 
is not RFC complaint? Isn’t that too strict?
[Cheng] This can be changed to SHOULD -> "An implementation supporting this 
document SHOULD allow configuration of the capability..."


Thanks a lot,
Samuel

From: Pce mailto:pce-boun...@ietf.org>> On Behalf Of 
Dhruv Dhody
Sent: Wednesday, February 21, 2024 10:33 AM
To: pce@ietf.org<mailto:pce@ietf.org>
Cc: pce-chairs mailto:pce-cha...@ietf.org>>; 
draft-ietf-pce-stateful-pce-optio...@ietf.org<mailto:draft-ietf-pce-stateful-pce-optio...@ietf.org>
Subject: [Pce] WGLC for draft-ietf-pce-stateful-pce-optional-

Re: [Pce] WGLC for draft-ietf-pce-stateful-pce-optional-07

[Cheng Li]

ording. And change MUST to SHOULD in section 3.2.

Thanks!





Regards,

PSF




Original
From: DhruvDhody mailto:d...@dhruvdhody.com>>
To: pce@ietf.org<mailto:pce@ietf.org> mailto:pce@ietf.org>>;
Cc: pce-chairs 
mailto:pce-cha...@ietf.org>>;draft-ietf-pce-stateful-pce-optio...@ietf.org<mailto:draft-ietf-pce-stateful-pce-optio...@ietf.org>
 
mailto:draft-ietf-pce-stateful-pce-optio...@ietf.org>>;
Date: 2024年02月21日 17:33
Subject: [Pce] WGLC for draft-ietf-pce-stateful-pce-optional-07
___
Pce mailing list
Pce@ietf.org<mailto:Pce@ietf.org>
https://www.ietf.org/mailman/listinfo/pce
Hi WG,

This email starts a 3-weeks working group last call for 
draft-ietf-pce-stateful-pce-optional-07.

https://www.ietf.org/archive/id/draft-ietf-pce-stateful-pce-optional-07.html

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 Wednesday 13 March 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<mailto: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] WGLC for draft-ietf-pce-stateful-pce-optional-07

[Samuel Sidor (ssidor)]

Hi authors of this draft,

I support this draft, but I still have a few minor comments:

1.Introduction section:

  *   “Generalzied MPLS (GMPLS) tunnels.” -> typo
  *   “…allow a PCC to specify in a Path Computation Request (PCReq) message 
(sent to a PCE) whether the object must be taken into account by the PCE during 
path computation or is optional” -> do we even need to specify that PCReq is 
sent to PCE?
2.1 Usage Example section:

  *   Is really “Disjoint Association” good example as that constraint itself 
has T flag defined in 
https://www.rfc-editor.org/rfc/rfc8800.html#name-disjoint-tlvs, which is 
allowing relaxing disjointness constraint completely as well (so P=0 for 
association object is not really required for that specific case) Maybe 
consider using some other constraint as an example, why we need this.
3.1 STATEFUL-PCE-CAPABILITY TLV section

  *   “In case the bit is unset, it indicates that the PCEP Speaker would not 
handle the P and I flags in the PCEP common object header for stateful PCE 
messages” – At least “Introduction” section is saying that behavior was not 
defined before this draft was written for older PCEP objects in Stateful 
messages, so isn’t it actually required to fallback to original “undefined” 
behavior if flag is not set instead of doing fallback to “PCEP peer is not 
using them”? We should probably have some “backward compatibility” section as 
we don’t have simple way to figure out whether flag is explicitly cleared or 
just not supported.
3.2.2 The PCUpd Message and the PCInitiate Message

  *   Is it really required to assume P flag set to all PCEP objects in 
PCUpd/PCinit messages? Consider PCE including for example accumulated metric or 
constraints used in the path-computation for policies configured on PCC – why 
PCC would need to support all of those objects even if really just 
“SRP/LSP/ERO” is really required in most of the cases? I would say that even 
“SHOULD” may be too strong here.
3.4 Delegation

  *   “Note that for the delegated LSPs, the PCE can update and mark some 
objects as ignored even when the PCC had set the P flag during delegation. 
Similarly, the PCE can update…” – Is there valid use-case for this behavior? At 
least to me it seems that it actually opening doors for bugs/misinterpretation 
rather than really adding any value.
7.1 Control of Function and Policy

  *   “An operator MUST be allowed to configure the capability to support 
relaxation of constraints in the stateful PCEP message exchange.” – So any 
implementation which would decide to enable it by default in that PCEP session 
is not RFC complaint? Isn’t that too strict?

Thanks a lot,
Samuel

From: Pce  On Behalf Of Dhruv Dhody
Sent: Wednesday, February 21, 2024 10:33 AM
To: pce@ietf.org
Cc: pce-chairs ; 
draft-ietf-pce-stateful-pce-optio...@ietf.org
Subject: [Pce] WGLC for draft-ietf-pce-stateful-pce-optional-07

Hi WG,

This email starts a 3-weeks working group last call for 
draft-ietf-pce-stateful-pce-optional-07.

https://www.ietf.org/archive/id/draft-ietf-pce-stateful-pce-optional-07.html

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 Wednesday 13 March 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
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] WGLC for draft-ietf-pce-stateful-pce-optional-07

[Zhenghaomian]

Hi WG,

I have read the document and think it is ready for publication, thanks.

Best wishes,
Haomian (as co-author)

From: Dhruv Dhody [mailto:d...@dhruvdhody.com]
Sent: Wednesday, February 21, 2024 5:33 PM
To: pce@ietf.org
Cc: pce-chairs ; 
draft-ietf-pce-stateful-pce-optio...@ietf.org
Subject: WGLC for draft-ietf-pce-stateful-pce-optional-07

Hi WG,

This email starts a 3-weeks working group last call for 
draft-ietf-pce-stateful-pce-optional-07.

https://www.ietf.org/archive/id/draft-ietf-pce-stateful-pce-optional-07.html

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 Wednesday 13 March 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
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] WGLC for draft-ietf-pce-stateful-pce-optional-07

[Cheng Li]

Oh no! It seems like this email is missing over the email sea.
Crazy busy weeks before IETF Meeting.

Yes, I support the publication of this draft as one of the author. Will 
response to the comments ASAP after the IETF119 meeting.;

Thanks,
Cheng


From: Dhruv Dhody 
Sent: Wednesday, February 21, 2024 5:33 PM
To: pce@ietf.org
Cc: pce-chairs ; 
draft-ietf-pce-stateful-pce-optio...@ietf.org
Subject: WGLC for draft-ietf-pce-stateful-pce-optional-07

Hi WG,

This email starts a 3-weeks working group last call for 
draft-ietf-pce-stateful-pce-optional-07.

https://www.ietf.org/archive/id/draft-ietf-pce-stateful-pce-optional-07.html

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 Wednesday 13 March 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
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] WGLC for draft-ietf-pce-stateful-pce-optional-07

[Dhruv Dhody]

Hi WG,

Considering this is a busy time just before the IETF meeting, we are
extending the WGLC for a week. Please respond by Thursday March 14th. It is
important to be explicitly vocal during the last call and we request you to
please respond to this thread.

Thanks!
Dhruv

On Wed, Feb 21, 2024 at 3:02 PM Dhruv Dhody  wrote:

> Hi WG,
>
> This email starts a 3-weeks working group last call for
> draft-ietf-pce-stateful-pce-optional-07.
>
>
> https://www.ietf.org/archive/id/draft-ietf-pce-stateful-pce-optional-07.html
>
> 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 Wednesday 13 March 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
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] WGLC for draft-ietf-pce-stateful-pce-optional-07

[peng.shaofu]

Hi Chairs, WG,

I have read this document and find it is useful and support its forwarding.
Please see some comments as below:

[1]
In section 3.1. STATEFUL-PCE-CAPABILITY TLV, it said that 

"When the PCEP session is established, a PCC sends an Open message with an OPEN 
object that contains the STATEFUL-PCE-CAPABILITY TLV, as defined in [RFC8231]."

This mislead us to understand it is after the session established. May change to

"During the PCEP initialization phase, ..."

or change to 
"When the TCP connection is established, ..."

[2]
In section 3.1. STATEFUL-PCE-CAPABILITY TLV, it said that 

"R (RELAX bit - TBD1): If set to 1 by a PCEP Speaker, the R flag indicates that 
the PCEP Speaker is willing to send and receive PCEP objects with the P and I 
flags in the PCEP common object header for the stateful PCE messages."

This sentence is not clear because the P and I flags fields are already 
included in the PCEP objects. May change to

"R (RELAX bit - TBD1): If set to 1 by a PCEP Speaker, the R flag indicates that 
the PCEP Speaker is willing to handle the P and I flags in the PCEP common 
object header for the stateful PCE messages."

[3]
For seciton 3.2.1. The PCRpt Message, it emphasizes that the P flag of 
mandatory object must be set. It may be more meaningful to provide guidance on 
the setting of the P flag for each object in intended-attribute-list and 
actual-attribute-list, that actually contain the constraints (e.g, bandwidth, 
metric) used for path computation .

[4]
In 3.3.1. The PCUpd Message, it said that

"Note that when a PCE is unable to find the path that meets all the constraints 
as per the PCEP Object that cannot be ignored (i.e. P flag is set), the PCUpd 
message MAY optionally include the PCEP Objects that caused the path 
computation to fail along with the with the empty ERO."

"with the" in this paragraph is repeated. 
Do you think that this paragraph should be moved to section 3.2.1 The PCRpt 
Message ? It seems actually to describe the procesing of P flag in PCRpt. If 
so, may changed to 

"Note that when a PCE is unable to find the path that meets all the constraints 
as per the PCEP Object (carried in PCRpt message) that cannot be ignored (i.e. 
P flag is set), the subsequent PCUpd message MAY optionally include the PCEP 
Objects that caused the path computation to fail along with the with the empty 
ERO."


[5]
In 3.3.2. The PCRpt Message, it said that

"Note that when a PCC is unable to setup the path that meets all the parameters 
as per the PCEP Object that cannot be ignored (i.e. P flag is set), the PCRpt 
message MAY optionally include the PCEP Objects that caused the path setup to 
fail along with the LSP-ERROR-CODE TLV [RFC8231] indicating the reason for the 
failure."

Dos this paragraph also be moved to section 3.2.2. The PCUpd Message and the 
PCInitiate Message ? It seems actually to describe the procesing of P flag in 
PCUpd. If so, may changed to 

"Note that when a PCC is unable to setup the path that meets all the parameters 
as per the PCEP Object (carried in PCUpd message) that cannot be ignored (i.e. 
P flag is set), the subsequent PCRpt message MAY optionally include the PCEP 
Objects that caused the path setup to fail along with the LSP-ERROR-CODE TLV 
[RFC8231] indicating the reason for the failure."

[6]
In section 3.4. Delegation, it said that

"Note that for the delegated LSPs, the PCE can update and mark some objects as 
ignored even when the PCC had set the P flag during delegation. Similarly, the 
PCE can update and mark some object as a must to process even when the PCC had 
not set the P flag during delegation."

I think this statement conflicts with the previous section 3.2 (which gives the 
impression that it is actually an active state of PCE mode, which naturally 
includes delegation). But this paragraph makes P flag no longer obeyed by PCE, 
which is confusing. Maybe I misunderstood.


Regards,
PSF



Original


From: DhruvDhody 
To: pce@ietf.org ;
Cc: pce-chairs 
;draft-ietf-pce-stateful-pce-optio...@ietf.org 
;
Date: 2024年02月21日 17:33
Subject: [Pce] WGLC for draft-ietf-pce-stateful-pce-optional-07

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




Hi WG,

This email starts a 3-weeks working group last call for 
draft-ietf-pce-stateful-pce-optional-07.


https://www.ietf.org/archive/id/draft-ietf-pce-stateful-pce-optional-07.html

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 Wednesday 13 March 2024.

A general reminder to the WG to be more vocal during 

[Pce] WGLC for draft-ietf-pce-stateful-pce-optional-07

[Dhruv Dhody]

Hi WG,

This email starts a 3-weeks working group last call for
draft-ietf-pce-stateful-pce-optional-07.

https://www.ietf.org/archive/id/draft-ietf-pce-stateful-pce-optional-07.html

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 Wednesday 13 March 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
https://www.ietf.org/mailman/listinfo/pce