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

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

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
>

如果您错误接收了该邮件，请通过电子邮件立即通知我们。请回复邮件到 
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