Subject: [OSPF] Update to OSPF Graceful Restart procedure - draft-holla-ospf-update-graceful-restart-02.txt

From: Acee Lindem <[email-masked]>
Date: Mon, 04 Dec 2006 18:07:09 -0500

This draft was presented in Montreal and was refreshed prior to the San 
Diego IETF.
It proposes two change to RFC 3623.

   1) Helper termination criteria between strict-LSA checking and no LSA 
checking.
   2) Explicit helper notification that graceful restart is terminated 
(other than flooding an
       inconsistent LSA).

Right now there isn't consensus as to whether or not there are 
requirements for these
enhancements.  Since in this E-mail I'm speaking as WG Co-chair, I'll 
comment as a
WG member and RFC 3623 co-author in a separate E-mail.

Please read the refresh version of the draft and comment.

Thanks,
Acee

_______________________________________________
OSPF mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ospf

---

From: Erblichs <[email-masked]>
Date: Thu, 07 Dec 2006 14:25:52 -0800

Hi Sujay, et al,

	The RFC 3623 has at least what I believe to be these
	loopholes. The first 8 should be no-brainers, IMO :-)
	Except #6. Since 99+% IMO are BMA envs and most of
	my work is their, no suggestions pertain stricly 
	to non BMA envs.

	1) Before GR-LSAs are sent, their should be a check for
	   Opaque capability (identified during database exchange).
	   If no capability, it should be prematurely terminated.
	   FYI: GR-LSAs are Opaque LSAs which require Opaque support.

	2) To support up to 1 hr.
	   If the GR-rtr is a DR-other re-originating self LSAs
	   should give 1 hrs worth of time. 

	2b) If the original self
	   orig LSAs were DNA LSAs, they need to be re-originated
	   as non DNA LSAs during the GR-interval.

	3) Re-sending GR-LSAs  frequently needs to be explicitly stated
	   to be limited to the standard of LSA retransmission of
	   MinLSInterval (5) secs.

	4) No MAXAGE LSAs should be outstanding by any of the
	   rtrs on the link when the GR-LSAs are xmited.

	5) No LSAs should be present on any full adj rexmit list at
	   the time that the GR-rtr stops ackimg OSPF control pkts from 
	   its full adj nbrs.

	6) If the GR-rtr X is a DR other, it should be explictly stated
	   that the DR/BDR SHOULD flood these GR-LSAs back on the link
	   without consideration that their are no direct full adj rtrs
	   to GR-rtr X.

	7) The draft could be made clearer if a timeline were
	   used as: at GR-time 0, pre rtr-X, verifies that no OSPF
	   events are occuring and that its rexmits lists are empty.
	   It it then validates its full adj nbrs for Opaq support and
	   if present, originates Gr-LSAs. Rtr-X SHOULD waits for acks
	   of its GR-LSAs and starts the GR-interval timer which occurs
	   at GR-time 1. ...

	8) If rtr-Y accepts helper responsibilites, then it should back
	   off any flooding / retransmissions to rtr-X of OSPF control
	   pkts for a max of the GR-interval.

	 9) ??? If GR-rtr is a DR-other, then why NOT support a secondary type
	   of rtr helper-Y? If they support GR, then they are allowed
	   to keep their original hello until the GR-interval ends.
	   No other support is required by the secondary rtr-Ys.
	   By link flooding requirements they all must recv the GR-LSAs.
	   No, they won't understand them if they don't support Opaque LSAs
	       and thus THOSE will no longer adv rtr-X after rtr dead interval.

	A) ??? Topology changes..

	   a) Should a new link / intf ALYWAYS prematurely end a GR-helper-y.
	      If this new link has a higher outgoing cost by say helper-Y
	      than the link to Gr-rtr-X, shouldn't it be obvious that we
	      prefer the link to X?

	     Why can't we run the new SPF algor, flood the LSA, and
	     not BLACKHOLE rtr-X?

	     If the GR-rtr is a DR. Worse-case.  the flooding will still occur
	     via the BDR. Yes, a requirement is that if the GR-rtr is a DR,
	     the BDR must be present.

	Mitchell Erblich

sujay gupta wrote:
> 
> Mithcell,
> Thanks for your previous comments.
> Could you please add to the list the RFC 3623
> original draft has loops and we need some
> update to resolve them.
> Thanks,
> Sujay
> 
> ---------- Forwarded message ----------
> From: Acee Lindem <[email-masked]>
> Date: Dec 5, 2006 4:37 AM
> Subject: [OSPF] Update to OSPF Graceful Restart procedure -
> draft-holla-ospf-update-graceful-restart-02.txt
> To: OSPF List <[email-masked]>
>