[OSPF] Comments / questions on RFC3623 and Update GR part 1 : BMA env
Erblichs <erblichs@earthlink.net> Tue, 14 November 2006 00:07 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjlpU-0006E2-0L; Mon, 13 Nov 2006 19:07:08 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjlpS-0006Dx-G4 for ospf@ietf.org; Mon, 13 Nov 2006 19:07:06 -0500
Received: from elasmtp-banded.atl.sa.earthlink.net ([209.86.89.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjlpR-00089U-4W for ospf@ietf.org; Mon, 13 Nov 2006 19:07:06 -0500
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=XBoRvuFhq6JLsHiQGI8GW0k0uskbk1pww8vboiinKRD5NwqdOOf9jpySDSeNJn/i; h=Received:Message-ID:Date:From:X-Sender:X-Mailer:X-Accept-Language:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP;
Received: from [68.164.159.38] (helo=earthlink.net) by elasmtp-banded.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1GjlpL-0007Og-HR for ospf@ietf.org; Mon, 13 Nov 2006 19:06:59 -0500
Message-ID: <45590834.B988E949@earthlink.net>
Date: Mon, 13 Nov 2006 16:05:08 -0800
From: Erblichs <erblichs@earthlink.net>
X-Sender: "Erblichs" <erblichs@earthlink.net@smtpauth.earthlink.net> (Unverified)
X-Mailer: Mozilla 4.72 [en]C-gatewaynet (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: ospf@ietf.org
Content-Type: text/plain; charset="iso-8859-2"
Content-Transfer-Encoding: 7bit
X-ELNK-Trace: 074f60c55517ea841aa676d7e74259b7b3291a7d08dfec79a519069e610f6de568fb91be4965c3d5350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 68.164.159.38
X-Spam-Score: 0.1 (/)
X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81
Subject: [OSPF] Comments / questions on RFC3623 and Update GR part 1 : BMA env
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
Group, First, I have a few questions to the base and the update. These comments / questions pertain ONLY to BMA envs but are also relevelent to other envs. FYI) IMO, helpers are defined by two major requirements a) the ability to recieve a grace-LSA before a hello "new hello" and not restart the adj b) the ability of a helper "Y" to (re)send a router-LSA, etc upon router "X" exiting graceful restart that are in its retransmit-list. If this "helper" split functionality is supported, then only a limited number of routers within a area need to be in Full-helper mode. Within BMA envs a DR-other above helper "b" functionality is not really necessary for retransmit. We use the DR/BDR for retransmit support. IFFFFFFF, a GR router is the DR, who is in it grace-period, and a DR-other stops sending hellos, if their are no alternate paths thru another router for any forwarding data. Then what benefit is it to prematurely end helper mode? Basicly, most algs can determine ahead of time whether the exiting router has contributed a primary link/path. If it isn't then it has no consequence. Yes, data pkts that have a intermediate dest will be forwarded 1 or two extra hops, before they are dropped. (Update: 2.0 Action on route calculation) If a topology change occurs and the GR restarting router is identified as the next hop. By definition it is in non-stop forwarding mode and should be able to forward packets. If this is identified as a topology change and the ONLY route is thru this GR router, shouldn't packets be forwarded thru it anyway? Not doing so blackholes those routes, IMO. Thus, 1) Helpers should be able to be able to support a, without b If this is the case, router "X", if it is a DR should allow all the DR-others to support a, while only the BDR need be a "Full-Helper". 2) If router "X" is a DR-other only one of a "DR or BDR" need to be a Full-helper. All LSAs can be placed on the retransmit list of the for router "X" by the DR or BDR. 3) Topology change. A LSA aging out of the LSDB, will not necessarily remove a element in the forwarding table? If this can be detected, should it still force the exit of a helper wrt graceful restart? 4) If router "X" is a DR and has entered graceful restart with no BDR present, should the DR-other routers allow the LSAs to become not refreshed and aged out because the grace period has not expired. How can "one" or more "HELPERS" force a new DR election? 5) Even with a 30 min max for the grace period, some routers may only retransmit once every 45 mins or so. How can we guarantee that those retransmited-LSAs are not aged-out if router "X" is the DR and is down for a longer time? Shouldn't recieving the first grace-LSAs from a restarting router initiate a re-send of the LSAs? Mitchell Erblich _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf