Re: [OSPF] Re: Comments on draft-berger-ospf-rfc2370bis-00.txt

Acee Lindem <> Tue, 28 November 2006 21:58 UTC

Received: from [] ( by with esmtp (Exim 4.43) id 1GpAyW-00057E-DY; Tue, 28 Nov 2006 16:58:48 -0500
Received: from [] ( by with esmtp (Exim 4.43) id 1GpAyV-000576-1K for; Tue, 28 Nov 2006 16:58:47 -0500
Received: from ([]) by with esmtp (Exim 4.43) id 1GpAyT-0000Jl-MP for; Tue, 28 Nov 2006 16:58:47 -0500
Received: from ([]) by with ESMTP; 28 Nov 2006 13:58:44 -0800
Received: from ( []) by (8.12.11/8.12.11) with ESMTP id kASLwi5S004362; Tue, 28 Nov 2006 16:58:44 -0500
Received: from ( []) by (8.12.10/8.12.6) with ESMTP id kASLwhDM016665; Tue, 28 Nov 2006 16:58:43 -0500 (EST)
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Nov 2006 16:58:43 -0500
Received: from [] ([]) by with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Nov 2006 16:58:43 -0500
Message-ID: <>
Date: Tue, 28 Nov 2006 16:58:42 -0500
From: Acee Lindem <>
User-Agent: Thunderbird (Windows/20061025)
MIME-Version: 1.0
To: Igor Bryskin <>
Subject: Re: [OSPF] Re: Comments on draft-berger-ospf-rfc2370bis-00.txt
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 28 Nov 2006 21:58:43.0514 (UTC) FILETIME=[5EEE99A0:01C71338]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2596; t=1164751124; x=1165615124; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;;; z=From:=20Acee=20Lindem=20<> |Subject:=20Re=3A=20[OSPF]=20Re=3A=20Comments=20on=20draft-berger-ospf-rf c2370bis-00.txt |Sender:=20 |To:=20Igor=20Bryskin=20<>; bh=Ox5fFqTcmX5p5J4AHxsxpIDHLxyEtuzr/I0qkc/H0+A=; b=RNK79gEaZ6l0FL/N87eU1OBPQNJEkUfYAdF3tG8M/M9hDer0AOAB/pV6/lNdEo7vUeBizf0h 9rCr9xr3MeD4wt2Ac6kX0OOh7kqGjV98Aw/bkAypPpn/bBJXGqFQQmsl;
Authentication-Results: rtp-dkim-2;; dkim=pass (s ig from verified; );
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab
Cc: OSPF List <>
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>

Hi Igor,
Igor Bryskin wrote:
> Acee,
>>> I also think we should put the question as to whether the checking
>>> should be madatory or relaxed a bit to allow an application to check
>>> less frequently if the opaque data is stale.
>> What benefit would this have?
> This would allow applications that don't require the opaque data to
> strictly track the SPF to discontinue using the information less
> frequently
> than the SPF. This would be useful if OSPF and the application using the
> opaque data were not tightly coupled. Here is what I put in the OSPFv3
> update draft:
> 3.4.4.  Future LSA Validation
>    It is expected that new LSAs will be defined that will not be
>    processed during the Shortest Path First (SPF) calculation as
>    described in Section 3.8.  For example, OSPFv3 LSAs corresponding to
>    information advertised in OSPFv2 using opaque LSAs [OPAQUE].  In
>    general, the new information advertised in future LSAs should not be
>    used unless the OSPFv3 router originating the LSA is reachable.
>    However, depending on the application and the data advertised, this
>    reachability validation MAY be done less frequently than every SPF
>    calculation.
>    To facilitate inter-area reachability validation, any OSPFv3 router
>    orginating AS scoped LSAs is considered an AS Boundary Router (ASBR).
> I believe that the usage of opaque LSAa and one of basic LSAs (required
> for SPF calculations) and, therefore, their validation are unrelated.
> The important thing, as you put it, is to make sure that the stale LSAs
> are not used. I mean, there is no need to provide timing recommendations
> on when and how frequent the validation of opaque LSAs should be
> performed. For example, one way to implement such validation is to make
> it event (rather, than time) driven. Specifically, the advertisements
> carried in type-11 LSAs could be marked as invalid every time when the
> corresponding type-4 LSA is removed from the LSDB.
I think we are agreeing in principle. Note that while the absence of a
Router-LSA or ASBR-Summary-LSA indicates the originator is not 
reachable, the
presence doesn't guarantee reachability. The text above articulates the 
fact that an
application using OSPFv3 advertised data MAY NOT be strictly tied to the
the SPF calculation and may check LSA "freshness" at less frequent 
However, the SPF should remain the definite source for determining 
whether an
LSA's originator is reachable.

> Cheers,
> Igor

OSPF mailing list