As is customary, I have done my AD review of draft-ietf-ospf-link-overload-10. First, I would like to thank the authors - Shraddha, Pushpasis, Hannes, Mohan, and Luay - as well as the WG for their hard work on this document.
I have several minor comments that should be resolved before it goes to IETF Last Call. 1) Personally, not having all of OSPFv2 and OSPFv3 readily in my head, I would find it helpful to have some examples where the Link Type, Link ID, and Link Data aren't enough to differentiate the parallel links. I am, of course, familiar with this issue for IS-IS - but I don't recall running into when implementing LFA. I would find it useful to see some examples of a topology with the LSA with TLV & sub-TLVs to handle some of the cases - particularly interacting with parallel links. 2) If there is the issue with parallel links, why isn't there a remote IPv6 address sub-TLV for use with OSPFv3? 3) The Remote IPv4 address and Local/Remote Interface ID sub-TLVs imply that they are narrowing the scope of the Extended Link Opaque TLV from multiple parallel links to one. However, there is no specific wording explaining how they would be generally applied (and yet the naming implies that they might be) or the implications for other sub-TLVs that might be included or how to handle the new need for multiple Extended Link Opaque TLVs that aren't supported in RFC 7684. From RFC 7684, it is clear that: " If multiple OSPFv2 Extended Link Opaque LSAs include the same link, the attributes from the Opaque LSA with the lowest Opaque ID will be used." and that there should be only one Extended Link TLV. For instance, what happens if a SID sub-TLV is also specified? What if a SID sub-TLV was specified in an Extended Link TLV - and now the router wants to advertise a link-overload for only one of the particularly parallel links? Regards, Alia
_______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf
