Joakim Tjernlund wrote:
On Tue, 2009-01-06 at 16:34 -0700, Dave Katz wrote:
On Jan 6, 2009, at 2:19 PM, Joakim Tjernlund wrote:
The footnote is sort of bogus on three counts. First of all, a
router
*must* have an address somewhere, or it has nothing to put in the IP
source address field, can't be managed, and is an incredibly
expensive
door stop. So that bit is redundant.
Obviously an IP address is needed, the key part is that the IP address
should be announced as an host route in the router LSA.
Secondly, there is no explicit
mechanism in the spec for advertising that host route, unless this
sentence is intended to be normative (in which case the "will" should
be a "SHALL".)
What mechanism do you need? It is an impl. detail how you specify
that IP address, if you need one. Will vs. shall is perhaps an
error, I can't
say, but I don't think the language in Option 1 or Option 2 is any
stronger.
Thirdly, if implementations were to actually follow
the other section you mention and do option 1, advertising that host
route is unnecessary because all of the OSPF neighbors will know the
address and advertise it themselves (roundabout, as mentioned
earlier,
but it works.) And that footnote is much narrower than the case we
are talking about, which is that of *any* unnumbered interface,
regardless of whether there are other numbered interfaces or not.
You only have do this iff you just have unnumbered interfaces, no need
to add an extra host route if you already announce one.
I think we've gone in circles here.
If I understood your original posting, you were asking about the
meaning/value of the options listed as part of 12.4.1.1. The reason
that they are there is to ensure reachability to the remote router
itself, if it implements exactly what the spec says to do. If the
local router doesn't do Option 1, and the remote router only does
exactly what the spec says to do, you will not be able to route to the
remote router because nobody will announce reachability to its address.
One can look at the spec and say, "of course I should announce host
routes for addresses I think the world might be interested in", and it
will work, but the spec never actually says to do that, *except* in
the case of a router with no numbered interfaces at all (and burying
it in a footnote at the very end of the spec is not a terribly good
thing even in that case.)
So a naïve implementor will still have a functional, reachable,
manageable network if he implements Option 1 and doesn't advertise any
host routes otherwise. This is why Option 1 exists, and why it is
normative. If my box is neighbor to the the naïve implementor's box,
and I don't do Option 1, and he doesn't have his loopback address or
some other address outside of OSPF in a host route (perfectly in-
spec), his box is going to be unreachable for management purposes.
I would not say that it is "perfectly in spec" as the spec actually
mentions this case explicitly in that footnote. I guess that the spec
assumes that it is very uncommon to just have unnumbered links is the
domain and that is perhaps why it is in a footnote.
Also I can can't find a reference in the spec that states that
the purpose of Option 1 is reachability, in [15] one can read:
[15]This is the way RFC 1583 specified point-to-point
representation. It has three advantages: a) it does not require
allocating a subnet to the point-to-point link, b) it tends to bias
the routing so that packets destined for the point-to-point
interface will actually be received over the interface (which is
useful for diagnostic purposes) and c) it allows network
bootstrapping of a neighbor, without requiring that the bootstrap
program contain an OSPF implementation.
Further, looking into RFC 1583 one can see that Option 1 isn't used for
unnumbered links.
Also, there would be no need for footnote [2] if Option 1 is required
so why have in the first place?
Actully, the only thing that might suggest that Option 1 should be
used in 2328 is the text i Option 1 and that text is a bit "fuzzy".
Everything else suggests that Option 1 should not be used(in my reading)
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.
- 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.
Richard
Maybe I'm missing something here?
An related question: what to do with an interface that is UP but not
RUNNING?
Given that these terms are not well-defined, it's not possible to
answer in a normative way. Even in a non-normative, casual way, it's
not clear to me what the actual difference is. If the link does not
pass packets, for whatever reason, OSPF will not come up, and traffic
will not be passed to the nonfunctional link. Whether that interface
address is advertised by the offending router is an implementation
decision, as it has no functional use other than as a management
address. For that matter, it is then immaterial as to whether the
interface is "up" in any way or not, since there's no traffic going
to
that interface anyhow. One could choose to advertise *all* interface
addresses as host routes whether the interface is up or not, in case
anybody is sending packets to those addresses from afar. But this is
usually done with loopback addresses, which become the "router
address" for management purposes and are independent of any physical
hardware.
The IP address on that link is still reachable through other
interfaces. If you
have a connection to the router using its IP address, you can still
use it
even if the interface isn't RUNNING(i.e someone pulled the cable for
that interface).
So instead of removing the whole interface and its subnet from the
OSPF domain, one
should change the router LSA to announce a host route with that
interface's IP address.
I guess I still don't understand the distinction between UP and
RUNNING, but that's OK.
Sorry, I should have explained this better. I refering to the
status of the interface as returned by ifconfig:
# > ifconfig eth0
eth0 Link encap:Ethernet HWaddr 00:06:9C:00:20:02
inet addr:10.0.1.1 Bcast:10.0.255.255 Mask:255.255.0.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
If I disconnect the ethernet cable, the RUNNING status goes away since
the interface cannot pass traffic on the ethernet, but the interface is
still UP.
What does Juniper do in this case for an interface that is part
of a OSPF area? I really like to find out how other routers handle
this case.
The point is (and I think we're in violent
agreement) that if you want a router address to be reachable, it
either has to be announced as a host route or as part of a subnet
route. If the interface isn't passing traffic, announcing a subnet
route would be an exceedingly poor idea, so the host route is the way
to go. The spec is properly (IMHO) silent on when to send host routes
in this case, as it is purely an implementation decision and is not
subject to standardization.
I think this is implicit in the spec. One can ask OSPF to announce
some subnets and all matching interfaces are then announced, if you pull
the cable, the IP address still matches and is reachable so it
should still be announced as a host route.
Jocke
_______________________________________________
OSPF mailing list
OSPF@ietf.org
https://www.ietf.org/mailman/listinfo/ospf
_______________________________________________
OSPF mailing list
OSPF@ietf.org
https://www.ietf.org/mailman/listinfo/ospf
