Dave Katz wrote:
On Jan 7, 2009, at 9:25 PM, Richard Ogier wrote:
I have found this discussion interesting and educational.
The above argument is very convincing, which I guess is why nobody
is arguing against it. Based on the discussion, I think RFC 2328
should
be clarified as follows to allow some flexibility while ensuring
interoperability between different implementations (including most
existing implementations).
- Footnote [2] MUST be implemented, i.e., if all of the router's
interfaces
are point-to-point links, then the router's IP address MUST be
advertised
in the router-LSA as a host route.
If all the router's interfaces are *unnumbered* point-to-point
links. This is, for the most part, an uninteresting degenerate case
and doesn't apply to the broader problem here, which is who should
be advertising the source address of OSPF packets sent on *any*
unnumbered link, independent of what the other link types are.
- For unnumbered point-to-point links, a Type 3 link (stub network)
MAY be added to the router-LSA (Option 1), but is not required.
Although
adding such links may seem redundant, it has the benefit of ensuring
that
routes calculated to each router are *shortest* paths. Without
adding the
stub links, the calculated routing table will provide the shortest
path to
each network and host, but that need not result in the shortest path
to a
router that is not advertising its own IP address as a host route.
For example, the last hop of the shortest path might be via an
unnumbered
point-to-point link, but the last hop of the calculated path might be
via a numbered point-to-point link (which includes a stub link to the
destination router). Let me know if I am mistaken.
This is presumably what the dreaded Option 1 attempted to do. It
attracts traffic to the neighbor router, which will then resolve the
last hop to the unnumbered link itself via the usual mechanisms for
directly-connected neighbors. Of course, this only results in
optimal routing if *all* of the links are unnumbered (so all of the
neighbors are injecting the stub), but then footnote 2 kicks in and
saves the day in the only case that actually works optimally.
I am assuming that a stub link is always required for *numbered*
point-to-point links (as per RFC 2328), and is optional for *unnumbered*
links (my suggestion). So this allows optimal routing even if only some
of the links are unnumbered, by allowing Option 1 to be used for all
point-to-point links. (Maybe I wasn't clear about this.) My point is
that some people might think it is redundant to advertise stub links for
unnumbered links, but there is a benefit - optimal routing to all routers.
In addition, Footnote 2 is required to ensure interoperability with
routers that decide not to use Option 1 for unnumbered links. The
resulting clarification to RFC 2328 allows optimal routing to all
routers (optionally), while hopefully complying with almost all existing
implementations. Let me know if I am mistaken.
Richard
You are right that the only way to get optimal routing to the router
in the general case is for the router itself to advertise a stub.
I fail to see what's controversial about Option 1, save for the fact
that it's suboptimal and a stupid way of solving the problem (rather
than having the router owning the address advertise the route instead
of its neighbors) and for the colloquial use of "should", which I
always read as MUST in the more modern dialect. To me it is
straightforwardly and unambiguously required for unnumbered links
(just as Option 2 is required for subnetted links.) Other than
substituting MUST for "should" I don't see any question about this.
It is brain-dead six ways from Sunday (like a number of things in
OSPF) but I think we're stuck with it due to backward compatibility
issues.
Unfortunately, I doubt there is no IETF equivalent of the Federalist
Papers to try to give hints of the true intentions of the framers.
(I was there, but didn't take notes, and was more interested in ISIS
at the time anyhow.) As soon as we figure out what the 2nd Amendment
was for, we can go on to Option 1. ;-)
--Dave
_______________________________________________
OSPF mailing list
OSPF@ietf.org
https://www.ietf.org/mailman/listinfo/ospf
