Re: regarding ospf las flushing .....

Dave Katz <dkatz@JUNIPER.NET> Thu, 09 June 2005 19:02 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 PAA04483 for <ospf-archive@LISTS.IETF.ORG>; Thu, 9 Jun 2005 15:02:25 -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 <19.01076D54@cherry.ease.lsoft.com>; Thu, 9 Jun 2005 15:02:24 -0400
Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 74774580 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 9 Jun 2005 15:02:23 -0400
Received: from 207.17.137.64 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Thu, 9 Jun 2005 15:02:23 -0400
Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id j59J2MBm029423 for <OSPF@PEACH.EASE.LSOFT.COM>; Thu, 9 Jun 2005 12:02:22 -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 j59J2Me24244 for <OSPF@PEACH.EASE.LSOFT.COM>; Thu, 9 Jun 2005 12:02:22 -0700 (PDT) (envelope-from dkatz@juniper.net)
Mime-Version: 1.0 (Apple Message framework v622)
References: <000701c56c04$eddbc840$bc04120a@china.huawei.com> <000701c56c04$eddbc840$bc04120a@china.huawei.com> <4.3.2.7.2.20050609105725.02826960@jaws.cisco.com>
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.622)
Message-ID: <acbfd4f3a0be5858cdfce14bd159a19a@juniper.net>
Date: Thu, 09 Jun 2005 12:02:18 -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
In-Reply-To: <4.3.2.7.2.20050609105725.02826960@jaws.cisco.com>
Precedence: list
Content-Transfer-Encoding: 7bit

On Jun 9, 2005, at 3:01 AM, mike shand wrote:

> Of course a certain other Link State Protocol has always specified 
> that this is what you should do i.e. send only the header, (not that 
> all implementations follow the spec in this regard:-)

Yes, and a certain implementor who had previously implemented the 
certain Link State Protocol took this to heart when implementing the 
uncertain Link State Protocol.  ;-)

--Dave