Hi Eric, please see inline:
On 11/05/2020 17:55, Éric Vyncke via Datatracker wrote:
Éric Vyncke has entered the following ballot position for draft-ietf-ospf-mpls-elc-13: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ospf-mpls-elc/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for the work put into this document. The document is easy to read. Please find below one non-blocking COMMENTs and two NITs. I hope that this helps to improve the document, Regards, -éric == COMMENT == For my own curiosity, is there a possibility that a router receives conflicting node capability via OSPFv2 and OSPFv3 (assuming that both are running over the same network and using the same router-ID over OSPFv2 and OSPFv3) ?
that would be a bug likely, as the capability is not specific to any of the protocol and they only act as messengers. But we can not mandate any cross protocols checking either.
== NITS == -- section 4 -- The "one" is ambiguous in "the router MUST advertise the smallest one." even if we can guess that it is not "interface" ;-) -- Sections 3 & 4 -- Is there a meaningful difference between the "advertizing" of section 3 and the "signaling" of section 4?
not really. In IGPs we tend to use "advertise" more. If you prefer, I can change all to "advertise" or to "signal" for consistency.
thanks, Peter
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
