Re: [OSPF] OSPF Hybrid Broadcast and P2MP Interface Type

Richard Ogier <ogier@earthlink.net> Tue, 17 May 2011 16:02 UTC

Return-Path: <ogier@earthlink.net>
X-Original-To: ospf@ietfa.amsl.com
Delivered-To: ospf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC2B3E0837 for <ospf@ietfa.amsl.com>; Tue, 17 May 2011 09:02:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.83
X-Spam-Level:
X-Spam-Status: No, score=-1.83 tagged_above=-999 required=5 tests=[AWL=0.769, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A97e1BhV4SWV for <ospf@ietfa.amsl.com>; Tue, 17 May 2011 09:02:27 -0700 (PDT)
Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by ietfa.amsl.com (Postfix) with ESMTP id 1DE14E074C for <ospf@ietf.org>; Tue, 17 May 2011 09:02:27 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=r9sa5qyxNUno6si+0c5tFlf6D5bU2gihonAdePeNvNsva0I8M3X2zv2ns1Hb+MYI; h=Received:Message-ID:Date:From:User-Agent:X-Accept-Language:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP;
Received: from [66.81.255.243] by elasmtp-banded.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from <ogier@earthlink.net>) id 1QMMj3-0004sb-Ko for ospf@ietf.org; Tue, 17 May 2011 12:02:26 -0400
Message-ID: <4DD29C97.60705@earthlink.net>
Date: Tue, 17 May 2011 09:04:39 -0700
From: Richard Ogier <ogier@earthlink.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "ospf@ietf.org" <ospf@ietf.org>
References: <FC090A1B-0A33-4CC8-B7B8-34076F16EE4D@ericsson.com> <1D23749D4168CC4D8B8652397B5F6432041769BB@XMB-RCD-206.cisco.com> <13205C286662DE4387D9AF3AC30EF456B03C2377D6@EMBX01-WF.jnpr.net> <1D23749D4168CC4D8B8652397B5F643204176A6C@XMB-RCD-206.cisco.com> <4D5474C5.1050107@juniper.net> <4D9F590A.5050008@earthlink.net> <13205C286662DE4387D9AF3AC30EF456D340CA09EE@EMBX01-WF.jnpr.net>
In-Reply-To: <13205C286662DE4387D9AF3AC30EF456D340CA09EE@EMBX01-WF.jnpr.net>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-ELNK-Trace: a073897a9455599e74bf435c0eb9d478504bcfd8a9496c945583a1e5b3683aee97ebbe97a30ffb20350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 66.81.255.243
Subject: Re: [OSPF] OSPF Hybrid Broadcast and P2MP Interface Type
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ospf>, <mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ospf>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ospf>, <mailto:ospf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 17 May 2011 16:02:27 -0000

Section 3.6 of draft-nsheth-ospf-hybrid-bcast-and-p2mp-01
has the following rule:

o  If a router is not the DR and has a full adjacency to the DR, it
   MUST add a Type 1 link corresponding to each neighbor that is in
   state 2-Way or higher.

Suppose i and j are non-DR routers.  It seems to me that i should
also require that the DR's router-LSA include a link to j before
i adds a Type 1 link corresponding to j, in order to ensure that
i and j are fully synchronized before either uses the other as
a next hop.  Is there a reason why this condition was omitted?

To explain further, the SPT calculation (Section 16.1 of RFC 2328)
requires that router j advertise a link back to router i before i
can use j as a next hop (and vice versa). Thus, routers i and j can use
each other as a next hop if they both advertise a link to each other.

Therefore, the above rule from draft-nsheth only ensures that
routers i and j are fully adjacent with the DR before either can
use the other as a next hop.  As a result, the DR might not be fully
adjacent with router i or j, and thus i and j may not be fully
synchronized.  Note that full adjacency with a neighbor does not
imply that the link state databases are synchronized (see footnote 23
in RFC 2328).  It only means that the router is at least as
up-to-date as the neighbor, since it only means that all Link
State Requests have been satisfied.

Please correct me if I am mistaken.

Richard