IETF Logo Mail Archive

Re: regarding ospf las flushing .....

Padma Pillay-Esnault <ppe@CISCO.COM> Wed, 08 June 2005 23:52 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 TAA04621 for <ospf-archive@LISTS.IETF.ORG>; Wed, 8 Jun 2005 19:52:23 -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 <1.01075EE6@cherry.ease.lsoft.com>; Wed, 8 Jun 2005 19:52:20 -0400
Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 74656065 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 8 Jun 2005 19:52:02 -0400
Received: from 171.71.176.71 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 8 Jun 2005 19:52:02 -0400
Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 08 Jun 2005 16:52:02 -0700
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j58NpdmE012432; Wed, 8 Jun 2005 16:51:56 -0700 (PDT)
Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 8 Jun 2005 16:51:57 -0700
Received: from [192.168.0.2] ([10.21.89.55]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 8 Jun 2005 16:51:56 -0700
User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913)
X-Accept-Language: en-us, en
MIME-Version: 1.0
References: <000701c56c04$eddbc840$bc04120a@china.huawei.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
X-OriginalArrivalTime: 08 Jun 2005 23:51:56.0925 (UTC) FILETIME=[0DE15AD0:01C56C85]
Message-ID: <42A7849C.4010406@cisco.com>
Date: Wed, 08 Jun 2005 16:51:56 -0700
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Padma Pillay-Esnault <ppe@CISCO.COM>
Subject: Re: regarding ospf las flushing .....
Comments: To: anupkumart@huawei.com
To: OSPF@PEACH.EASE.LSOFT.COM
In-Reply-To: <000701c56c04$eddbc840$bc04120a@china.huawei.com>
Precedence: list
Content-Transfer-Encoding: 8bit

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
>

v2.23.0 | Report a Bug | By Email