Re: ospfv3 - Route Entry
Acee Lindem <acee@CISCO.COM> Mon, 27 June 2005 21:54 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 RAA26888 for <ospf-archive@LISTS.IETF.ORG>; Mon, 27 Jun 2005 17:54:15 -0400 (EDT)
Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.01090600@cherry.ease.lsoft.com>; Mon, 27 Jun 2005 17:54:14 -0400
Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 77081516 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 27 Jun 2005 17:53:58 -0400
Received: from 171.68.10.87 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Mon, 27 Jun 2005 17:53:58 -0400
Received: from rtp-core-2.cisco.com (64.102.124.13) by sj-iport-5.cisco.com with ESMTP; 27 Jun 2005 14:54:00 -0700
X-IronPort-AV: i="3.93,235,1115017200"; d="scan'208"; a="194657007:sNHT31479384"
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j5RLqOaE020884 for <OSPF@PEACH.EASE.LSOFT.COM>; Mon, 27 Jun 2005 17:53:59 -0400 (EDT)
Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 27 Jun 2005 17:53:44 -0400
Received: from [10.82.216.104] ([10.82.216.104]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 27 Jun 2005 17:53:44 -0400
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
References: <20050627070617.30219.qmail@webmail36.rediffmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 27 Jun 2005 21:53:44.0338 (UTC) FILETIME=[B037B720:01C57B62]
Message-ID: <42C07567.8000901@cisco.com>
Date: Mon, 27 Jun 2005 17:53:43 -0400
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Acee Lindem <acee@CISCO.COM>
Subject: Re: ospfv3 - Route Entry
To: OSPF@PEACH.EASE.LSOFT.COM
In-Reply-To: <20050627070617.30219.qmail@webmail36.rediffmail.com>
Precedence: list
Content-Transfer-Encoding: 7bit
Vivek Dubey wrote: >Hi Acee, > > >>Other implementations are possible. As you know, the OSPFv3 intra->area SPF calculation is done in 2 phases. First a Shortest Path Tree >>(SPT) is built from the router and network LSAs. In the second phase, >the intra-area-prefix-LSAs are examined and routes are added to the >routing table for reachable prefixes based on whether the reference >LSA is reachable (among other checks). So, one either needs to lookup >the route to the corresponding node in the SPT or the reference LSA. >RFC 2740 chose the former and I think it is more straight forward. >> >> > >Following from above: > >draft-ietf-ospf-ospfv3-update-04 >3.5.3 Installing LSAs in the database >---------------------------------------- >Router-LSAs, Network-LSAs, Intra-Area-Prefix-LSAs, and Link-LSAs > The entire routing table is recalculated, starting with the > shortest path calculation for each area (see Section 3.8) > ><vivek> Change in contents of "Intra-Area-Prefix-LSAs" does not require "entire routing table recalculation". Route entry for referenced router/transit link should be checked and best route to prefixes described in "Intra-Area-Prefix-LSAs" should be calculated > > Hi Vivek, As specified in section 16.1 of RFC 2328, optimizations are possible as long as the same SPF (Shortest Path Tree) is produced. It would be possible to specify an incremental calculation for intra-area-prefix-LSAs but since it hasn't been specified heretofore and implementations are free to implement one without specification, I'm not going to add it in this RFC 2740 re-spin. Note that there are a number of issues that would need to be covered (alternate routes, forwarding addresses, changes in VL endpoints, etc). Thanks, Acee >Thanks >Vivek > > > > > >On Fri, 24 Jun 2005 Acee Lindem wrote : > > >>Vivek Dubey wrote: >> >> >> >>>Hi, >>> >>> >>> >>Hi Vivek, >> >> >> >>>RFC 2328: Section 11 >>>-------------------- >>>Destination Type: Router entries are kept for area border routers and AS boundary routers >>> >>>draft-ietf-ospf-ospfv3-update-04 >>>-------------------------------- >>>Section 3.3 The Routing table Structure: >>>An entry for each router in the area is kept >>> >>><vivek> Calculation of reachability to stub networks and prefixes described in intra-area-prefix LSA is I guess similar. What's the need to maintain an entry for each router in the area ? >>> >>> >>> >>Other implementations are possible. As you know, the OSPFv3 intra-area SPF >>calculation is done in 2 phases. First a Shortest Path Tree (SPT) is built from the >>router and network LSAs. In the second phase, the intra-area-prefix-LSAs are >>examined and routes are added to the routing table for reachable prefixes based >>on whether the reference LSA is reachable (among other checks). So, one either >>needs to lookup the route to the corresponding node in the SPT or the reference >>LSA. RFC 2740 chose the former and I think it is more straight forward. >> >>Thanks, >>Acee >> >> >> >>>Thanks >>>Vivek >>> >>> >>> >>> >>> >>> > > >
- ospfv3 - Route Entry Vivek Dubey
- Re: ospfv3 - Route Entry Acee Lindem
- Re: ospfv3 - Route Entry Vivek Dubey
- Re: ospfv3 - Route Entry Acee Lindem