I have an additional comment below. (My last comment is also repated
below.)
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.
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.
Yes, another way to ensure optimal routing to all routers is to have
every router advertise its IP address as a stub link. Obviously, this
can also be done optionally if optimal routing is desired. Therefore,
my suggested clarification of RFC 2328 can be summarized as follows:
- Footnote 2 MUST be implemented.
- Option 1 is optional for unnumbered point-to-point links.
- Any router MAY advertise its IP address as a stub link, to ensure
optimal routing.
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.
Since Footnote 2 was already required by RFC 2328 (and hopefully your
implementations are compliant with this), then making Option 1 optional
for unnumbered links is backward compatible, even if you interpreted the
RFC to require Option 1 for unnumbered links (which as Acee stated was
not the intention.) Let me know if I am mistaken.
Richard
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
