Re: RFC ietf Drafe Contradicts in NSSA
Don Goodspeed <dgoodspe@EXCITE.COM> Thu, 08 August 2002 18:47 UTC
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22886 for <ospf-archive@LISTS.IETF.ORG>; Thu, 8 Aug 2002 14:47:36 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.006C6A84@cherry.ease.lsoft.com>; Thu, 8 Aug 2002 14:48:48 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 82173 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 8 Aug 2002 14:48:44 -0400
Received: from 63.236.75.8 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 8 Aug 2002 14:48:44 -0400
Received: by xmxpita.excite.com (Postfix, from userid 110) id 74335109EF3; Thu, 8 Aug 2002 14:48:44 -0400 (EDT)
Received: from [63.104.212.252] by xprdmailfe1.nwk.excite.com via HTTP; Thu, 08 Aug 2002 14:48:44 EST
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: ID = b4f718530cf8af0dd8df25e0425ffee0
MIME-Version: 1.0
X-Sender: dgoodspe@excite.com
X-Mailer: PHP
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <20020808184844.74335109EF3@xmxpita.excite.com>
Date: Thu, 08 Aug 2002 14:48:44 -0400
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: Don Goodspeed <dgoodspe@EXCITE.COM>
Subject: Re: RFC ietf Drafe Contradicts in NSSA
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit
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). 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