Re: FW: Last Call: Detecting Inactive Neighbors over OSPF Demand Circuits to Proposed Standard

[Erblichs <erblichs@earthlink.net>]

Ok,

	If I wanted to look into the draft itself, then I have 4 suggestions
	labed A, B, C, and D.

	A) No order is implied..
	2.  "When application traffic starts going over the link, the
             link is brought up, and the routers may probe each other."

	The wording could be improved to specify:

	After the link is brought up, a probe SHOULD be sent if ..ProbeInterval
	has expired, and after verifying a successful probe, then application
	data can be sent.

	B) Configurable Parameters
	
	Did I see any usage of these parameters in the draft? Shouldn't
	some wording be used for them in the draft before the
	appendix?

	C) ...ProbeInterval

	I question whether a sucessful probe that is specified in this
	draft will guarantee that even with link that is up that application
	traffic will be properly recieved.

	Why? A probe with a minimum packet/frame size may succeed in
	a buffer allocation where application traffic may use a MTU
	size packet. Thus, probes should be of MTU size.
	(this type of verification is done in IS-IS)

	 Thus, I would add a suggested probe size of MTU size.

	D) .. ProbeInterval

	I question that an demand link uptime can be shorter
	than ..ProbeInterval. In the event that ..ProbeInterval
	is longer than successive application transmissions, then
	some application traffic is sent without a prior probe.
	
	Thus, for the paranoid of us, I would expect that a probe be sent
	before and after application data. This would allow a higher
	assurance level of successful transmission of the application
	data.

	Thus, my suggestion is to remove the ..ProbeInterval config
	value and suggest bracketing application data with probes.

	My only issue, is if the first probe succeeded and the 2nd failed,
	then what do you do?

	Minimally, I would expect a probe before each application transmit
	and remove the ..ProbeInterval config value.

	Mitchell Erblich
	Sr Software Engineer
	-----------------------

> >
> > The IESG wrote:
> > >
> > > The IESG has received a request from the Open Shortest Path
> > > First IGP Working Group to consider Detecting Inactive Neighbors
> > > over OSPF Demand Circuits <draft-ietf-ospf-dc-06.txt> as a
> > > Proposed Standard.
> > >
> > > The IESG plans to make a decision in the next few weeks,
> > and solicits
> > > final comments on this action.  Please send any comments to the
> > > iesg@ietf.org or ietf@ietf.org mailing lists by 2003-6-10.
> > >
> > > Files can be obtained
> > > via http://www.ietf.org/internet-drafts/draft-ietf-ospf-dc-06.txt
> >