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

From: Erblichs <[email-masked]>
Date: Tue, 31 Jan 2006 16:06:05 -0800

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.

	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 is no
	longer a requirement for neighbor acceptance in many
	implementations.

	Mitchell Erblich

---

From: Erblichs <[email-masked]>
Date: Tue, 31 Jan 2006 16:13:30 -0800

Group,

	Actually, I want to make one minor change to the
	2nd suggestion. Hands faster than the mind :^)

	Mitchell Erblich
	------------------

Erblichs wrote:
>         if the original hello protocol is followed, but 

	the HelloInterval

	is no

---

From: Dave Katz <[email-masked]>
Date: Tue, 31 Jan 2006 16:41:41 -0800

I'm assuming that in this "fast hello" mode, routers send a hello  
interval of 0 and a dead interval of 1?  Strictly speaking, there's  
nothing to ignore, since the only test is that everybody is saying "0".

In any case, this draft doesn't seem to be the place to talk about  
changes to OSPFv2, which I believe is what you're really referring  
to.  Changes to the base spec (that don't conflict with v3) should be  
in a separate draft.

--Dave

---

From: Erblichs <[email-masked]>
Date: Tue, 31 Jan 2006 17:43:31 -0800

Dave Katz,

	First, I did do an almost immediate followup
	to keep just dead interval as a valid match
	in this suggestion. That is all that is really
	needed and still behave as expected.

	Yes... But the 0 value is ignored and
	doesn't follow the expected original usage
	of what we should do if we see a 0.

	AND Because we later specify in section
	C.3 Router interface parameters

	"HelloInterval
      The length of time, in seconds, between Hello Packets that the
      router sends on the interface.  This value is advertised in the
      router's Hello Packets.  It MUST be the same for all routers
      attached to a common link.  The smaller the HelloInterval, the
      faster topological changes will be detected.  However, more OSPF
      routing protocol traffic will ensue.  Sample value for a X.25 PDN:
      30 seconds.  Sample value for a local area network (LAN): 10
      seconds."

	And in the preceeding section and throughout
	this document, implementations are diverging
	so far from RFCs, that some of these docs are
	becoming mythical..

	Would the avg router BREAK if they see a
	0 for HelloInterval and not configured via a
	CLI to see it.

	If they would, these RFCs are supposed to attempt
	to achieve compatiblity. This suggestion is to
	attempt to still achieve that goal in this section.

	LASTLY, yes, I do believe that many v3 implimentations
	also support some notion of "fast hellos".

	Mitchell Erblich
	---------------------

---

From: Acee Lindem <[email-masked]>
Date: Tue, 31 Jan 2006 20:48:30 -0500

Hi Mitchell,

>	2nd suggestion. Hands faster than the mind :^)
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 :^).

>>        longer a requirement for neighbor acceptance in many
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