On Fri, Aug 31, 2012 at 11:03:29AM -0400, Acee Lindem wrote: > > 1) Use value from Link Data field, in a same way of how RFC 2328 > > specifies next hop computation for Point-to-Multipoint links. > > This scheme has several problems (e.g. does not work for unnumbered > > links and there is no reliable way to match links from neighbor's router > > LSA to my links if there are parallel links). > > > > 2) Use neighbor IP address from neighbor data structure of the neighbor on > > given iface. This is probably more robust, but a bit strange, as neighbor > > data structure is otherwise not used in routing table calculation. > > > > Any comments on how next hop computation should be done in this case? >
> Many layer 2 implementations support P2P ethernet as a true > point-to-point topology. For P2P, my implementation uses #2 independent > of whether the P2P is a true layer 2 P2P or a layer 3 emulation of P2P > over a LAN topology. The RIB layer determines whether it is necessary. Glad to hear that other implementations also use #2. Our implementation uses #2 and we met some compatibility problems with implementations that uses #1 and expects IP address in Link Data field, even if we consider link unnumbered and put ifindex there (RFC 2328, 12.4.1.1) > > Slightly related question: Is it true that link-back check is broken in > > OSPFv2 when there are parallel (unnumbered) links between two routers? > > It is true that you cannot not unambiguously differentiate between the > parallel unnumbered P2P links. However, for the unicast routing > hop-by-hop paradigm, it shouldn't matter since we know the OSPF LSDBs > should be synchronized and the IP routing tables should be consistent. > For paradigm, e.g., traffic engineering, it is necessary to be able to > uniquely identify the links. Note that no ambiguity exists in OSPFv3. Even if OSPF LSDBs are synchronized then there still could be a discrepancy in link state - if one neighbor immediately notices a link failure (e.g. by a physical layer link signalization) while the other waits for an inactivity timeout. This is a transient condition, but in a stable state the link-back check is IMHO not needed anywhere. -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: [email protected]) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
signature.asc
Description: Digital signature
_______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
