Hi Andrew, Thanks for your feedback.
On Wed, Oct 16, 2024 at 12:53 AM Andrew Stone (Nokia) < andrew.st...@nokia.com> wrote: > Hi PCE WG, authors, > > > > Some comments, continuing on this thread: > > > > Thanks Dhruv for that explanation regarding forced on/off. I initially > gave it a read through and had the same question as Aijun, unclear as to > what the trade-offs were with the existing then came and read this thread. > Perhaps it's worth expanding a bit more in section 6 - the existing > mechanism effectively is turning it off-and-on again which may cause more > path churn (compared to targeted knob removal). > > > Dhruv: Ack, will do! > The document indicates the 'value portion' of the sub-tlv. I assume this > applies to all 'values' when the sub-tlv contains multiple? For example, > Adjustment-Threshold-Percentage Sub-TLV has both percentage and > minimum-threshold. I would assume a speaker should set both of those fields > to zero? > > > Dhruv: Yes, will update text to make it clear - "The value portion of the sub-TLV consists of encoded data (of the specified length and type), which is set to zero. In cases where the value portion of the sub-TLV contains multiple fields, all fields are set to zero." > Regarding section 6, the SHOULD use other techniques is a bit unclear to > me the intent. Shouldn't the speaker: MUST follow RFC8733 and MUST NOT send > zeros where RFC8733 does not permit it, and MAY use other RFC8733 compliant > techniques? > > > Dhruv: You are correct, we should remove it. I suggest - An existing implementation of [RFC8733] that does not support this update (where the Z flag is not set) will not recognize or use the special value of all zeros in the sub-TLV. If such a sub-TLV is received, as per [RFC8733], some implementations may treat the sub-TLV as malformed and ignore it. Thanks! Dhruv > Rest of the document was fairly clear read. > > > > > > >> Do you believe that this document [1] is a right foundation for a PCE > WG item? > > > > It looks to enhance existing PCEP mechanisms to not require doing a > force-on-off while also managing backwards compatibility, so yes it is the > right foundation for a PCE WG item. Support adoption. > > > > Thanks > > Andrew > > > > *From: *Aijun Wang <wangai...@tsinghua.org.cn> > *Date: *Friday, October 11, 2024 at 9:17 AM > *To: *Dhruv Dhody <d...@dhruvdhody.com> > *Cc: *draft-peng-pce-stateful-pce-autobw-upd...@ietf.org < > draft-peng-pce-stateful-pce-autobw-upd...@ietf.org>, pce@ietf.org < > pce@ietf.org> > *Subject: *[Pce] Re: 答复: Adoption Poll for > draft-peng-pce-stateful-pce-autobw-update > > > > *CAUTION:* This is an external email. Please be very careful when > clicking links or opening attachments. See the URL nok.it/ext for > additional information. > > > > Hi, Dhruv: > > > > OK, your explanations and supposed updates address my concerns. > > > > Support its adoption. > > > > Aijun Wang > > China Telecom > > > > On Oct 10, 2024, at 19:41, Dhruv Dhody <d...@dhruvdhody.com> wrote: > > > > Hi Aijun, > > > > Thanks for reading our draft and asking questions. > > > > On Thu, Oct 10, 2024 at 12:41 PM Aijun Wang <wangai...@tsinghua.org.cn> > wrote: > > Hi, Authors: > > Just want to clarify some questions first: > 1) As described in section 6(Backward Compatibility) of your draft, it > seems that " send a PCEP message without AUTO-BANDWIDTH-ATTRIBUTES TLV > first and then include the AUTO-BANDWIDTH-ATTRIBUTES TLV with the updated > sub-TLV. " can achieve the same effect to remove the aimed sub-TLV? If so, > what's advantage of this draft? If not, why? > > > > Dhruv: PCEP message without the AUTO-BANDWIDTH-ATTRIBUTES TLV indicates > that the auto-bandwidth feature is disabled. Including it again with > updated sub-TLV signals that the feature is enabled with the new > parameters. While switching-it-off-and-switching-it-back-on may get it to > work, this is not the proper method for handling modifications to the > auto-bandwidth parameters. Moreover, it will also cause unnecessary path > computation churn at the PCE. > > > > 2) Is there any situation that needs to remove the sub-TLV with default > value? If so, it seems current mechanism can't achieve such aim. > > > > Dhruv: Yes but there is no such situation. The default values lead to the > same behavior as if the sub-TLV was removed. > > > > > > 3) From the table 1 of your draft, the default value of " > Down-Adjustment-Threshold " is " Adjustment-Threshold ", but the default > value of " Adjustment-Threshold " is "None". Then which category the " > Down-Adjustment-Threshold " belongs to? Have default value or not? > > > > Dhruv: You make a good point. We should add one more condition as - > > * if an explicit default value is set for the sub-TLV: > > - Restore to the explicit default values > > * if default value is set to another sub-TLV value: > > - Remove the associated attribute > > * if there is no default value for the sub-TLV: > > - Remove the associated attribute > > Assume we have a case of (Sample-Interval = 1000), we use the special > value of all zeros, Sample-Interval = 0, this leads to first if condition > i.e. Sample-Interval = 300 > Now let's assume we have a case of (Adjustment-Threshold = X, > Down-Adjustment-Threshold = Y). > To remove Down-Adjustment-Threshold, we use the special value of all zeros > - Down-Adjustment-Threshold = 0, this will lead to a second if > condition(Adjustment-Threshold = X). > Now assume we want to remove Adjustment-Threshold as well, we use the > special value of all zeros - Adjustment-Threshold = 0, this will lead to > the third if condition and Adjustment-Threshold is removed. > > I can make this update and add an example in the appendix. > > Thanks! > Dhruv > > > > > > > > > > > Best Regards > > Aijun Wang > China Telecom > > -----邮件原件----- > 发件人: forwardingalgori...@ietf.org [mailto:forwardingalgori...@ietf.org] 代表 > julien.meu...@orange.com > 发送时间: 2024年10月7日 23:05 > 收件人: pce@ietf.org > 主题: [Pce] Adoption Poll for draft-peng-pce-stateful-pce-autobw-update > > Hi all, > > This is an adoption poll for draft-peng-pce-stateful-pce-autobw-update. > Do you believe that this document [1] is a right foundation for a PCE WG > item? > Please use the PCE mailing list to express your support or the reasons why > you may be opposed to its adoption. > > Thank you, > > Julien > > --- > [1] > > https://datatracker.ietf.org/doc/html/draft-peng-pce-stateful-pce-autobw-update > > > _______________________________________________ > 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
