Re: OSPFv2 Opaque LSAs in OSPFv3

[Alex Zinin <[e-mail]>]

Dennis,

  Thanks for your note.

  I don't think the key point of the argument is about how separated
  are the flooding and reachibility announcement mechanisms in
  OSPFv3--they definitely are, nor I think it is about whether OSPFv3
  can be extended to support IPv4 routing--it definitely can be. It is
  about whether "legalizing" all v2's Opaque-LSAs in v3 (as opposed to
  copying the features) makes sense or not. As you said, OSPFv2 and
  OSPFv3 are somewhat different routing protocols, also OSPFv3, as it
  stands today, is an IPv6 routing protocol. Given these two combined
  with my paranoid worry about insufficient specification, I don't
  think it is a good idea.

  Regards.

--
Alex

Saturday, October 12, 2002, 4:18:58 PM, Dennis Ferguson wrote:
> 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