Subject: Re: OSPFv2 Opaque LSAs in OSPFv3

From: "Naidu, Venkata" <[email-masked]>
Date: Thu, 10 Oct 2002 13:05:39 -0400

Kireeti & Alex,

  I am late into the field - please excuse and consider
  my points.

-> > (c) is, if I understand you correctly, the approach you
-> are suggesting.
->
-> Not necessarily on a section-by-section/TLV-by-TLV basis as you
-> mentioned above. Instead, if, for example, we need to get the TE
-> extensions into v3, we would come up with a
-> draft-ospf-ospfv3-katz-yueng
-> and specify the LS Type for TE LSAs, refer to katz-yueng for things
-> like body formatting, enumerate TLVs (by reference, not value) that
-> are IP-version independent and are valid for v3, and then go and
-> address the IPv6 specific details.

  Kireeti has a very valid point here. Alex's point is independent
  of what we (MPLS folks) have to do at this point of time.

  I view MPLS-TE a "service user" of OSPF (v2 or v3) "a service
  provider" for flooding the information transparently to other
  side of MPLS-TE layer.

  If, by chance, OSPFv3 is running in the topology, and If the
  application (here, for example, still MPLS-TE for IPv4) would
  like to pass the info (OSPF should not care about what the
  information is) to the other side, then it should. *Application*
  (for example MPLS-TE for IPv4) knows what is the info - here it
  is still IPv4 - for the reasons mentioned  by Kireeti.

  Alex, let me put it in other way - define a LS Type in OSPF v3
  and call it "User defined LS Type" and reserve *one* (just one)
  for OSPF v2 Opaque LSAs. Now with very minimal changes, all the
  IPv4 applications which used OSPF v2 Opaque LSAs can be flooded
  even when OSPF v3 is running in the network.

  Alex's point is valid when MPLS-TE for IPv6 (which is different
  application when compared to MPLS-TE for IPv4) is used in the
  network. For this, any way, we need a clear draft which considers
  IPv6 requirements, etc etc.

  Alex, there are almost nearly 20 different IPv4 applications
  using OSPF v2 Opaque LSAs (MPLS-TE is just one of them). So please
  consider the fact that, all those applications must work if the
  version of OSPF is changed from v2 to v3 with minimal work.

  Bottom Line: It is the application who decides whether to write
  a new draft for IPv6 or not by taking the new requirements for IPv6
  (if there are any). A service provider (here OSPF) should not ask
  applications to change their behavior or information when it's own
  operation/version changes. What it should possible do is, provide
  a transport mechanism (a SAP) to all those previous applications,
  so that the information is flooded intact.

  Please don't think otherwise - kindly interrupt me if I am not
  in the same page :)

--
Venkata.

---

From: Kireeti Kompella <[email-masked]>
Date: Thu, 10 Oct 2002 11:54:23 -0700

Thanks for your support, Venkata!

One thing I would like to reiterate: there are a *small* number of
currently defined Opaque LSAs -- TE, Grace LSA, and perhaps one more.
If we analyse the applicability of those LSAs to OSPF v3, and mandate
that any future definition of an OSPFv2 Opaque LSA MUST have a similar
analysis, that seems to me to address the "backdoor" problem.

The "backdoor" issue is an excellent example of a *theoretical*
problem that has little *practical* relevance, given the above mandate.

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.

And then we hear that the IETF is overloaded, and the IESG overburdened.
Oh, well ...

Kireeti.

---

From: Alex Zinin <[email-masked]>
Date: Fri, 11 Oct 2002 16:53:12 -0700

Venkata,

  There's no problem in OSPFv3 providing transport-like services to
  non-OSPF "applications", this concept is just already in the
  protocol, we don't have to specify anything extra here.

  My objection is against the idea of mapping/linking/shortcutting all
  Opaque-LSA-based *extensions* to OSPFv3. This idea is based on the
  assumption that migration of those extensions from IPv4 to IPv6 or
  from OSPFv2 to OSPFv3 environment will generally not require any
  additional specification. While this may be true for some specific
  "applications", I don't believe we can safely assume this as a
  general case.

  We are here to make sure independent interoperable implementations
  can be developed, which means that things need to be properly
  specified. My standing in this discussion is to ensure that we do
  not make a mistake that will create the underspecification problem.

  Thank you.

--
Alex

>   I am late into the field - please excuse and consider

->> > (c) is, if I understand you correctly, the approach you
->> are suggesting.
->>
->> Not necessarily on a section-by-section/TLV-by-TLV basis as you
->> mentioned above. Instead, if, for example, we need to get the TE
->> extensions into v3, we would come up with a
->> draft-ospf-ospfv3-katz-yueng
->> and specify the LS Type for TE LSAs, refer to katz-yueng for things
->> like body formatting, enumerate TLVs (by reference, not value) that
->> are IP-version independent and are valid for v3, and then go and
->> address the IPv6 specific details.

---

From: Alex Zinin <[email-masked]>
Date: Fri, 11 Oct 2002 18:10:15 -0700

> problem that has little *practical* relevance, given the above mandate.

It's an excellent example of the type of hidden problems that ADs have
to think about and that to them has a very practical relevance.

> 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.

> And then we hear that the IETF is overloaded, and the IESG overburdened.

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.

Alex

---

From: Dennis Ferguson <[email-masked]>
Date: Sat, 12 Oct 2002 16:18:58 -0700

Alex,

> 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.

> "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

---

From: Alex Zinin <[email-masked]>
Date: Mon, 14 Oct 2002 10:44:54 -0700

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