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. Apart from this, the draft looks good. The idnits tool throws up a handful of warnings - please fix as many of these as you can. Thanks Jon
_______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
