Subject: Opaque LSA question: attaching OSPF interface to different area

From: Alex Levit <[email-masked]>
Date: Mon, 27 Oct 2003 14:02:59 +0200

Hi All,

Does anyone know about any specification what is to be done to Opaque LSA
type 9 (or 10)
when an OSPF interface through which it was originated is attached to area
different than it was
at the originating time?

The LSA probably needs to be altered and re-originated, but does it making
any sense that OSPF will do the job itself
or the opaque application needs to be involved here?

Does it matter if interface was brought down and then up after reattaching
to new area?

Thanks,
Alex

---

From: Acee Lindem <[email-masked]>
Date: Mon, 27 Oct 2003 10:02:34 -0500

Hi Alex,

>when an OSPF interface through which it was originated is attached to area
For type 9, it  is obvious the  initial LSA should be purged and a new
one originated. For type 10,
the LSA is associated with an area as opposed to an interface.  If the
contents of the LSA are
specific to the interface that has been moved to a different area (e.g.,
a TE LSA containing a
link TLV), then the LSA should be purged from its former area and
originated in the  new area.

>or the opaque application needs to be involved here?
Whether it needs to get involved or not, the LSA purge/originations
should be signaled to the opaque
application.

>Does it matter if interface was brought down and then up after reattaching
I'd say "no" -  from the perspective of OSPF it is a different interface.

---

From: Vanitha N <[email-masked]>
Date: Tue, 28 Oct 2003 10:47:53 +0530

Hi Alex,

>>> Why should we generate the Type9 LSA. Its scope is only interface. What
do we gain by regenerating the LSA with the same contents. It is enough if
the database synchronization takes care about flooding the original LSA
during adjacency reformation.

I agree with Type 10 LSA that if the contents of the LSA are specific to the
interface (TE), we need to regenerate the TE Link in new area.
But if the Type10 LSA is from some other application for the old area, it
should not be regenerated.

>Alex

***************************************************************************
This message is proprietary to Future Software Limited (FSL)
and is intended solely for the use of the individual to whom it
is addressed. It may contain  privileged or confidential information
and should not be circulated or used for any purpose other than for
what it is intended.

If you have received this message in error, please notify the
originator immediately. If you are not the intended recipient,
you are notified that you are strictly prohibited from using,
copying, altering, or disclosing the contents of this message.
FSL accepts no responsibility for loss or damage arising from
the use of the information transmitted by this email including
damage from virus.
***************************************************************************

---

From: Acee Lindem <[email-masked]>
Date: Tue, 28 Oct 2003 09:28:58 -0500

Hi Vanitha,

Please configure you're E-mail client to quote your reply so that is it
easy to see what you've
said.

>during adjacency reformation.
It is true that there is nothing in the contents of the LSA specific to
the area and you could avoid
regeneratting the LSA internally. However, the flooding will be the same
since the scope is
interface. It is much simpler conceptually to treat the move from one
area to another as an
interface deletion and creation.

>should not be regenerated.
I believe this is the corollary of what I said.