Subject: Re: [OSPF] OSPF NSSA ABR behaviors

From: "Pat Murphy - (650)329-4044" <[email-masked]>
Date: Wed, 10 Feb 2010 17:57:20 -0700 (PDT)

James,

Sorry for the weak example. The incremental update of Type-5 and Type-7 
LSAs is described in RFC 3101 Section 2.6; and it is true that the entire 
routing table entry for the destination N is invalidated before the 
recalculation. However multiple functionally equivalent external Type-5 
and Type-7 LSAs with non-zero forwarding addresses can coexist in the 
LSDB. They will eventually be purged to just one by flushing as described 
in RFC 2328 Section 12.4.4.1 and RFC 3101 Section 2.4 so that only one LSA 
will remain in the stable topology (except for Type-5 translations of 
Type-7 LSAs). A set of such beasts can have Type-7 LSAs with both the 
P-bit set and not set. Flushing is not immediate. These tie breaker rules 
simply insure that only one of these LSAs is installed at all times. I 
could have dropped (2) in the tie breaker rules:

  1. A Type-7 LSA with the P-bit set.

  2. A Type-5 LSA.

  3. The LSA with the higher router ID.

However (2) does emphasize that (3) applies to both Type-5 and Type-7 
LSAs. Furthermore, as you have noticed, a broken topological deployment 
(or a more forgiving implementation) can break the intent of the last 
paragraph of Section 2.5 step (3). The tie breaker rules simply ensure 
that the calculation always only installs one LSA for a set of external 
LSAs that are functionally equivalent with a non-zero forwarding address. 
The rules, as they are written, are fine and recommended. However, if an 
implementation chooses to ignore them, it should not effect a stable 
proper topology.

Pat

Return-path: <[email-masked]>
Received: from gscamnls01.wr.usgs.gov (gscamnls01.wr.usgs.gov 
[130.118.4.108])
 by omega7.wr.usgs.gov (PMDF V6.0-23 #41392)
 with ESMTP id <[email-masked]> for
 [email-masked] (ORCPT [email-masked]); Wed,
 10 Feb 2010 10:48:42 -0700 (PDT)
Received: from mx1.watchguard.com (HELO watchguard.com) 
([206.191.171.101])
 by gscamnls01.wr.usgs.gov with ESMTP; Wed, 10 Feb 2010 10:48:54 -0800
Date: Wed, 10 Feb 2010 10:48:37 -0800
From: James Huang <[email-masked]>
Subject: RE: RE: [OSPF] OSPF NSSA ABR behaviors
In-reply-to: <[email-masked]>
To: "Pat Murphy - (650)329-4044" <[email-masked]>
Cc: [email-masked]

Pat,

In your area partitioning scenario, the decision about whether to prune
a type-5 
or a functionally equivalent type-7 LSA can be done at the check in the
last 
paragraph of step (3) of sec 2.5.  There are three cases:
(1) network N (which contains the forwarding address X) and this ABR
router are in the 
    same partition: 
    In this case, the route to network N is intra-area through the NSSA.
    So step (3) of sec 2.5 will prune the type-5 LSA.
(2) network N and this ABR are in different partitions:  
    In this case, the route to network N is inter-area. 
    So step (3) of sec 2.5 will prune the type-7 LSA.  
    Later when the partitioning is repaired and the route to network N
is changed back to 
    intra-area, step (3) of sec 2.5 will prune the type-5 LSA and let
the type-7 LSA pass.  
(3) both the NSSA area and the network N itself are partitioned:
    OSPF cannot handle this case. The part of Network N in the other
partition is always 
    unreachable.

So I still do not see when the tie-breaker rules at sec 2.5 step (6e)
will ever get applied.
As for incremental updates, I assume that this ABR will perform a full
SPF computation when 
a new router LSA or a new network LSA is received (as per RFC 2328).  
But even if iSPF is performed for intra-area routes instead, we still
have to reexamine all 
external routes (at least those with a forwarding address in N) after
iSPF computation for 
intra-area routes completes. So the above arguments are still valid.

-- James Huang      

>-----Original Message-----
>From: Pat Murphy - (650)329-4044 [mailto:[email-masked]]
>Sent: Tuesday, February 09, 2010 5:01 PM
>To: James Huang
>Cc: [email-masked]
>Subject: FWD: RE: [OSPF] OSPF NSSA ABR behaviors
>
>James,
>
>You seem to be questioning whether the tie breakers rules ever apply.
>Don't
>forget that the calculation is linear; plus it can be updated
>incrementally. If
>the NSSA partitions separating the R2 translator and its R3 ASBR from
>R1, then
>R1 will install the Type-5 translation. Later, when the full NSSA is
>restored,
>R1 will have to make an incremental decision about what to do with the
>installed Type-5 LSA as soon as it receives the newly arrived Type-7
>LSA. In
>this case the already installed Type-5 LSA will be pruned by the tie
>breaker
>rules. Indeed anomalous topologies can probably tweak all of the tie
>breaker
>rules.
>
>Also don't forget in Scenario 1 that aggregations always add +1 to
their
>E2
>metrics.
>
>In Scenario 2, the broken configuration, a Type-5 LSA is preferred over
>a
>Type-7 LSA with a zero P-bit simply because a zero P-bit indicates
there
>is no
>intent that the Type-7 path be a transit path for the full OSPF domain.
>
>Pat
>
>[James Huang]
>
>I have a few scenarios. Let's assume the non-zero forwarding address is
>X,
>which is part of a subnet N, in the following discussion.
>
>(Scenario 1)
>
>Assuming multi-area network is not allowed (i.e. N is part of the NSSA
>area
>only). There are two ABRs, R1 and R2, in this NSSA and R1 is this
router
>doing
>the route computation. An ASBR R3 within the NSSA originates a type-7
>P=1
>E2-cost LSA.
>
>(case 1.1) R2 translates type-7 LSA to type-5 LSA without aggregation:
>
>In this case, R1 may receive one <type-7, P=1, FA=X, ADV=R3> LSA from
>NSSA and
>another <type-5, FA=X, ADV=R2> LSA from the transit topology. The
>routing table
>for N is intra-area associated with the NSSA. So the type-5 LSA will
not
>pass
>the check in the last paragraph of step (3) of sec 2.5.
>
>(case 1.2) R2 translates type-7 LSA to type-5 LSA with aggregation
>(aggregating
>with some other LSAs):
>
>In this case, R1 may receive one <type-7, P=1, FA=X, ADV=R3> LSA from
>NSSA and
>another <type-5, FA=0, ADV=R2> LSA from the transit topology. The
>routing table
>for N is intra-area associated with the NSSA. If the routing table for
>R2 is
>non-backbone intra-area and the cost from R1 to N and from R1 to R2 are
>the
>same, then R1 will install both LSAs into the routing table.
>
>So neither (1.1) nor (1.2) requires the tie-breaking rule in sec 2.5
>(6e).
>
>(Scenario 2)
>
>Assuming multi-area network is allowed. Let's say, subnet N is part of
>this
>NSSA area 1 and another type-5 capable area 2. R1 is this ABR router in
>area 1
>and R2 (an ASBR within area 1) originates a <type-7, P=1, FA=X, ADV=R2,
>E2-cost> LSA. R3 (an ASBR within area 2) also originates a <type-5,
>FA=X,
>ADV=R3, E2-cost> LSA. This type-5 LSA may traverse the transit topology
>to
>reach R1
>
>There are two sub-cases here:
>
>(case 2.1) R1 is not connected to area 2: The route for N is intra-area
>through
>the NSSA area 1 (intra-area route is preferred over inter-area route).
>So the
>type-5 LSA will not pass the last paragraph of step (3) of sec 2.5.
>
>(case 2.2) R1 is also connected to area 2: The route for N is
intra-area
>through the area 1 and area 2. In this case, the tie-breaking rule in
>sec 2.5
>(6e) will be used. According to rule (6e), R1 should prefer the type-7,
>P=1,
>FA=X, ADV=R2, E2-cost> LSA over the <type-5, FA=X, ADV=R3, E2-cost>
LSA.
>But if
>the type-7 LSA has P=0, R1 should prefer the type-5 LSA over type-7
LSA.
>
>Why is it so?
>
>I know that RFC 2328 does not support multi-area network. So case (2)
is
>not
>valid in that sense. But I just cannot find other cases where the rule
>in sec
>2.5 (6e) will be used for tie-breaking with good rationales.
>
>Thanks,
>James Huang =20
>
>
>
>
>>Hope this helps.
>>
>>Pat
>>
>>
>

---

From: "Pat Murphy - (650)329-4044" <[email-masked]>
Date: Tue, 16 Feb 2010 17:40:44 -0700 (PDT)

James,

When I wrote:

P>Regarding OSPF RFC 2328 Section 16.6, "Incremental updates -- 
P>AS-external-LSAs", and NSSA RFC 3101 Section 2.6, "Incrementalupdates",
P>there is some efficiency to simply first running the NSSA Section 2.5 
P>calculation on the newly arrived external LSA to see if it actually 
P>replaces the current route to its destination N; or it simply updates 
P>the route's current list of next hops and/or installed LSAs; or it is 
P>not installed. This is only slightly different than what would happen if
P>the newly arrived external LSA were simply the last LSA to pass through 
P>the calculation of NSSA Section 2.5.

my intent is that the preferences defined in NSSA RFC 3101 step 6, which 
include the (6)(e) priorities,

  2. A Type-5 LSA.

should result in a set of next hops for the Type-7 LSA's(s') network(s) N 
that reflects the current state of the LSDB.

Let's not over think this. Some topologies have routers that use their 30 
second Hello intervals and 120 second router-dead-intervals (2 minute) 
default settings. These specs simply define an orderly process that keeps 
everything in sync with the LSDB as best as possible at all times. 

Regarding,

J>Does it really matter that the LSA with highest router-ID is installed?
J>After all, they all have the same non-zero forwarding address.
J>So the same next-hop(s) will be computed regardless which one
J>of the functional equivalent LSAs is installed. 

Yes it does as only installed LSAs with the P-bit set are translated. Also 
a current accurate external routing table that reflects actual installed 
LSAs should help keep the external portion of the OSPF routing table 
stable. If a change is as simple as updating the LSA source of a next hop, 
it should be done (See OSPF RFC 2328 Section 11).

Note again that as long as the preferences and priorities of Section 2.5 
are followed the incremental handling of external LSA updates is 
implementation specific. How this is done is a matter of taste. If you 
have more questions let's take them off line, barring any objections from 
this list.

Pat