Subject: OSPFv2 Opaque LSAs in OSPFv3

From: Kireeti Kompella <[email-masked]>
Date: Mon, 7 Oct 2002 17:18:03 -0700

Hi All,

I've just posted draft-kompella-ospf-opaquev2-00.txt that takes
six pages to say "if you see an OSPF v3 LSA with Function Code 10,
treat it as you would an OSPF v2 Opaque LSA".

Comments actively solicited, at least until the negative ones roll in :-)
The main goal is code reuse between v2 and v3; if that isn't achieved,
I'd be interested in knowing why, and how it might be fixed.

Kireeti.
-------

---

From: Alex Zinin <[email-masked]>
Date: Mon, 7 Oct 2002 18:12:34 -0700

Kireeti,

  Hard to talk without seeing the draft, but what problem
  is it trying to address? I mean, we already have a more
  generic "opaque"-like mechanism in OSPFv3, why is it not
  enough?

--
Alex

---

From: Kireeti Kompella <[email-masked]>
Date: Mon, 7 Oct 2002 18:32:44 -0700

Hi Alex,

> generic "opaque"-like mechanism in OSPFv3, why is it not

True, we have a generic opaque mechanism in OSPF v3.  However,
if I want to do TE in OSPF v3, what do I put in the packet to let
you know that this is a TE LSA?  In particular, what function code
do I put in the LSA?  Should there be a new function code for each
'legacy' Opaque LSA?  Etc.

The draft (see below, sorry all for the spam) just grabs a single
LSA function code for 'OSPF v2 Opaque LSAs', but otherwise keeps
everything mostly the same.

Take a look -- fortunately, it shouldn't take more than a couple
of minutes :-)

Kireeti.
-------

Network Working Group                                        K. Kompella
Internet Draft                                          Juniper Networks
Updates: 2740                                               October 2002
Category: Standards Track
Expires: April 2003

                      OSPFv2 Opaque LSAs in OSPFv3
                  draft-kompella-ospf-opaquev2-00.txt

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
              http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
              http://www.ietf.org/shadow.html.

Copyright Notice

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

Abstract

   This memo specifies how OSPF version 2 Opaque Link State
   Advertisements can be carried in OSPF version 3.

Kompella                     Standards Track                    [Page 1]

Internet Draft        OSPFv2 Opaque LSAs in OSPFv3          October 2002

1. Introduction

   RFC 2370 [OPAQUE] describes the notion of an "opaque" Link State
   Advertisement (LSA) -- as the RFC says, an LSA that provides "a
   generalized mechanism to allow for the future extensibility of OSPF".
   This has certainly proved useful, for example in defining Grace LSAs
   [HITLESS] and OSPF v2 Traffic Engineering LSAs [OSPF-TE].  RFC 2370
   also defines the format that opaque LSAs take in OSPF version 2
   [OSPFv2], and defines three flooding scopes for such LSAs:
   link-local, area-local and Autonomous System (AS)-wide.

   OSPF version 3 [OSPFv3] inherently supports the notion of opaque LSAs
   in that the flooding scope of an LSA is explicitly stated in the LSA
   header.  OSPF v3 also specifies how LSAs with unrecognized function
   codes are to be handled.

   This memo specifies how OSPF version 2 opaque LSAs can be carried in
   OSPF version 3.  This allows the reuse of the specifications of OSPF
   v2 Opaque LSAs, as well as the code to support them, in OSPF v3.  In
   a nutshell, an OSPF v3 LS Function Code is defined to indicate that
   the LSA is of type OSPF v2 Opaque LSAs; the OSPF v3 Link State ID is
   formatted the same as in the OSPF v2 Opaque LSA; and the body of the
   OSPF v3 LSA is identical to the body of the OSPF v2 Opaque LSA.

2. Opaque LSAs

   An Opaque LSA in OSPF v2 is formatted as follows [OPAQUE, A.2]:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |            LS age             |     Options   |    LS Type    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Opaque Type  |               Opaque ID                       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                      Advertising Router                       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                      LS Sequence Number                       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         LS checksum           |           Length              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    +                                                               +
    |                      Opaque Information                       |
    +                                                               +
    |                              ...                              |

Kompella                     Standards Track                    [Page 2]

Internet Draft        OSPFv2 Opaque LSAs in OSPFv3          October 2002

   The LS Type is 9, 10, or 11 depending on whether the Opaque LSA's
   flooding scope is link-local, area-local or AS-wide (respectively).

   The above OSPF v2 Opaque LSA is formatted as follows as an OSPF v3
   LSA:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |            LS age             |1|X|Y|    OSPFv2 Opaque LSA    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         Link State ID                         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                      Advertising Router                       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                      LS Sequence Number                       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |          LS checksum          |            Length             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    +                                                               +
    |                      Opaque Information                       |
    +                                                               +
    |                              ...                              |

   The U bit in the LS Type is set to 1.  The LS Function Code is set to
   10 [to be ratified by the OSPF WG], indicating that the LSA type is
   'OSPF v2 Opaque LSA'.  The XY bits are set to reflect the flooding
   scope:

       OSPFv2 Opaque
      LSA of LS Type   X Y
      --------------   ---
                   9   0 0
                  10   0 1
                  11   1 0

   The OSPF v3 LSA's Link State ID is formatted as one octet of Opaque
   Type, and 3 octets of Opaque ID (i.e., exactly as the Link State ID
   of the OSPF v2 Opaque LSA).

   The body of the OSPF v3 LSA is octet-for-octet identical to the OSPF
   v2 Opaque Information.

Kompella                     Standards Track                    [Page 3]

Internet Draft        OSPFv2 Opaque LSAs in OSPFv3          October 2002

2.1. Processing OSPF v2 Opaque LSAs

   An OSPF v3 implementation encountering an LSA of type 'OSPF v2 Opaque
   LSA' MUST follow the rules regarding handling and flooding as defined
   by the U and XY bits, as defined in [OSPFv3].

   In addition, an OSPF v3 implementation MAY further process an OSPF v2
   Opaque LSA as an OSPF v2 implementation would, e.g., it might use a
   Grace-LSA to accomplish (or assist in) hitless restart of OSPF v3; or
   it might build a Traffic Engineering database using the opaque TE
   LSAs.  It is the intent of this memo to maximize code (and
   specification) reuse between OSPF v2 and OSPF v3 in this regard.

Normative References

   [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
       Requirement Levels", BCP 14, RFC 2119, March 1997

   [OPAQUE] Coltun, R., "The OSPF Opaque LSA Option," RFC 2370, July
       1998

   [OSPFv2] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998

   [OSPFv3] Coltun, R., D. Ferguson, and J. Moy, "OSPF for IPv6", RFC
       2740, December 1999

Informative References

   [HITLESS] Moy, J., "Hitless OSPF Restart", work in progress

   [OSPF-TE] Katz, D., D. Yeung, and K. Kompella, "Traffic Engineering
       Extensions to OSPF Version 2", work in progress

Security Considerations

   The flooding and handling of LSAs has already been specified in the
   [OSPFv3]; this memo only defines a new LS Function Code, and the
   format of the LS body.  The OSPF v3 security mechanisms to prevent
   tampering and spoofing of LSAs suffice.

Kompella                     Standards Track                    [Page 4]

Internet Draft        OSPFv2 Opaque LSAs in OSPFv3          October 2002

Acknowledgments

   Many thanks to Quaizar Vohra, with whom much of this was discussed.

Authors' Addresses

   Kireeti Kompella
   Juniper Networks, Inc.
   1194 N. Mathilda Ave
   Sunnyvale, CA 94089
   Email: [email-masked]

IPR Notice

   The IETF takes no position regarding the validity or scope of any
   intellectual property or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; neither does it represent that it
   has made any effort to identify any such rights.  Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11.  Copies of
   claims of rights made available for publication and any assurances of
   licenses to be made available, or the result of an attempt made to
   obtain a general license or permission for the use of such
   proprietary rights by implementors or users of this specification can
   be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard.  Please address the information to the IETF Executive
   Director.

Kompella                     Standards Track                    [Page 5]

Internet Draft        OSPFv2 Opaque LSAs in OSPFv3          October 2002

Full Copyright Notice

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Kompella                     Standards Track                    [Page 6]

---

From: Kunihiro Ishiguro <[email-masked]>
Date: Mon, 7 Oct 2002 19:19:28 -0700

>everything mostly the same.

I'm resending thie mail...I send from wrong from address....so you may
receive two mail.

BTW I haven't submitted the draft but I prepared TE extensions to
OSPFv3.  I just define a new LS type for TE then use OSPFv3 built in
flooding mechanism.  I believe this is straight forward way to do it.
--
Kunihiro Ishiguro

Network Working Group                                       K. Ishiguro
Internet Draft                                         IP Infusion Inc.
Expiration Date: May 2003                                     T. Takada
                                                       IP Infusion Inc.
                                                           October 2002

            Traffic Engineering Extensions to OSPF version 3

               draft-ishiguro-ospf-ospfv3-traffic-00.txt

<SNIP>...

2. Applicability

   OSPFv3 has a very flexible mechanism for adding new LS type.  Even
   the implementation does not know the LS types, the LSA is properly
   flooded by LS type field.  This document add a new LSA type Traffic
   Engineering LSA to OSPFv3.

3. Traffic-Engineering-LSA

   New LSA Traffic-Engineering-LSA is introduced.

3.1 LS Type

   Traffic-Engineering-LSA is defined as Area scope LSA.

   LSA function code  LS Type  Description
   --------------------------------------------------------------------
   10                 0x2000a  Traffic-Engineering-LSA

3.2 LSA Format Overview

   This is LSA header format.

      0                   1                   2                   3
     |           LS age              |0|0|1|          10             |
     |                    LS sequence number                         |

3.3 TLV Header

   The LSA payload consists of one or more nested Type/Length/Value

<SNIP>....

---

From: Kireeti Kompella <[email-masked]>
Date: Mon, 7 Oct 2002 19:58:30 -0700

Hi Kunihiro,

> flooding mechanism.  I believe this is straight forward way to do it.

The draft I submitted also uses the OSPFv3 built in flooding.  It is the
only way to do it.

>  LSA function code  LS Type  Description

Do you plan to have a different Function Code for each OSPFv2 Opaque LSA
Type?

It seems to me to be much easier to have a single code point for all
OSPFv2 Opaque LSAs.  This way, all defined OSPFv2 Opaque LSAs get
automatically defined in v3; moreover, if a new Opaque LSA seems to be
useful for both v2 and v3, it can be defined as an OSPFv2 Opaque LSA.

Kireeti.

---

From: Acee Lindem <[email-masked]>
Date: Mon, 7 Oct 2002 23:19:13 -0400

>> LSA function code  LS Type  Description

Kunihiro,

Believe you mean 0x200a.

> Do you plan to have a different Function Code for each OSPFv2 Opaque LSA

Kiretti,

If you take into account changes to the LS type for OSPFv3, the code points
are compatible. For OSPFv3, the LS Type is 16 bits (versus 8 for OSPFv2) and it
contains the flooding scope and a bit indicating what to do with unrecognized
types. There are no LS type collisions pervent use of the same function codes.

                                OSPFv2             OSPFv3
   Link Scoped Opaque LSAs        0x09             0x0009

  Area Scoped Opaque LSAs        0x0a             0x200a

   AS   Scoped Opaque LSAs        0x0b             0x400b

One could argue that the functions types for area and AS scoped opaque LSAs
should be 0xa00a and 0xc00b as well. This would indicate that a router that
does not recognize the type should store and flood it anyway. Any strong feelings
on this?

Thanks,
Acee

--
Acee

---

From: Kunihiro Ishiguro <[email-masked]>
Date: Mon, 7 Oct 2002 20:33:41 -0700

>The draft I submitted also uses the OSPFv3 built in flooding.  It is the

Exactly.  My point is opaque capability is already provided in OSPFv3.
So there is no benefit to export OSPFv2 opaque capability in OSPFv3.

>Do you plan to have a different Function Code for each OSPFv2 Opaque LSA

Yes.  IHMO, it should be.  For example TE case, we can't apply OSPFv2
TE as it is in OSPFv3.  For Local interface IP address and Remote
interface IP address should be treated IPv6 address not IPv4 address.

So I have in my draft (sorry for referring non published draft...):

     3 - Local interface IP address (16N octets)
     4 - Remote interface IP address (16N octets)

You can easily imagine there are some difference between OSPFv2 TE and
OSPFv3 TE.

And if we mask U,S2,S1 bit, LSA Function Code 9 is alredy assingned to
Intra-Area-Prefix-LSA....  This is another concern...

>useful for both v2 and v3, it can be defined as an OSPFv2 Opaque LSA.

I think it is not realistic that applying OSPFv2 Opaque LSA to OSPFv3
verbatim.  We should define each LS type and it's packet format.  When
OSPFv2 Opaque LSA can be introduced to OSPFv3 without any change,
let's just define type code.  It is not a big effort.
--
Kunihiro Ishiguro

---

From: Kireeti Kompella <[email-masked]>
Date: Tue, 8 Oct 2002 00:30:48 -0700

> types.

No kidding!

> There are no LS type collisions pervent use of the same function codes.

I beg to differ.

>    AS   Scoped Opaque LSAs        0x0b             0x400b

Where did you read this?  I see in rfc 2740:

         LSA function code   LS Type   Description
         ----------------------------------------------------
         1                   0x2001    Router-LSA
         2                   0x2002    Network-LSA
         3                   0x2003    Inter-Area-Prefix-LSA
         4                   0x2004    Inter-Area-Router-LSA
         5                   0x4005    AS-External-LSA
         6                   0x2006    Group-membership-LSA
         7                   0x2007    Type-7-LSA
         8                   0x0008    Link-LSA
         9                   0x2009    Intra-Area-Prefix-LSA

which says that function code 9 represents Intra-Area Prefix LSAs;
it doesn't define a function code 10 or 11.

Since Function Codes are independent of flooding scope in v3, the
LS types 0009, 4009 and 6009 should be interpreted as link local,
AS-wide and ?? Intra-Area-Prefix LSAs, i.e., mostly nonsense.  The
same applies to 0001, 4001 and 6001, etc.

Using the value 0009 for Link Local Opaque LSAs (i.e., requiring that
the function code be interpreted *in the context of the flooding scope*)
negates the entire point of separating LS function and flooding scope.

Kireeti.

---

From: Acee Lindem <[email-masked]>
Date: Tue, 8 Oct 2002 10:17:50 -0400

>>There are no LS type collisions pervent use of the same function codes.

The collision is at different flooding scopes. Hence, the LS type
is unambiguous. Since the application of the opaque LSA is specified
by the Opaque type (in the first 8 bits of the link-state ID)
I can't imagine how the reuse of 0x09 at different flooding scopes
would pose a problem.

> Where did you read this?  I see in rfc 2740:

It was simply an extension of RFC 2370. As Vishwas proposed,

OSPFv3 opaque LSAs can be implemented with a single function
code. This seems to be the best solution given that the only
reason for 3 types in OSPFv2 was to support different flooding
scope. It also removes the collision between function codes.

                                OSPFv2             OSPFv3
   Link Scoped Opaque LSAs        0x09             0x000a
   Area Scoped Opaque LSAs        0x0a             0x200a
   AS   Scoped Opaque LSAs        0x0b             0x400a

As for the setting of the U bit, I think this could stand

some discussion.

--
Acee

---

From: Kireeti Kompella <[email-masked]>
Date: Tue, 8 Oct 2002 07:59:24 -0700

>      4 - Remote interface IP address (16N octets)

This approach is flawed (IMO) for a couple of reasons:
a) OSPF v3 should deal with IPv4 as well as IPv6 addresses.
b) The fact that a couple of simple TLVs are needed is not a good
   reason to reinvent the entire TE LSA.

A better approach seems to be to add a couple of *new* TLVs to the v2
TE LSA for IPv6 addresses -- I suggested this to Yakov some time ago,
and this will hopefully be in a forthcoming version of the GMPLS OSPF
TE draft.

I suspect (without seeing your draft) that you have essentially
cut-and-paste the OSPF v2 TE draft.  I believe that to be a flawed
approach as well: it's better to copy by reference rather than by value
whenever you can.  The OSPFv2 TE document is constantly undergoing
changes; the GMPLS extensions are one example; DiffServ TE is another;
others (such as extensions for SONET and G.709) are in the works.  The
approach that maps OSPFv2 TE LSAs directly into OSPFv3 seems much more
scalable and pragmatic -- each such extension is automatically inherited
into OSPF v3 both spec-wise and code-wise.

> you can easily imagine there are some difference between OSPFv2 TE and
> OSPFv3 TE.

I can far more readily imagine that there is a vast overlap :-)

Note that the above applies equally to the Grace LSA.  If you add an
IPv6 TLV to the Grace LSA, it can be used pretty much as is in OSPF v3;
ask Padma Pillay-Esnault for details.

> Intra-Area-Prefix-LSA....  This is another concern...

Where in my draft do you see the use of function code 9?

> verbatim.  We should define each LS type and it's packet format.

I guess we just have different viewpoints.  I do not like to generate
new work just for the fun of it.  *Not* changing the packet format is
so much more pragmatic.

Note that the two approaches are not incompatible.  Go ahead and define
a new LS function code for OSPF v3 TE; change the packet formats; add any
new TLVs you find useful; remove any TLVs you think that OSPF v3 doesn't
need; move bits and bytes around.  Then we'll let the market decide :-)

Kireeti.

---

From: Kunihiro Ishiguro <[email-masked]>
Date: Tue, 8 Oct 2002 08:18:55 -0700

>into OSPF v3 both spec-wise and code-wise.

That is fine.  At least we have to clearly define each extension's
applicability to OSPFv3.  My draft is for that.  It is not a easy
task.  Contrary defining LS type is not a big deal.

I believe OSPFv2's Opaque LSA is a inevitable way to introduce new LS
type.  Because OSPFv2 has very static definition of flooding scope.
In OSPFv3 we addressed it with intoroducing generic flooding
mechanism.  Why are we going to introduce legacy idea from OSPFv2 into
OSPFv3?  Let's make it clean and simple.
--
Kunihiro Ishiguro

---

From: Kireeti Kompella <[email-masked]>
Date: Tue, 8 Oct 2002 08:35:44 -0700

> type.  Because OSPFv2 has very static definition of flooding scope.

Is it so hard to understand the following table from the draft?

       OSPFv2 Opaque
      LSA of LS Type   X Y
      --------------   ---
                   9   0 0
                  10   0 1
                  11   1 0

I guess I should replace it with Vishwas's table ...

Kireeti.

---

From: Acee Lindem <[email-masked]>
Date: Tue, 8 Oct 2002 12:39:35 -0400

Kireeti,

At initial glance, I missed that you are proposing to use a single
function code (you said to only spend a couple minutes ;^).

Note that RFC 2370 doesn't mandate that opaque LSAs must be in TLV
format. Luckily, all the OSPFv2 opaque LSAs in common use today are
composed of TLVs. I think TLV format should be mandated for OSPFv3
opaque LSAs.

I agree that migrating the existing link-state types and opaque
LSAs TLVs makes sense. Since the addressing semantics of IPv6 and IPv4
are different, I don't think you can say that the bodies of the respective
LSAs will be identical. Also, there may be applications which require
additional TLVs for OSPFv3. Hence, I don't think opaque LSAs with TLVs
containing addresses can be migrated to OSPFv3 without at least definition
of the new TLV and IPv6 addressing semantics (e.g., IPv6 address scope).
Hence, I think the paragraph below needs to be expanded to
cover what can and cannot be migrated in tact.

Thanks,

--
Acee

---

From: Kireeti Kompella <[email-masked]>
Date: Tue, 8 Oct 2002 11:01:32 -0700

Hi Acee,

> function code (you said to only spend a couple minutes ;^).

Mea culpa :-)

> Since the addressing semantics of IPv6 and IPv4
> LSAs will be identical.

Bad wording.  Let me try again: the bodies of the respective LSAs are
*formated* identically.  The actual contents may be different, as you
say, but the parsing should be the same.

<  OSPF v3 LSA is identical to the body of the OSPF v2 Opaque LSA.

>  OSPF v3 LSA is formated identically to the body of the OSPF v2 Opaque LSA.

Does that help?

This should address your issue that OSPFv2 Opaque LSAs are not in TLV
format.  E.g., if a new Opaque LSA was defined to have a fixed portion
followed by TLVs, the OSPFv3 version would look the same.

Kireeti.

---

From: Suvani Kaura <[email-masked]>
Date: Wed, 9 Oct 2002 08:42:24 -0700

Hi All,

Is it legal for an Intra Area Prefix LSA to be advertised with zero
prefixes?

Case in point: if a router with a single interface running OSPFv3 is
DR but there is no active router on that link, it originates an intra
area prefix lsa referencing its router LSA.  Subsequently another
router (DR-other) comes up on that link, & therefore the DR
originates a Network LSA & moves the prefix information to the intra
area prefix lsa referencing the network LSA.  Should it now withdraw
its old intra area prefix lsa referencing the router LSA or should it
re-advertise it with zero prefixes?

Thanks for your input,
Suvani

__________________________________________________
Do you Yahoo!?
Faith Hill - Exclusive Performances, Videos & More
http://faith.yahoo.com

---

From: Yasuhiro Ohara <[email-masked]>
Date: Thu, 10 Oct 2002 03:50:04 +0900

Hi.

My view is "legal, but should be avoided". I guess it can be thought
as a inefficiency of the implementation.

I get a similar feeling from the implementation that generates
multiple AS-External LSAs for a single prefix...

The answer should be "withdraw rather than re-advertise".

regards,
yasu

bg24096> Hi All,
bg24096>
bg24096> Is it legal for an Intra Area Prefix LSA to be advertised with zero
bg24096> prefixes?
bg24096>
bg24096> Case in point: if a router with a single interface running OSPFv3 is
bg24096> DR but there is no active router on that link, it originates an intra
bg24096> area prefix lsa referencing its router LSA.  Subsequently another
bg24096> router (DR-other) comes up on that link, & therefore the DR
bg24096> originates a Network LSA & moves the prefix information to the intra
bg24096> area prefix lsa referencing the network LSA.  Should it now withdraw
bg24096> its old intra area prefix lsa referencing the router LSA or should it
bg24096> re-advertise it with zero prefixes?
bg24096>
bg24096> Thanks for your input,
bg24096> Suvani
bg24096>
bg24096> __________________________________________________
bg24096> Do you Yahoo!?
bg24096> Faith Hill - Exclusive Performances, Videos & More
bg24096> http://faith.yahoo.com

---

From: Sina Mirtorabi <[email-masked]>
Date: Wed, 9 Oct 2002 15:35:37 -0700

Suvani

To add to what Yasu already said, re-advertising with zero prefix behavior
could further not work in all cases ( so not a generic solution )
for example when you your router has some prefix with AL bit set ( /128)
then those prefixes are Not added to intra-area prefix referencing network
LSA and you have to keep it in intra-area prefix referncing a Router LSA,
therefore you have to maxage only some prefixes but not all of them ..

Sina

> -----Original Message-----
> From: Mailing List [mailto:[email-masked]]On Behalf Of
> Suvani Kaura
> Sent: Wednesday, October 09, 2002 8:42 AM
> To: [email-masked]
> Subject: OSPFv3 Intra area prefix LSA
>
>
> Hi All,
>