IETF Logo Mail Archive

Re: regarding ospf las flushing .....

Dave Katz <dkatz@JUNIPER.NET> Thu, 09 June 2005 05:15 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 BAA00916 for <ospf-archive@LISTS.IETF.ORG>; Thu, 9 Jun 2005 01:15:00 -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 <5.010763F0@cherry.ease.lsoft.com>; Thu, 9 Jun 2005 1:14:59 -0400
Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 74673276 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 9 Jun 2005 01:14:57 -0400
Received: from 207.17.137.57 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Thu, 9 Jun 2005 01:14:57 -0400
Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id j595Eu989428 for <OSPF@PEACH.EASE.LSOFT.COM>; Wed, 8 Jun 2005 22:14:56 -0700 (PDT) (envelope-from dkatz@juniper.net)
Received: from [172.16.12.13] (nimbus-sc.juniper.net [172.16.12.13]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id j595Epe83607 for <OSPF@PEACH.EASE.LSOFT.COM>; Wed, 8 Jun 2005 22:14:51 -0700 (PDT) (envelope-from dkatz@juniper.net)
Mime-Version: 1.0 (Apple Message framework v622)
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
X-Mailer: Apple Mail (2.622)
Message-ID: <df9cea53777c9106701f508ee574665a@juniper.net>
Date: Wed, 08 Jun 2005 22:14:48 -0700
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Dave Katz <dkatz@JUNIPER.NET>
Subject: Re: regarding ospf las flushing .....
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

On Jun 8, 2005, at 5:23 PM, Quaizar Vohra wrote:

> But that major implementation had to revert to sending the entire
> LSA (header + body) because another major implementation did not
> like it :).
>
> Have gone thru enought pain on this subject and would prefer not
> having to do yet another revision. As far as efficiency and memory
> is concerned, I wouldn't worry too much about it for this particular
> case.

I guess this explains how it was resolved.  Obviously my resistance was 
futile.  ;-)

--Dave

v2.26.15 | Report a Bug | By Email | System Status