Subject: Re: [OSPF] OSPF NSSA ABR behaviors

From: "Pat Murphy - (650)329-4044" <[email-masked]>
Date: Fri, 05 Feb 2010 19:37:06 -0700 (PDT)

James,

I can only respond to your questions regarding the RFC 3101 
specification. Specific implementations can deviate from RFC 3101. RFC 
3101 is an optional OSPF addition. Deviations from the original NSSA 
specification are not wrong. They are just different and perhaps not 
fully featured. Usually most of the more popular and useful features 
will be present. For specific implementations you will have to refer to 
implementation specific NSSA documentation. The RFC 3101 specification 
has been in place for years and to date only one minor tweak has been 
reported. A complete implementation should function as I have described.

Note NSSA is widely used. Perhaps its status as optional should change. 
Incomplete implementations are disappointing and confusing. In the 
meantime folk should talk to their vendors about the features they need 
and perhaps these features will be added in future releases.

Pat

Date: Fri, 05 Feb 2010 16:58:16 -0800
From: James Huang <[email-masked]>
Subject: RE: [OSPF] OSPF NSSA ABR behaviors
In-reply-to: <[email-masked]>
To: "Pat Murphy - (650)329-4044" <[email-masked]>, [email-masked]

Hi Pat,

	I did some NSSA test on a router (with very new software
installed) from the #1 networking vendor.
Here is my observation about their NSSA ABR behavior with regarding to
external LSA aggregation:

(1) When an NSSA ABR does not have any locally sourced external routes
matching an address range, it will aggregate installed type-7 LSAs =
(p=3D1)
received from the NSSA matching the address range into a type-5 LSA and
advertise the LSA to the transit topology.=20

(2) When an NSSA ABR has some locally sourced external routes subsumed
within an address range (may or may not be strictly), it will aggregate
installed type-7 LSAs (p=3D1) received from the NSSA matching the =
address
range and all those external routes into a type-5 LSA and advertise the
LSA into the transit topology. In addition, it will originate a
corresponding type-7 LSA (same destination, cost, and advertising router
as the aggregated type-5 LSA, p=3D0, forwarding address=3D0) to the NSSA
area. It will not originate a type-7 LSA individually for each of the
locally sourced external routes.

So their NSSA ABR behavior does not seem to comply with what was stated
in your previous email in two ways:
(1) origination of an aggregated type-5 LSA from at least one locally
sourced external route will always force the origination of a
corresponding type-7 LSA (p=3D0) into the NSSA, and
(2) locally sourced external routes subsumed within the address range
are aggregated into the type-5 LSA. They does not have to have the same
[address, mask] as the address range.

Now I am really confused.

-- James Huang
  =20

>-----Original Message-----
>From: Pat Murphy - (650)329-4044 [mailto:[email-masked]]
>Sent: Friday, February 05, 2010 2:20 PM
>To: [email-masked]
>Cc: James Huang
>Subject: Re: [OSPF] OSPF NSSA ABR behaviors
>
>James,
>
>See comments inline.
>
>P>Thus if one desires to aggregate the external route during Type-7
>P>translation using a Type-7 address range then a Type-7 LSA with the
P-
>bit
>P>set must be originated.
>
>P>Note the latter statement from RFC 3101 simply ensures that non-NSSA
>P>traffic forwarded by a Type-5 LSA installation toward a forwarding
>address
>P>inside an NSSA won't loop. I prefer originating the Type-7 LSA with
>the
>P>P-bit set and simply letting the Type-7 translation process originate
>the
>P>Type-5 LSA. Thus Type-5 LSAs would then never need to set a
forwarding
>P>address that belongs in a stub area or an NSSA, except during the
>Type-7
>P>LSA translation process. Hence if the best forwarding address is in
>the
>P>transit topology, it is better to originate both a Type-5 LSA and a
>Type-7
>P>LSA with the P-bit clear. If the best forwarding address belongs to
>the
>P>NSSA, it is better to simply originate a Type-7 LSA with the P-bit
set
>and
>P>let the Type-7 translation process originate the Type-5 LSA.
>
>J>When you say a router originates a type-7 LSA, does it mean
>J>that the type-7 LSA will be advertised?
>
>Of course, all LSAs are advertised by an originating router.
>See RFC 2328 Appendix A.4.1, "The LSA header".
>
>J>Or it simply means that the type-7 LSA is generated internally
>J>and it depends on the translation process to determine whether
>J>it should be aggregated with some other external LSA(s) or be
>J>advertised individually?
>
>Like all LSAs, Type-7 LSAs are only generated to be originated
>by an advertising router. But once originated with the P-bit set
>the Type-7 LSA may generate a Type-5 translation as described in
>RFC 3101 Section 3.2, Translating Type-7 LSAs into Type-5 LSAs.
>
>P>Let's assume that the redistribute is intended to feed the route
>P>into all NSSAs and the non-NSSA topology. If (G) belongs to the non-
>NSSA
>P>topology, originate a Type-5 LSA with forwarding address (G) into the
>P>non-NSSA topology and also originate a Type-7 LSA with the P-bit
clear
>P>into each NSSA. Here the Type-7 LSAs can simply use a 0.0.0.0
>forwarding
>P>address. If (G) belongs to one of the NSSAs, then originate a Type-7
>LSA
>P>with the P-bit set into that NSSA with the forwarding address set to
>(G).
>P>Finally originate a Type-7 LSA with the P-bit clear into the
remaining
>P>NSSAs. Note again that Type-7 translation will cause the appropriate
>P>Type-5 LSA to be originated into the non-NSSA topology.
>
>J>Agree - assuming address aggregation is not performed.
>
>Type-7 ranges that subsume only a single prefix with the same
>[address,mask] pair result in a normal translation. Hence, since
>type-7 ranges can even subsume other type-7 ranges, one can negate
>the effects of aggregation under configuration control. This is a
>subtle point from RFC 3101 Section 3.2.
>
>J>On a related question: When a MSSA ABR originates a aggregated
>J>type-5 LSA, does it has to advertise a corresponding type-7 (p=3D0)
>J>LSA into the NSSA area?  I cannot find any rule in RFC 3101 about
>this.
>
>The origination of a type-5 LSA generated by the translation of a
>type-7 LSA NEVER forces the origination of another type-7 LSA.
>
>J>I think the answer is no unless more than one locally sourced
>J>external LSAs with the best forwarding addresses NOT in the NSSA are
>J>aggregated into the type-5 LSA (otherwise, individual type-7 LSA
>J>(p=3D0) should be advertised).   Is this correct?
>
>The non-zero forwarding addresses of Type-7 LSAs are always
>chosen from interfaces that belong to the NSSA. See Section 2.3.
>A type-5 translation that aggregates a set of installed type-7
>LSAs also NEVER forces the origination of another type-7 LSA.
>
>J>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.
>
>J>What is the reason aggregation can only aggregate those locally
>sourced
>J>type-5 LSAs with the same [address, mask] as the configured address
>range?
>
>Since this is an aggregation its metric must reflect the highest cost
>amongst the type-7 LSAs being aggregated. A locally source type-5 LSA
>that has the same [address,mask] pair coupled with a lower cost could
>negate the translation metrics. Similarly a lower cost in the Type-5
>translation of a type-7 range would negate the high cost of a
>locally sourced type-5 LSA with the same [address,mask] pair. Hence
>a single advertisement is required.
>
>J>If a locally sourced type-5 LSA is subsumed within the range, can it
>J>be aggregated too?
>
>No. The above excerpt is the only exception.
>
>Pat
>
>
>

---

From: "James Huang" <[email-masked]>
Date: Mon, 8 Feb 2010 13:40:15 -0800

Hi Pat,
	One more question about NSSA ABR:

In RFC 3101, Section 2.5, step (6e), the following priorities are
specified to resolve multiple functional equivalent external LSAs (same
destination, cost, and non-zero forwarding address):

                 1. A Type-7 LSA with the P-bit set.
                 2. A Type-5 LSA.
                 3. The LSA with the higher router ID.  

This means that type-7 LSA with P-bit set is preferred over type-5 LSA
and type-5 LSA is preferred over type-7 LSA with P-bit clear.

I checked the old NSSA RFC (RFC 1587), it specifies a different priority
ordering:

                 a. Any type 5 LSA.
                 b. A type-7 LSA with the P-bit set and the forwarding
                    address non-zero.
                 c. Any other type-7 LSA.

What is the reason for this change?

Thanks,
James Huang

>From: [email-masked] [mailto:[email-masked]] On Behalf Of
>Pat Murphy - (650)329-4044
>Sent: Friday, February 05, 2010 6:37 PM
>To: [email-masked]
>Cc: [email-masked]
>_______________________________________________
>OSPF mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/ospf