Subject: Re: [OSPF] Next hop calculation on PtP links over LAN

From: Ondrej Zajicek <[email-masked]>
Date: Sat, 1 Sep 2012 12:42:59 +0200

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-masked])
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."