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 <c...@huawei.com>
To: 彭少富10053815;
Cc: pce@ietf.org <pce@ietf.org>;pce-cha...@ietf.org
<pce-cha...@ietf.org>;draft-ietf-pce-stateful-pce-optio...@ietf.org
<draft-ietf-pce-stateful-pce-optio...@ietf.org>;Dhruv Dhody
<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 <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 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 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.
[Cheng] I can see how this could be confusing. I propose moving section 3.4
under 3.2.1 and doing some rewording. And change MUST to SHOULD in section 3.2.
Thanks!
Regards,
PSF
Original
From: DhruvDhody <d...@dhruvdhody.com>
To: pce@ietf.org <pce@ietf.org>;
Cc: pce-chairs
<pce-cha...@ietf.org>;draft-ietf-pce-stateful-pce-optio...@ietf.org
<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 the last-call/adoption.
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
