[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