From: Mike Fox (mjfoxUS.IBM.COM)
Date: Tue Apr 08 2003 - 16:32:03 CDT

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

I've skimmed the archives all the way back and I don't think I've seen this
addressed, but other implementations must have answered this question for
themselves.

What is the definitive way to remove a link from a Router LSA? This could be
necessary because either the link has been deleted from the router, or the
link no longer meets the requirement for being included in the router LSA
(for example, the router lost all its adjacencies over the link). In
OSPFv2, it's done by sending a new router advertisement without the link.
Now with multiple router advertisements, it can get tricky. That
observation drives the following question:

Are link memberships in router LSAs "sticky"? It seems to me that this is
almost necessary to have decent convergence on removed links.

For example, assume RT1 originates three router LSA's into an area, as follows:

Link state id: 1
Advertising Router: RT1
links: link1, link2

Link state id: 2
Advertising Router: RT1
links: link3, link4

Link state id: 3
Advertising router: RT1
links: link5

Now if, RT1 later sends the following Router LSA:

Link State id: 2
Advertising Router: RT1
links: link4

Is this enough to cause other routers to realize that link3 has been removed
from router1? Or is it necessary for them to verify that link3 has not
moved to the router LSA with link state id 1 or 3, or even a new one with
link state id 4? If links are not "sticky", then how long should a
receiving router wait to make sure it doesn't receive new copies of another
LSA containing that link before it can decide that link is deleted from RT1?

Also, if links are not "sticky", consider the original case above but now
link5 has been deleted. How can RT1 communicate that fact? If links are
sticky he can just flush the router LSA with link state id 3. If they
aren't, that would not be sufficient because other routers would have to
verify that link5 hasn't moved to another link state id, meaning waiting an
interval to make sure a new router LSA with link5 in it does not arrive from
RT1.

In either case, if the links are not sticky to their specific router LSA
instances, what's necessary starts to look suspiciously like recreating
TCP's fragmentation/reassembly logic in the routing process.

Btw, the same question can be asked about intra-area-prefix LSAs. Are
prefixes sticky to particular intra-area-prefix LSA instances (link state
IDs)? Virtually the same problems and questions arise about them.

Mike

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]