Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email email@example.com
From: Alex Zinin (zinin_at_PSG.COM)
Date: Tue Oct 08 2002 - 16:26:27 CDT
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
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
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.