Subject: Re: [OSPF] Re:Generating type5 LSA in ospfv3

From: "Pat Murphy - (650)329-4044" <[email-masked]>
Date: Mon, 01 May 2006 17:33:38 -0700 (PDT)

>I think that in this situation, the ABR must inhibit
>or flush the any NSSA default it is injecting into the NSSA area. 
>However, it doesn't appear RFC 3101 handles this case (Pat can correct 
>me if I'm wrong).

When I re-wrote the spec the intent was that the NSSA ABR would always 
originate a default LSA unless it loses its ABR status via transit 
topological failure. Adding the no-summary option triggered this 
decision and I saw no reason to have a different behavior when summary 
routes are imported. It is the nature of a stub area. In all situations 
they must have a default or they can lose access to the full OSPF 
domain's routing environment. The last paragraph of Section 2.4, 
Originating Type-7 LSAs, states it as a "MUST" for those who adhere to 
IETF vernacular.

   NSSA border routers must originate an LSA for the default destination
   into all their directly attached NSSAs in order to support intra-AS
   routing and inter-AS routing.  This default destination is advertised
   in either a Type-3 LSA or a Type-7 LSA, as described in Section 2.7.
   The default LSA's metric should be configurable. For Type-7 default
   LSAs, the metric type (1 or 2) should also be configurable.

Clearly an NSSA ABR's self originated type 7 default LSA can be 
configured, via metrics, as the NSSA's default path of last resort; 
hence this should not be a problem. Regardless it never factors into the 
installation of default on any NSSA ABR as describe below.

The third paragraph of RFC 3101 Section 2.4, further clarifies issues 
w.r.t. the NSSA type 7 default LSAs.

   A Type-7 default LSA for the network 0.0.0.0/0 may be originated into
   the NSSA by any NSSA router.  The Type-7 default LSA originated by an
   NSSA border router must have the P-bit clear.  An NSSA ASBR that is
   not an NSSA border router may originate a Type-7 default LSA with the
   P-bit set.  A Type-7 default LSA may be installed by NSSA border
   routers if and only if its P-bit is set.  (See Appendix E.)

Thus if an ABR must originate a default lsa into an NSSA as well as into 
the full OSPF domain, it must do so via separately self-originated type 
7 and type 5 default LSAs. It cannot set the P-bit and use type 7 
translation to generate the type 5 default LSA. This is not the case for 
non-ABRs.

Note that the installation of a Type 7 default LSA on the NSSA border 
can harm the full OSPF domain's transit topology (See Appendix E). Thus 
RFC 3101 guards against this in Section 2.5 Step 3 paragraph 2:

          ... if the destination is a Type-7 default route (destination
          ID = DefaultDestination) and one of the following is true,
          then do nothing with this LSA and consider the next in the
          list:

            o  The calculating router is a border router and the LSA has
               its P-bit clear.

Hence both RFC 3101 and RFC 1587 do not install the Type 7 default LSAs 
of other NSSA ABRS. However RFC 1587 will install a non-ABR originated 
type 7 default LSA when its p-bit is clear. RFC 3101 does not. This 
correction was due to the discussion in Appendix E.

Pat

_______________________________________________
OSPF mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ospf

---

From: Acee Lindem <[email-masked]>
Date: Mon, 01 May 2006 21:17:24 -0400

Hi Pat,
See inline down at the summary.

Pat Murphy - (650)329-4044 wrote:

>of other NSSA ABRS. 
Agree.

>However RFC 1587 will install a non-ABR originated 
In retrospect, I don't think we should depend on a configured metric to 
avoid a routing
loop in the case where the NSSA ABR is installing a default from an NSSA 
internal
router (with the P-bit set). I think that NSSA ABRs should either be 
precluded
from installing an NSSA internal default (as they are when summaries
are suppressed) or have them not advertise a type 7 default when an 
internal NSSA
default is installed.

Thanks,
Acee