Re: OSPFv2 Opaque LSAs in OSPFv3

[Dennis Ferguson <[e-mail]>]

Alex,

> > As a consequence, we have at least two independent efforts to migrate
> > just the TE document to v3, when in fact it should be really simple.
> > Then we do it again for Grace LSAs.  And possibly again in the future.
>
> OSPFv3- and IPv6-related issues should be considered and specified for
> each feature independently, because OSPFv? are not just two versions
> of a transport mechanism, they are two different routing protocols
> providing connectivity for different types of environment.

Here's the problem I have with this.  OSPFv3 was in fact designed to
be network-protocol agnostic, like IS-IS, except retaining OSPF's
style of adjacency synchronization and many-LSA information distribution.
This is why address information was entirely separated from adjacency
maintenance packets and topology description LSAs, why there's a "v6"
option bit (so you could have a v4-only router running the protocol), is
one of the reasons for the instance ID (if you really needed to deal
with multiply-addressed v4 links), and is why the LSAs which do carry
address information only carry address information, and nothing else.
While it has not been specified yet, making OSPFv3 route IPv4 may not
be much more difficult than finding all the LSA types which carry IPv6
addresses in the current protocol (I think there are 4 of them) and
inventing equivalents to carry IPv4 addresses.

The reason I think you really want to plan for this is that networks
which support IPv6 will almost certainly continue to support IPv4 just
about forever, in Internet years.  Support for both protocols won't be
a transition strategy, it will be a permanent operational state.  As
such (and while at least one of the authors of the OSPFv3 RFC might
disagree), I don't think running two IGPs over the same topology is a
practical plan to address this.  Not only does it substantially
increase configuration, debugging and other operational complexity, but
it also unnecessarily duplicates the mechanisms which often dominate the
cost of running a link state protocol and most severely limit its scalability,
i.e. adjacency maintenance.  Having one IGP carry twice the number of
addresses is much cheaper, more maintainable and more scalable then running
two IGPs.

So we're in this state where OSPFv3 should be a dual-network-protocol
routing protocol, but isn't yet, and you are talking about importing several
functions from OSPFv2 which, if well done, seem like they should have
very little dependence on a particular network protocol.  Given what OSPFv3
may become I think it would be a big mistake to allow gratuitous IPv6
dependencies to creep into these (in fact I also think it is a mistake
if the authors of the OSPFv2 versions let gratuitous IPv4 dependencies
creep into those) because if you do you may be painting yourself into
a corner where you might not want to be in future.

This leaves the practical problem of ensuring that functionality is
specified in a way which makes sense in a multi-network-protocol
environment when OSPFv3 doesn't (yet) operate in an environment like
that.  While one could attempt to do this in theory, I'd just point
out that if you could manage to import the functionality from OSPFv2
without changes you'd have some practical assurance that what you had
actually would make sense for IPv4 as well as IPv6.  While I'll admit
that OSPFv3 is a somewhat different routing protocol than OSPFv2, I don't
think I'd reject the direct copy based on a generic "different types of
environment" argument since those environments may become a lot more
similar in future.

> > And then we hear that the IETF is overloaded, and the IESG overburdened.
> > Oh, well ...
>
> Thanks for thinking about the IESG. I can assure you that it will be
> much less controversial (and hence faster) for the IESG to deal with
> drafts explicitly specifying IPv6/OSPFv3 considerations for specific
> features, than it will be to waste time arguing about a draft that
> collectively migrates all present and future OSPFv2-based features and
> "applications" to the IPv6/OSPFv3 environment.

If the IESG thinks of "OSPFv3" as exclusively "IPv6" I think they might
be missing some of the bigger picture with respect to future operational
requirements for an IGP.  Perhaps there needs to be a draft to keep
people reminded of this, however.

Dennis Ferguson