Subject: Re: draft-ietf-ospf-ospfv3-update-07.txt : Constants

From: Erblichs <[email-masked]>
Date: Wed, 1 Feb 2006 12:44:09 -0800

Acee, et al,

	Two additional notes on this thread.

	1) The IETF BFD draft is a sledgehammer to OSPF
	for subsecond liveness. Implementations may
	consume months of development and excess of
	a 1000 lines of code. Yes, the WG is appying
	it to every protocol.

	Fast hellos have been around for years and
	require less than a afternoons worth of work,
	with maybe 50 lines of code. It also achieves
	90+% of what is needed in OSPF and is used by
	the majors.  However, their is no mention of 
	its existance in any IETF doc that I know of..

	So, when the v3 spec is re-drafted, I decided to
	try to get the hello protocol's second
	granularity mentioned configurables
	at least updated in a arch dependent manner.

	2) There are many documents dealing with scalability,
	faster convergence, etc that alludes to TUNING these
	FIXED/architectural constants.

	Any enterprise level OSPF implementation is not going
	to leave these unchanged and documenting that they are
	no longer constant in many implementations IMO would
	be prudent.

	Mitchell Erblich

	

Acee Lindem wrote:
> 
> Hi Mitchell,
> 
> Erblichs wrote:
> 
> >Group,
> >
> >       Actually, I want to make one minor change to the
> >       2nd suggestion. Hands faster than the mind :^)
> >
> >       Mitchell Erblich
> >       ------------------
> >
> >Erblichs wrote:
> >
> >
> >>Group,
> >>
> >>        1) Appendix B.  Architectural Constants
> >>
> >>        I know of very few original "Architectural Constants"
> >>        that were originally specified in the OSPFv2 spec,
> >>        that currently remain as their specified default.
> >>
> >>        IMO, this spec could acknowledge that fact by
> >>        stating:
> >>
> >>        Although these items are identified as Architectural
> >>        Constants; scalability, reliability, convergence
> >>        considerations, etc. have dictated some flexibility in
> >>        their values. Thus, when not explicitly modified,
> >>        these original values SHOULD be considered defaults.
> >>
> >>
> I don't agree with this suggestion. First of all, I'm not going to
> allude to what some
> implementions have done without an IETF document precisely describing
> it. Second, in the
> instances where these value may be  modified by an implementation, an
> IETF document
> isn't necessary for interoperability (give or take a retransmission now
> and then :^).
> 
> >>        2) Appendix C.  Configurable Constants
> >>
> >>        "Similarly, all routers attached to a network must
> >>   agree on that network's HelloInterval and RouterDeadInterval."
> >>
> >>        In most enterprise and other implementations, the default
> >>        hello protocol specified in the V2 doc has been supplimented
> >>        with "fast hello" implementations for subsecond aliveness.
> >>
> >>        The standard "fast hello" Hello Interval is set to 0 on
> >>        transmit and IGNORED on reception, thus I suggest the
> >>        following change.
> >>
> >>        Similarly, all routers attached to a network must
> >>   agree on that network's HelloInterval and RouterDeadInterval
> >>        if the original hello protocol is followed, but
> >>
> >>
> >
> >       the HelloInterval
> >
> >       is no
> >
> >
> >>        longer a requirement for neighbor acceptance in many
> >>        implementations.
> >>
> >>
> This isn't true. However, it doesn't matter since fast hellos are not
> described in an IETF
> document. And, before anyone looking for their 15 minutes of fame
> submits a draft,
> note the BFD is the IETF agreed upon mechanism for sub-second liveliness
> detection (Dave
> will probably correct me here).
> 
> Thanks,
> Acee
> 
> >>        Mitchell Erblich
> >>
> >>
> >
> >
> >

---

From: Acee Lindem <[email-masked]>
Date: Thu, 2 Feb 2006 11:57:01 -0500

Hi Mitchell,

Erblichs wrote:

>	the majors. 
The majors??  IMHO, fast hellos may be good for a trade show demo but in 
practice they're
too fragile (especially the 50 LOC variety).. Anyway, that isn't the 
debate here. Fast
hellos don't belong in the base specification - the details of it 
haven't been documented
or accepted by the OSPF WG.

> However, their is no mention of 
Which documents - Same answer as above.

Thanks,
Acee

---

From: Erblichs <[email-masked]>
Date: Fri, 3 Feb 2006 00:16:25 -0800

Acee,

> >>>>       longer a requirement for neighbor acceptance in many

	This original statement does not mention "fast hellos".
	It only tries to limit the mandatory original meaning of
	HelloInterval.

	It could also be simplified to cut it before the ", but....".

	Group, the fast hello feature was only being used to enforce
	the meaning of why HelloInterval should be dropped. Another
	one could be the BFD draft.

	As to fragility, I would hope that is an implementation
	issue and not a arch issue. :^)

	Mitchell Erblich
	-----------------
> or accepted by the OSPF WG.
	I am not really suggesting

---

From: Acee Lindem <[email-masked]>
Date: Fri, 3 Feb 2006 05:35:44 -0500

>	It only tries to limit the mandatory original meaning of
As Dave noted, this doesn't change for fast hellos. HelloInterval is 
advertised as 0
and DeadInterval is advertised as 1.

Thanks,
Acee