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

[Erblichs <[e-mail]>]

Sorry group,

        I forgot..

        E) If ..ProbeInterval is kept, its max value MUST not exceed
           1 hr..

        I think this follows that if we haven't heard from our
        nbr in 1 hr "he" is considered dead.

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

Erblichs wrote:
>
> "L-Soft list server at PEACH.EASE.LSOFT.COM (1.8e)" wrote:
> >
> > Your  message is  being returned  to you  unprocessed because  it looks  like a
> > LISTSERV command, rather than material intended for distribution to the members
> > of the OSPF list. Please note that LISTSERV commands must ALWAYS be sent to the
> > LISTSERV address;  if it  was indeed  a command you  were attempting  to issue,
> > please send it again to [e-mail] for execution. Otherwise,
> > please accept  our apologies  and try  to rewrite the  message with  a slightly
> > different wording - for instance, change the first word of the message, enclose
> > it  in quotation  marks, insert  a  line of  dashes  at the  beginning of  your
> > message, etc.
> >
> >   ------------------------------------------------------------------------
> >
> > Subject: Re: FW: Last Call: Detecting Inactive Neighbors over OSPF Demand
> >      Circuits to Proposed Standard
> > 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.
> >
> >         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
> > > > > [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
> > > >