Subject: [OSPF] flush translated lsas

From: p6 c6d6 <[email-masked]>
Date: Tue, 11 Jan 2011 20:38:30 +0530

hi,

In nssa, when an nssa border router elected as translator loses
it's translator status. after the translator stability interval has
expired, rfc suggests to flush only the aggregated translated lsas
but not the normal translated type-5 lsas. why give special treatment
to only aggregated lsas any specific reason.

thanks

---

From: "Pat Murphy - (650)329-4044" <[email-masked]>
Date: Wed, 12 Jan 2011 11:36:51 -0700 (PDT)

>to only aggregated lsas any specific reason.

The last sentence in NSSA RFC 3101 Section 3.3 states

   ...This minimizes the flushing and flooding impact on the transit
   topology of an NSSA that changes its translators frequently.

At the time I wrote this I was reflecting on some painful experiences with 
router flap. A continuous flap of an NSSA's elected translator might have 
an adverse effect on its processing capability as well as the full OSPF 
transit topology. Since these Type-5 translations simply mirror their 
corresponding Type-7 advertisements, allowing them to simply age out seemed 
appropriate. If a translator is re-elected shortly thereafter it could then 
re-assume its translator duties without re-originating these Type-5 
translations. Of course for this statement to be fully effective an 
implementer must mitigate the effect on Type-5 translations of the 
following note from OSPF RFC 2328 Section 12.4.4.1:

    ...if two routers, both reachable from one another, originate
    functionally equivalent AS-external-LSAs (i.e., same destination,
    cost and non-zero forwarding address), then the LSA originated by
    the router having the highest OSPF Router ID is used. The router
    having the lower OSPF Router ID can then flush its LSA.

A similar statement is included for Type-7 LSAs in RFC 3101 Section 2.4. 
Even if this statement is not mitigated, a delay by the deposed translator 
in flushing Type-5 translations until the new NSSA translator's Type-5 
translations are receive seems beneficial. Premature flushing effects 
routing.

Note that at the time NSSA RFC 3101 was published routing engine processing 
power and memory was not what it is today; also bandwidth was expensive so 
that OSPF deployments over much slower links than are currently used was 
commonplace. Given the kinds of memory that modern routers have perhaps the 
last sentence in the above note from 12.4.4.1 is not even necessary. It is 
certainly not a requirement for inter-operability.

Pat

Date: Tue, 11 Jan 2011 20:38:30 +0530
From: p6 c6d6 <[email-masked]>
Subject: [OSPF] flush translated lsas
Sender: [email-masked]
To: [email-masked]

hi,

thanks