Subject: Re: OSPFv2 Opaque LSAs in OSPFv3

From: "Manral, Vishwas" <[email-masked]>
Date: Wed, 9 Oct 2002 01:40:05 -0400

Hi folks,

To summarize the discussion I guess Kireeti's approach helps in reducing the
workload for the working group and getting the specs out faster(especially
TE). I do not think "mapping" can cause problems as long as in each draft
using opaque LSA's we give information for both v2 and v3.

However the code reuse can still be done if we use the same TLV values for
v3 as v2 even when we have seperate drafts. If the working group is ready to
take in the additional work, I think we can replicate and have seperate
drafts for TE which do help in clarity of the specs.

However I have a few clarification to make if we do decide to work on each
draft seperately: -

a) How would we want to go ahead with docs like "Graceful Restart" which are
still in draft state and haven't gone LC etc? We could as well have v3
additions in the existing drafts.

b) How would we want to have drafts in the future for a particular feature?
Different drafts or the same one defining for both OSPFv2 and v3?

For both the questions I would prefer an integrated approach for the drafts.

Thanks,
Vishwas

-----Original Message-----
From: Alex Zinin [mailto:[email-masked]]
Sent: Wednesday, October 09, 2002 2:56 AM
To: [email-masked]
Subject: Re: OSPFv2 Opaque LSAs in OSPFv3

Kireeti, et al

 Sorry for the delay.

 If I understand Kireeti's idea correctly, the suggestion is to "map"
 the Opaque LSA mechanism in v2 to the generic scoped flooding
 mechanism in v3; and it is primarily driven by the desire to get TE
 extensions to v3 faster. Below is my view on this.

 It seems to me that such a mapping would introduce the under-
 specification problem and thus may affect interoperability. Here's
 why.

 What is being said is essentially "whatever Opaque LSAs have been
 introduced in the past or will be introduced in the future in v2 now
 also make sense in v3". It's not that easy though. Opaques LSAs used
 in v2 may affect protocol mechanisms that are specific to v2 and are
 not applicable in v3, or they may contain information that makes
 sense in the IPv4 world only. Just saying that we now have this stuff
 in v3 is not enough, one has to go and specify how this info is
 interpreted there.

 In other words, when one wants to have a feature in v3 that is
 supported in v2 using Opaque LSAs, two things need to be specified:
 how required information is carried around, and how this information
 is interpreted. Suggested mapping solves the first part, which is a
 non-issue btw, but creates a problem in the second.

 Bottom line: I think there is a problem in the suggested approach and
 believe that bringing the features based on/contents of Opaque LSAs
 to v3 should be done on a case-by-case basis with proper
 specification of IPv6 and v3-related details.

 Regards.

--
Alex

---

From: Kireeti Kompella <[email-masked]>
Date: Wed, 9 Oct 2002 10:57:24 -0700

> using opaque LSA's we give information for both v2 and v3.

You'll make yourself pretty unpopular with the AD if you keep that up :-)

> additions in the existing drafts.

Actually, all the TE-related work is also in draft stage.  The base TE
doc is pretty far along, though, and I would prefer not to pull it back
at this point.  That is why I suggested putting the IPv6 TLVs in the
GMPLS doc (which I view as an update to the TE doc).  That way, the v3
doc only needs to define an LS Function Code, map Instances to LS IDs,
and "ratify" that all TE TLVs/sub-TLVs work in v3.

Consider for example a network with an IPv4 control plane and IPv6
data plane.  RSVP-TE already has support for signaling in IPv4 an ERO
with IPv6 addresses; all it needs is a TE database with IPv6.  So
making the new TLVs v3-only is unnecessary and unhelpful.  This can
of course be taken care of with careful wording in the v3 TE draft.

Since we're already on the path of maximal work, why don't you and
Kunihiro get together and bash out one TE draft instead of two?

Kireeti.