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 > > >
- Re: [OSPF] OSPF Hybrid Broadcast and P2MP Interfa… Alvaro Retana (aretana)
- [OSPF] OSPF Hybrid Broadcast and P2MP Interface T… Jeffrey (Zhaohui) Zhang
- Re: [OSPF] OSPF Hybrid Broadcast and P2MP Interfa… pete
- Re: [OSPF] OSPF Hybrid Broadcast and P2MP Interfa… Jeffrey (Zhaohui) Zhang
- Re: [OSPF] OSPF Hybrid Broadcast and P2MP Interfa… Peter Psenak
- Re: [OSPF] OSPF Hybrid Broadcast and P2MP Interfa… Jeffrey (Zhaohui) Zhang
- Re: [OSPF] OSPF Hybrid Broadcast and P2MP Interfa… Peter Psenak
- Re: [OSPF] OSPF Hybrid Broadcast and P2MP Interfa… Jeffrey (Zhaohui) Zhang
- Re: [OSPF] OSPF Hybrid Broadcast and P2MP Interfa… Peter Psenak
- Re: [OSPF] OSPF Hybrid Broadcast and P2MP Interfa… Anton Smirnov
- Re: [OSPF] OSPF Hybrid Broadcast and P2MP Interfa… Jeffrey (Zhaohui) Zhang
- Re: [OSPF] OSPF Hybrid Broadcast and P2MP Interfa… Alvaro Retana (aretana)
- Re: [OSPF] OSPF Hybrid Broadcast and P2MP Interfa… Jeffrey (Zhaohui) Zhang
- Re: [OSPF] OSPF Hybrid Broadcast and P2MP Interfa… Alvaro Retana (aretana)
- Re: [OSPF] OSPF Hybrid Broadcast and P2MP Interfa… Jeffrey (Zhaohui) Zhang
- [OSPF] OSPF Hybrid Broadcast and P2MP Interface T… Acee Lindem
- Re: [OSPF] OSPF Hybrid Broadcast and P2MP Interfa… Jeffrey (Zhaohui) Zhang
- Re: [OSPF] OSPF Hybrid Broadcast and P2MP Interfa… Alvaro Retana (aretana)
- Re: [OSPF] OSPF Hybrid Broadcast and P2MP Interfa… Jeffrey (Zhaohui) Zhang
- Re: [OSPF] OSPF Hybrid Broadcast and P2MP Interfa… Anton Smirnov
- Re: [OSPF] OSPF Hybrid Broadcast and P2MP Interfa… Jeffrey (Zhaohui) Zhang
- Re: [OSPF] OSPF Hybrid Broadcast and P2MP Interfa… Nischal Sheth
- Re: [OSPF] OSPF Hybrid Broadcast and P2MP Interfa… Nischal Sheth
- Re: [OSPF] OSPF Hybrid Broadcast and P2MP Interfa… Acee Lindem
- Re: [OSPF] OSPF Hybrid Broadcast and P2MP Interfa… Jeffrey (Zhaohui) Zhang
- Re: [OSPF] OSPF Hybrid Broadcast and P2MP Interfa… Jeffrey (Zhaohui) Zhang
- Re: [OSPF] OSPF Hybrid Broadcast and P2MP Interfa… Henderson, Thomas R
- Re: [OSPF] OSPF Hybrid Broadcast and P2MP Interfa… Jeffrey (Zhaohui) Zhang
- Re: [OSPF] OSPF Hybrid Broadcast and P2MP Interfa… Richard Ogier
- Re: [OSPF] OSPF Hybrid Broadcast and P2MP Interfa… Jeffrey (Zhaohui) Zhang
- Re: [OSPF] OSPF Hybrid Broadcast and P2MP Interfa… Richard Ogier
- Re: [OSPF] OSPF Hybrid Broadcast and P2MP Interfa… Richard Ogier
- Re: [OSPF] OSPF Hybrid Broadcast and P2MP Interfa… Lili Wang
- Re: [OSPF] OSPF Hybrid Broadcast and P2MP Interfa… Richard Ogier
- Re: [OSPF] OSPF Hybrid Broadcast and P2MP Interfa… Lili Wang