Subject: [OSPF] OSPF NSSA ABR bahaviors

From: "James Huang" <[email-masked]>
Date: Thu, 4 Feb 2010 13:23:25 -0800

Hi all,

I have a few questions regarding NSSA ABR: 

(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?

(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.  

(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)?

Thanks,

James Huang

---

From: "Patrick W. Murphy, Ph.D." <[email-masked]>
Date: Thu, 04 Feb 2010 17:27:30 -0800

>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.

>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.

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

From: [email-masked] [mailto:[email-masked]] On Behalf Of
James Huang
Sent: Thursday, February 04, 2010 1:23 PM
To: [email-masked]
Subject: [OSPF] OSPF NSSA ABR bahaviors

Hi all,

(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?

(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.  

(3)    RFC 3101 sec 3.2:

Thanks,

James Huang

---

From: "James Huang" <[email-masked]>
Date: Fri, 5 Feb 2010 12:51:51 -0800

Hi Pat,
	See my comments below.

-- James Huang

>From: Patrick W. Murphy, Ph.D. [mailto:[email-masked]] 
>Sent: Thursday, February 04, 2010 5:28 PM
>To: [email-masked]
>Cc: James Huang
>Subject: RE: [OSPF] OSPF NSSA ABR behaviors
>
>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.

>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.

>>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):

          [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?