A quick reminder to keep our discussions aligned with the IETF’s expectations for professional and respectful conduct, as outlined in RFC 7154.
In particular, please avoid comments that could be perceived as dismissive, condescending, or personally directed at others. It is perfectly appropriate to challenge technical claims, ask for evidence, or question assumptions, but please do so in a way that addresses the substance of the discussion rather than the individuals involved. Keeping the discussion factual, constructive, and respectful will help ensure that everyone can participate effectively and that we maintain a productive environment for the WG. Thanks for your cooperation. - Pavan and Oscar On Thu, Oct 1, 2026 at 11:40 AM John Drake <je_drake= [email protected]> wrote: > Hi, > > Comments inline. > > Thanks, > > John > > > On Wednesday, September 30, 2026 at 01:17:31 PM PDT, RJ A < > [email protected]> wrote: > > > > > > On Sep 28, 2026, at 11:15, Robert Raszuk <[email protected]> wrote: > > > > Hi Ran, > > > > While I do support adoption of this TE extension for ISIS I do not agree > that current discussion can be named as "odd". > > > > See IETF rules and guidelines perhaps work decent to define conditions > when this or that draft is proposing an extension which sits already in the > working group charter. > > > > Here this proposal is defining a completely new technology "power saving > by network auto reconfiguration using TE" and by this alone touches work > residing in number of other working groups in IETF. > > > > On the other hand we can't and should not extend protocol to only fit > one design/architecture as changing such extension while deployed out in > the wild is very costly - especially for architectures which to work well > do requires a massive almost network wide upgrade. > > I believe that you believe that. > > Based on my ~38 years of IETF experience, and having personal experience > with network engineering for a multi-continent broadband ISP, I disagree > with your characterization. > > > > > JD: Impressive. It's not well known, but I solved world hunger and > invented cold fusion. > > > > This is a minor, almost trivial, extension to very well-understood Traffic > Engineering (TE) mechanisms. Further, I disagree that this proposal > narrowly fits “one design/architecture” and disagree that any uninterested > operator would need to upgrade anything. > > > > > JD: This two statements are completely contradictory > > > > Operators that choose to use the mechanism are perfectly capable of > making their own cost/benefit analyses. Further, the operators I’ve spoken > with disagree with the claim that any “massive almost network wide upgrade” > would be required. > > > > > JD: Were these Operators folks you met in an elevator or at a bus stop? > > > > Yours, > > Ran > > _______________________________________________ > Lsr mailing list -- [email protected] > To unsubscribe send an email to [email protected] > _______________________________________________ > Teas mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
