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 IPsource address field, can't be managed, and is an incredibly expensivedoor 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 specifythat 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 theaddress 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.
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 theinterface is "up" in any way or not, since there's no traffic going tothat 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. 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.
That way you can have an router with one Ethernet interface that is always reachableover any other(unnumbered) interface.
This is essentially independent of unnumbered interfaces. The requirement for unnumbered interfaces is only that the source address in OSPF packets is reachable, so that the local router can send packets back to it. The remote router can advertise host routes for any or all of its interface addresses if it wishes to, but in fact it doesn't need to advertise *any* host route for this to work, as the neighbor (by option 1) is required to advertise a host route on its behalf, which will draw traffic to the unnumbered interface.
If a router wishes to advertise host routes for interfaces so that management traffic may use them without worrying about the associated interface state, it can. Note that this is no different than having functioning router interfaces that are not actually part of the OSPF domain (which is quite common.)
--Dave _______________________________________________ OSPF mailing list OSPF at ietf.org https://www.ietf.org/mailman/listinfo/ospf