Hi Jon, Thanks for your review. See inline…
From: Pce [mailto:[email protected]] On Behalf Of Jonathan Hardwick Sent: 26 January 2016 22:52 To: [email protected]<mailto:[email protected]> Cc: [email protected]<mailto:[email protected]> Subject: [Pce] Shepherd's review of draft-ietf-pce-iro-update I have performed a document shepherd review of this draft. Here are my comments. Please feel free to discuss. The draft makes a good clarification to RFC 5440 and the author has taken great care to check the impact on existing implementations. The draft proposes to add the L bit to IRO subobjects. Prior to this draft, implementations should have been setting this bit to zero when sending, and ignoring it on receipt. Following this draft, a value of zero is now to be interpreted as indicating a “strict hop” in the IRO. However, according to the survey, there are at least two implementations that interpret IRO subobjects as loose hops. From the point of view of such implementations, this is a non-backwards-compatible change. I think the draft should explain the impact on operations if an implementation conforming to this draft interworks with an implementation that does not. I think the impact is as follows. * If a non-conforming PCC sends an IRO to a conforming PCE, then the PCE may unexpectedly fail to find a path (since the PCC thinks it is giving loose hops, but the PCE interprets them as strict hops). * If a conforming PCC sends an IRO containing strict hops to a non-conforming PCE, then the PCE may erroneously return a path that does not comply with the requested strict hops (since it interprets them all as loose hops). The PCC would have to double-check the returned path or else it may end up using a path with unintended hops in it. The second impact seems worse than the first. I think the draft should note these possibilities in a new section, and should RECOMMEND that network operators ensure that all PCEs in their network conform to this draft if they intend to use IROs. I don’t think the impact is critical enough to warrant adding a new capability to the protocol to indicate this updated behaviour, but I would be interested in hearing feedback from anyone (particularly operators) who is worried by this. [Dhruv]: Luckily these implementations were not “shipping product”, so there shouldn’t be any impact on live networks. I have added a section describing this anyways. Apart from this, the draft looks good. The idnits tool throws up a handful of warnings �C please fix as many of these as you can. [Dhruv]: Done, one comment regarding the boilerplate is pending (but this should not block progress of the draft). I have posted an updated version. Regards, Dhruv Thanks Jon 本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁 止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中 的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！ This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!
_______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
