draft-nguyen-ospf-restart-05.txt : bit

Erblichs <erblichs@EARTHLINK.NET> Fri, 25 February 2005 04:29 UTC

MIME-Version: 1.0
References: <LISTSERV%200502241804429790.CC56@PEACH.EASE.LSOFT.COM>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <421EA48A.E8A94619@earthlink.net>
Date: Thu, 24 Feb 2005 20:07:38 -0800
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Erblichs <erblichs@EARTHLINK.NET>
Subject: draft-nguyen-ospf-restart-05.txt : bit
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

>"PEACH.EASE.LSOFT.COM LISTSERV Server (14.3)" wrote:
> 
> Your  message is  being returned  to you  unprocessed because  it looks  like a
> LISTSERV command, rather than material intended for distribution to the members
> of the OSPF list. Please note that LISTSERV commands must ALWAYS be sent to the
> LISTSERV address;  if it  was indeed  a command you  were attempting  to issue,
> please send it again to LISTSERV@PEACH.EASE.LSOFT.COM for execution. Otherwise,
> please accept  our apologies  and try  to rewrite the  message with  a slightly
> different wording - for instance, change the first word of the message, enclose
> it  in quotation  marks, insert  a  line of  dashes  at the  beginning of  your
> message, etc.
> 
>   ------------------------------------------------------------------------
> 
> Subject: draft-nguyen-ospf-restart-05.txt
> Date: Thu, 24 Feb 2005 15:06:12 -0800
> From: Erblichs <erblichs@earthlink.net>
> To: zinin@psg.com, akr@cisco.com, lhnguyen@cisco.com,
>      OSPF@PEACH.EASE.LSOFT.COM
> 
> ok guys,
> 
>         I am sure that I am missing something here about
>         your implimentations of why you even need this bit.
> 
>         Wouldn't a simple method of delaying output of
>         a hello pkt when a interface comes up after a
>         graceful restart suffice?
> 
>         Yes, the minor stuff is to process hellos over
>         say 15 secs, set up the fields in the hello pkt
>         and then send hellos that are appropriate to the
>         recieved information... Yes, if hellos are lost
>         going to the restarting router, then those nbrs hellos
>         would not be seen and not stated in the hello
>         based reply by the restarting router.
> 
>         Thus all hellos recieved from nbrs, would see a
>         reply hello with that nbr stated.This would be a
>         transparent change vs the need to support this
>         new bit.
> 
>         Yes, for your knowledgeable people out there, demand
>         circuits suppresss hellos, so the hello sent on a
>         demand circuit with GR would need an flag to generate
>         a longer delay. However, I would expect this to
>         happen anyway...
> 
>         Mitchell Erblich

draft-nguyen-ospf-restart-05.txt : bit Erblichs