Re: regarding ospf las flushing .....

Don Goodspeed <Don.Goodspeed@ALCATEL.COM> Wed, 08 June 2005 23:58 UTC

Received: from ( []) by (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 ( by (LSMTP for Digital Unix v1.1b) with SMTP id <>; 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 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 8 Jun 2005 19:58:21 -0400
Received: from (localhost []) by (8.12.10/8.12.10) with ESMTP id j58Nw1mg013322; Wed, 8 Jun 2005 18:58:06 -0500 (CDT)
Received: from dgoodspeedpc (localhost []) by (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: <>
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 <>,
In-Reply-To: <>
Precedence: list
Content-Transfer-Encoding: 7bit


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.


-----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
Cc: OSPF@PEACH.EASE.LSOFT.COM; Padma Pillay-Esnault
Subject: Re: regarding ospf las flushing .....


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.


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