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

[Erblichs <[e-mail]>]

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