[OSPF] AD review of draft-ietf-ospf-link-overload-10

[Alia Atlas <[e-mail]>]

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