Re: [OSPF] OSPF NSSA ABR behaviors

["James Huang" <[e-mail]>]

Hi Pat,
	See my comments below.

-- James Huang


>From: Patrick W. Murphy, Ph.D. [mailto:[e-mail]] 
>Sent: Thursday, February 04, 2010 5:28 PM
>To: [e-mail]
>Cc: James Huang
>Subject: RE: [OSPF] OSPF NSSA ABR behaviors
>
>My NSSA recollections are getting dimmer and dimmer. But here it is:
>
>>(1)    Under what circumstances will an ABR originate type-7 LSAs with
>>P-bit set to 1 into a NSSA area for locally sourced external routes?
>>And why is it better than itself originating a type-5 LSA into type-5 
>>capable areas and a type-7 LSA with P-bit set to 0 into NSSA areas?
>
>RFC 3101 simply states:
>
>   If the border router only originates a Type-7 LSA, it
>   may set the P-bit so that the network may be aggregated/propagated
>   during Type-7 translation.  If an NSSA's border router originates a
>   Type-5 LSA with a forwarding address from the NSSA, it should also
>   originate a Type-7 LSA into the NSSA.
>
>Thus if one desires to aggregate the external route during Type-7 translation using a Type-7 address range then >a Type-7 LSA with the P-bit set must be originated.
>
>Note the latter statement from RFC 3101 simply ensures that non-NSSA traffic forwarded by a Type-5 LSA >installation toward a forwarding address inside an NSSA won't loop. I prefer originating the Type-7 LSA with >the P-bit set and simply letting the Type-7 translation process originate the Type-5 LSA. Thus Type-5 LSAs >would then never need to set a forwarding address that belongs in a stub area or an NSSA, except during the >Type-7 LSA translation process. Hence if the best forwarding address is in the transit topology, it is better >to originate both a Type-5 LSA and a Type-7 LSA with the P-bit clear. If the best forwarding address belongs to >the NSSA, it is better to simply originate a Type-7 LSA with the P-bit set and let the Type-7 translation >process originate the Type-5 LSA.
>
>

[James Huang] 

When you say a router originates a type-7 LSA, does it mean that the type-7 LSA will be advertised?
Or it simply means that the type-7 LSA is generated internally and it depends on the translation process to determine whether it should be aggregated with some other external LSA(s) or be advertised individually?  What you said above will make sense if the answer is the second one.


>>(2)    Suppose an ABR is connected to area 0 and multiple NSSA areas, it
>>redistributes locally sourced external route for subnet N into OSPF, 
>>and this ABR is a translator for all of its NSSA areas.  In this case, 
>>what will the type-5/type-7 LSAs originated by this ABR for subnet N 
>>look like (in terms of LSA-type, forwarding address, P-bit setting)?  I 
>>think there are at least three sub-cases here, depending on where the 
>>next hop gateway (G) for N is located: (2.1) G is not within the OSPF 
>>domain;(2.2) G is within area 0; (2.3) G is within one of the NSSA areas.
>
>If one follows my recommendation above, the answer depends on whether N belongs to one of the NSSAs or to the >non-NSSA topology. Also does your implementation allow the granularity of deciding whether or not to >redistribute the route into each NSSA specifically as well as the non-NSSA topology. Let's assume that the >redistribute is intended to feed the route into all NSSAs and the non-NSSA topology. If (G) belongs to the non->NSSA topology, originate a Type-5 LSA with forwarding address (G) into the non-NSSA topology and also originate >a Type-7 LSA with the P-bit clear into each NSSA. Here the Type-7 LSAs can simply use a 0.0.0.0 forwarding >address. If (G) belongs to one of the NSSAs, then originate a Type-7 LSA with the P-bit set into that NSSA with >the forwarding address set to (G). Finally originate a Type-7 LSA with the P-bit clear into the remaining >NSSAs. Note again that Type-7 translation will cause the appropriate Type-5 LSA to be originated into the non->NSSA topology.


[James Huang] 
Agree - assuming address aggregation is not performed.


>>(3)  RFC 3101 sec 3.2:
>>          The path type and metric of the Type-7 address range is
>>          determined from the path types and metrics of those
>>          translatable Type-7 LSAs that best match the range plus any
>>          locally sourced Type-5 LSAs whose network has the same
>>          [address,mask] pair.  If any of these LSAs have a path type of
>>          2, the range's path type is 2, otherwise it is 1.  If the
>>          range's path type is 1 its metric is the highest cost amongst
>>          these LSAs; if the range's path type is 2 its metric is the
>>          highest Type-2 cost + 1 amongst these LSAs.  (See Section 2.5
>>          step (5).)  1 is added to the Type-2 cost to ensure that the
>>          translated Type-5 LSA does not appear closer on the NSSA
>>          border than a translatable Type-7 LSA whose network has the
>>          same [address,mask] pair and Type-2 cost.
>>
>>Can someone explain the reason for adding 1 to the type-2 cost above (in plain English please)?

>It is entirely possible that a Type-7 LSA may be aggregated by a Type 7 range into a Type-5 translation that >has the same prefix ([address,mask] pair) as the Type 7 LSA. If there are other Type 7 LSAs subsumed by the >same Type 7 range then the forwarding address of the Type-5 translation is set to 0.0.0.0. This could easily >make the Type-5 translation appear closer on the border than the original Type-7 LSA, thus potentially causing >a tight righting loop. I believe OSPF Section 16.4.1 resolves this issue unless RFC1583Compatibility is set to >"enabled". Regardless retaining the metric settings of RFC 1587 translation process maintained compatibility >with older implementations.
>
>
>Pat


[James Huang] 
I see.  Adding 1 to the type-2 cost is to make sure that the aggregated type-7 LSA (p=0) sent into the NSSA area will have a larger metric than the original type-7 (p=1) LSA (with the same [address, range]) received from the NSSA.  This will prevent the other router in the NSSA area from choosing the best route for the destination towards this ABR.   But, as you has pointed out, RFC2328 sec16.4.1 will prefer intra-area forwarding address/advertising router.  So this will not happen if RFC1583Compatibility is set to disabled.  Note the tie breaking rule in sec 2.5, step (6e) will not help the other routers to choose the right type-7 LSA because these two LSAs are not functionally equivalent (one has forwarding address set to 0). 

On a related question: When a MSSA ABR originates a aggregated type-5 LSA, does it has to advertise a corresponding type-7 (p=0) LSA into the NSSA area?  I cannot find any rule in RFC 3101 about this.  I think the answer is no unless more than one locally sourced external LSAs with the best forwarding addresses NOT in the NSSA are aggregated into the type-5 LSA (otherwise, individual type-7 LSA (p=0) should be advertised).   Is this correct?  

One more question, RFC3101, sec 3.2 step (3):

   The path type and metric of the Type-7 address range is
          determined from the path types and metrics of those
          translatable Type-7 LSAs that best match the range plus any
          locally sourced Type-5 LSAs whose network has the same
          [address,mask] pair.

What is the reason aggregation can only aggregate those locally sourced type-5 LSAs with the same [address, mask] as the configured address range?  If a locally sourced type-5 LSA is subsumed within the range, can it be aggregated too?