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

Acee Lindem <acee@cisco.com> Tue, 14 November 2006 00:03 UTC

Received: from [] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gjlm1-0003P1-Rp; Mon, 13 Nov 2006 19:03:33 -0500
Received: from [] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gjlm0-0003Oo-Fn for ospf@ietf.org; Mon, 13 Nov 2006 19:03:32 -0500
Received: from sj-iport-5.cisco.com ([]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gjllz-0007eI-3f for ospf@ietf.org; Mon, 13 Nov 2006 19:03:32 -0500
Received: from rtp-dkim-2.cisco.com ([]) by sj-iport-5.cisco.com with ESMTP; 13 Nov 2006 16:03:29 -0800
Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com []) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id kAE03TCh020514; Mon, 13 Nov 2006 19:03:29 -0500
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com []) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kAE03TDM010393; Mon, 13 Nov 2006 19:03:29 -0500 (EST)
Received: from xfe-rtp-201.amer.cisco.com ([]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Nov 2006 19:03:29 -0500
Received: from [] ([]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Nov 2006 19:03:29 -0500
Message-ID: <455907D0.5010706@cisco.com>
Date: Mon, 13 Nov 2006 19:03:28 -0500
From: Acee Lindem <acee@cisco.com>
User-Agent: Thunderbird (Windows/20061025)
MIME-Version: 1.0
To: OSPF List <ospf@ietf.org>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 14 Nov 2006 00:03:29.0308 (UTC) FILETIME=[509DDDC0:01C70780]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2912; t=1163462609; x=1164326609; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=acee@cisco.com; z=From:=20Acee=20Lindem=20<acee@cisco.com> |Subject:=20Comments=20on=20draft-berger-ospf-rfc2370bis-00.txt |Sender:=20 |To:=20OSPF=20List=20<ospf@ietf.org>; bh=46iV3mtq4HGZvl0Mz0PoOUCqurygaggFyiz4YfFuBTw=; b=yLvQKsch/W+hCmD40cdTveNDXEa3wGHPCWMdyptHwkDUYiy9Nzhw79nM53qfyqzTVUv5ybjh okEnsQCAsEoZ9aSfEo3d733KgCqmeoBr7eyIJp+F661clBapqWNZl1pB;
Authentication-Results: rtp-dkim-2; header.From=acee@cisco.com; dkim=pass (s ig from cisco.com/rtpdkim2001 verified; );
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1
Subject: [OSPF] Comments on draft-berger-ospf-rfc2370bis-00.txt
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ospf>, <mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ospf>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ospf>, <mailto:ospf-request@ietf.org?subject=subscribe>
Errors-To: ospf-bounces@ietf.org

Hi Lou,

My main comment is on section 5 (6 is your draft). The draft adds
mandatory reachability checking for AS scoped opaque LSAs.
If we add mandatory reachability checking, it should be for all
opaque types rather reading like the constraint is unique to AS scoped
opaque LSAs (type 11s). 

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.

Detailed comments:

Section 2, third paragraph - "aligned" rather than "qaligned".

Section 3, "Section 7" rather than "Section 7."

Section 3.1 - Type 9  LSA - "keep" rather than "keepk". I believe we
                    should discard a link-local LSA received from a 
neighbor not
                    on the interface (text similiar to type 11).

Section 3.1, Since the area ID is not in the LSA header, the bullet on
                   area flooding is confusing. It should say something 
to the
                   effect of only flooding type 10 LSAs out interfaces 
in the
                   LSA's associated area. I don't care if it said this 
in RFC 2370
                   and everyone knew what it implied.
Section 3.1, 2nd to last paragraph: "An opaque" rather than "a opaque".

Swap sections 5 and 6 since "inter-area" is more the "meat" of the draft.
In fact, if the opaque MIB objects are all covered in the new MIB, we can
probably remove the "management section".

Section 6 (will be 5)

5. Opaque LSA Validation

Opaque LSAs are not processed during the SPF calculation as described in
section 16 of [OSPF]. However, they are subject to the same reachability
constraints as the base LSA types. This implies that originating router
MUST be reachable for the advertised application specific data to be
considered valid.

5.1 Inter-Area Considerations


Section 5.1

   Type-9 opaque LSAs and type-10 opaque LSAs do not have this problem
   as a receiving router can detect an a loss of reachability through 
the intra-area
   SPF calculation.

Section 5.1

   To enable OSPF routers in remote areas to check availability of the
   originator of link-state type 11 opaque LSAs, the orignators of
    type-11 opaque LSAs are considered Autonomous System Border
    Routers (ASBRs) and will advertise themselves as such.
Section 5.1 - Remove "It is important to note that this solution MUST 
NOT ..."
This is redundant.

Remove numbered items (1) and (2), these actions ARE NOT new to
opaque LSAs. Make (3) a separate paragraph rather than numbered

Section 10.1 - Correct NSSA reference to RFC 3101.

Section 12.1 - Add D and MT bits with informative references to [RFC 4576]
and the [OSPF-MT] drafts. "All eight bit ..." rather than "Six bits..".

General - Replace "stub area" with "stub or NSSA areas".


OSPF mailing list