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

Richard Ogier <ogier@earthlink.net> Tue, 07 June 2011 03:46 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 C6B671F0C4C for <ospf@ietfa.amsl.com>; Mon, 6 Jun 2011 20:46:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 Y3nHOYocpVEj for <ospf@ietfa.amsl.com>; Mon, 6 Jun 2011 20:46:41 -0700 (PDT)
Received: from elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) by ietfa.amsl.com (Postfix) with ESMTP id A324B1F0C44 for <ospf@ietf.org>; Mon, 6 Jun 2011 20:46:41 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=F0GRi9TsrNqCGKh0uunxPHpFkwB2kMUgWQFNz1AZr/An9J5bwGxCR0TIlxDY+FZy; h=Received:Message-ID:Date:From:User-Agent:X-Accept-Language:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP;
Received: from [66.81.246.143] by elasmtp-galgo.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from <ogier@earthlink.net>) id 1QTnFX-0006fu-28; Mon, 06 Jun 2011 23:46:40 -0400
Message-ID: <4DED9FDA.5060108@earthlink.net>
Date: Mon, 06 Jun 2011 20:49:46 -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: Lili Wang <liliw@juniper.net>
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> <4DD29C97.60705@earthlink.net> <A4C6A166C36F5F40A5767E6F66358FC0B3134BDC1B@EMBX01-WF.jnpr.net>
In-Reply-To: <A4C6A166C36F5F40A5767E6F66358FC0B3134BDC1B@EMBX01-WF.jnpr.net>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-ELNK-Trace: a073897a9455599e74bf435c0eb9d4787b1ed7a12fe76a0a612c968caef20566cce0df2f6ec2329b350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 66.81.246.143
Cc: "Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net>, "ospf@ietf.org" <ospf@ietf.org>
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, 07 Jun 2011 03:46:42 -0000

Hi Lili,

Your proposed change assumes that the non-DR router knows when the
DR has finished sending LS request packets.  I am not sure this can
be assumed, since a router doesn't indicate when it is finished
sending LS request packets (and might not send any).
I think the only indication is when the DR declares the adjacency
to be Full when the LoadingDone event occurs (and adds the neighbor
to its LSA).

Even if the non-DR router determines via Database Description
packets that the DR has out-of-date LSAs, the DR could receive
those LSAs from another router.

It seems easier to just require that the DR's LSA include a link to
the router itself (router i in my example), or to the other non-DR
router j (which is what I used in my draft), before router i includes
a link to j in its router-LSA.  I prefer the latter because then
router i advertises a link to j only if router i is Full with the DR
and the DR is Full with router j.  Thus, by transitivity router i is
equivalent to being Full with router j (i.e., router i is as
up-to-date as router j).

Richard


Lili Wang wrote:

>Hi Richard,
>
>   Sorry for the late reply!
>
>Yes, this is a problem with the current spec.  We incorrectly convinced ourselves that such a check is not required.
>
>Here's the proposed change.
>
>We make sure the non-DR router have a synchronized database with the DR before advertising the Type 1 link to other non-DR router.
>We declare the DR as a fully synchronized adjacency after having all the DR's LSA request satisfied (i.e., Our LSA update for the LSA requests are acknowledged by the DR.) in addition to having a full adjacency with the DR. 
>
>The rule then will look like the following:  
>
>o  If a router is not the DR and has a fully synchronized adjacency to the DR, it MUST add a Type 1 link corresponding to each neighbor that is in
>state 2-Way or higher.
>
>
>Tanks,
>
>Lili
>-----Original Message-----
>From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf Of Richard Ogier
>Sent: Tuesday, May 17, 2011 12:05 PM
>To: ospf@ietf.org
>Subject: Re: [OSPF] OSPF Hybrid Broadcast and P2MP Interface Type
>
>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
>_______________________________________________
>OSPF mailing list
>OSPF@ietf.org
>https://www.ietf.org/mailman/listinfo/ospf
>
>  
>