Re: FW: Last Call: Detecting Inactive Neighbors over OSPF Demand

[Abhay Roy <[e-mail]>]

Mitchell,

Please see some comments inline..

> > Date: Wed, 28 May 2003 11:52:47 -0700
> > From: Erblichs <[e-mail]>
> > To: [e-mail], [e-mail]
> > References: <[e-mail]>
> >
> > 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.

We can change MAY to a SHOULD.

The latter part implies that the data should not be sent till the
probe succeeds.. I don't think there is any need to be that
extreme. The success of probes depends on possibly retransmitting
the Update packet multiple times. And I don't see much value
(except maybe in the case, when the neighbor is indeed dead) in
dropping the data for that much time.

> >         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?

We got the same comment from the AD ;) We will fix it..

> >         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.

OSPF uses Interface MTU during DBD exchange to make sure that
MTU's match.. If there was an MTU problem, the adjacency will not
progress to FULL state.. The probe is just an OSPF update packet,
so it has no size restrictions..

> >         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.

To me, the probe is just a background task to verify the viability
of the DC link to a neighbor. I don't see how data plane waiting
for control plane verification is going to help..

Regards,
-Roy-


> >         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
> > > > > [e-mail] or [e-mail] mailing lists by 2003-6-10.
> > > > >
> > > > > Files can be obtained
> > > > > via http://www.ietf.org/internet-drafts/draft-ietf-ospf-dc-06.txt
> > > >
>
>