Re: RFC ietf Drafe Contradicts in NSSA

Samvid Shah <samvid@FUTSOFT.COM> Thu, 08 August 2002 20:59 UTC

References: <20020808184844.74335109EF3@xmxpita.excite.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-ID: <019301c23f1e$cd595df0$eb2a7a42@futsoft.com>
Date: Thu, 08 Aug 2002 14:01:41 -0700
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: Samvid Shah <samvid@FUTSOFT.COM>
Subject: Re: RFC ietf Drafe Contradicts in NSSA
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Hi Don and Amit,
          my 2 cents...
          Thanks.
                                     -Samvid

----- Original Message -----
From: Don Goodspeed <dgoodspe@EXCITE.COM>
To: <OSPF@discuss.microsoft.com>
Sent: Thursday, August 08, 2002 11:48 AM
Subject: Re: RFC ietf Drafe Contradicts in NSSA


> Amit,
>
> The nssa-update-11 draft is correct.  Since it's an update
> to the RFC, you should always consider it's operation to be
> correct.  Just because we cannot state compliance to IETF
> drafts does not mean we cannot implement them.
>
> As for the actual reason "why" the change was made, I've seen
> situations where an external LSA was chosen by a non-translator
> ABR.  The translator ABR goes down, and the non-translator did
> not start translating because it had chosen the route from
> the Type-5 external (only NSSA reachable routes are translated).

Samvid>  If we consider NSSA with 2 ABRs both connected to area 0,  probably
we can appreciate  this fact (giving higher priority to type 7 LSA with P
bit set for installing it as AS external route).
Since, type 7 LSA represents intra-area LSA and P bit set represents the LSA
needs to be translated to type 5 ,
giving higher priority to type 7 LSA with P bit  increases chances that
routing will be optimal for AS external routes in this case.

>
> Cheers,
> -don
>
>  --- On Thu 08/08, Amit Srivastava  wrote:
> From: Amit Srivastava [mailto: ospfisfun@YAHOO.COM]
> To: OSPF@DISCUSS.MICROSOFT.COM
> Date: Thu, 8 Aug 2002 05:03:38 -0700
> Subject: RFC ietf Drafe Contradicts in NSSA
>
> > Hi All,
> >   I have found a contradition in the NSSA RFC 1587 and
> > ietf dratf number 11 for nssa. The RFC specifies in
> > section 3.5 2nd last para:-
> >
> > When a type-5 LSA and a type-7 LSA are found to have
> > the same type and an equal distance, the following
> > priorities apply (listed from highest to lowest) for
> > breaking the tie.
> > 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.
> >
> > While the Draft specifies in section 3.5 2nd Last para
> > that:-
> >
> >           (e) If the current LSA is functionally the
> > same as an installed LSA (i.e., same destination, cost
> > and non-zero forwarding address) then apply the
> > following priorities in deciding which LSA is
> > preferred:
> >               1. A Type-7 LSA with the P-bit set.
> >
> >               2. A Type-5 LSA.
> >
> >               3. The LSA with the higher router ID.
> >
> > Now my doubt is which one to Follow???
> > Please Help
> > Regards
> > Amit
> >
> >
> >
> >
> > __________________________________________________
> > Do You Yahoo!?
> > HotJobs - Search Thousands of New Jobs
> > http://www.hotjobs.com
> >
>
> ------------------------------------------------
> Join Excite! - http://www.excite.com
> The most personalized portal on the Web!
>

Re: RFC ietf Drafe Contradicts in NSSA Don Goodspeed
Re: RFC ietf Drafe Contradicts in NSSA Samvid Shah
Re: RFC ietf Drafe Contradicts in NSSA Pat Murphy - (650)329-4044
LSAs with Reserved flooding scope Subhash