Re: regarding ospf las flushing .....
Don Goodspeed <Don.Goodspeed@ALCATEL.COM> Wed, 08 June 2005 23:58 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 TAA04990 for <ospf-archive@LISTS.IETF.ORG>; Wed, 8 Jun 2005 19:58:34 -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 <20.01075DD2@cherry.ease.lsoft.com>; Wed, 8 Jun 2005 19:58:34 -0400
Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 74656351 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 8 Jun 2005 19:58:21 -0400
Received: from 143.209.238.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 8 Jun 2005 19:58:21 -0400
Received: from mvrelay.mv.usa.alcatel.com (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id j58Nw1mg013322; Wed, 8 Jun 2005 18:58:06 -0500 (CDT)
Received: from dgoodspeedpc (localhost [127.0.0.1]) by mvrelay.mv.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id j58NvvYm018306; Wed, 8 Jun 2005 16:57:58 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478
Thread-index: AcVshRR7AkVdwxTjTh+qv6vGjN5dyQAAHxaA
Message-ID: <200506082357.j58NvvYm018306@mvrelay.mv.usa.alcatel.com>
Date: Wed, 08 Jun 2005 16:58:08 -0700
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Don Goodspeed <Don.Goodspeed@ALCATEL.COM>
Organization: Alcatel
Subject: Re: regarding ospf las flushing .....
Comments: To: Padma Pillay-Esnault <ppe@cisco.com>, anupkumart@huawei.com
To: OSPF@PEACH.EASE.LSOFT.COM
In-Reply-To: <42A7849C.4010406@cisco.com>
Precedence: list
Content-Transfer-Encoding: 7bit
Padma, How does one address the issues of summary and external LSAs where the LSID "may" change depending upon Appendix E of RFC2328. In those cases, isn't including the subnet mask needed? Otherwise, an incorrect LSA could be flushed. -don -----Original Message----- From: owner-ospf@PEACH.EASE.LSOFT.COM [mailto:owner-ospf@PEACH.EASE.LSOFT.COM] On Behalf Of Padma Pillay-Esnault Sent: Wednesday, June 08, 2005 4:52 PM To: anupkumart@huawei.com Cc: OSPF@PEACH.EASE.LSOFT.COM; Padma Pillay-Esnault Subject: Re: regarding ospf las flushing ..... Anup This was already done in a major implementation. I think it was a good idea. You have to be careful though as this might break some implementation who access the body of the lsa on flushing ( though I don't see why they would do that). I'm for it and can collaborate. This can initiate a discussion on the list. Padma anup wrote: > Hello Padma, > > As per RFC 2328, we send the lsa (header + body) to the peer though > the lsa is maxaged. > > Considering that the peer would not examine the lsa body if the lsa is > maxaged, *if we could send only the maxaged lsa's header*, it would > reduce a lot of traffic as well as the protocol memory consumption > during flushing. > > If you agree with this idea, I would like to prepare a small draft on > this. > > Regards, > > Anup >
- Re: regarding ospf las flushing ..... Padma Pillay-Esnault
- Re: regarding ospf las flushing ..... Don Goodspeed
- Re: regarding ospf las flushing ..... Quaizar Vohra
- Re: regarding ospf las flushing ..... Dave Katz
- Re: regarding ospf las flushing ..... Dave Katz
- Re: regarding ospf las flushing ..... mike shand
- Re: regarding ospf las flushing ..... Acee Lindem
- Re: regarding ospf las flushing ..... Dave Katz