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

[Abhay Roy <[e-mail]>]

Mitchell,

In case of 'always up' DC links, it does turn out to be periodic
probing. But in case of 'on demand' DC links, (if there is no data
traffic) it's of no use to bring up the link just to send probes.
So it makes sense to piggy back this event on the link coming up
event, and keep doing it periodically till the time line remains
up (due to data traffic).

Regards,
-Roy-

On 05/28/03-0700 at 5:01pm, Erblichs writes:

> Abhay Roy and Acee Lindem,
>
>         If the mechanism is to detect only dead neighbors,
>         then why wouldn't their be just a periodic probing
>         of the neighbor every 45 minutes or so, without
>         respect to the application data traffic?
>
>         In addition, if a probe is recieved and responded
>         to within the 1 hr time frame, then a  probe in the
>         reverse direction would not be necessary until
>         the next time interval.
>
>         If on the other hand it is important to know that
>         the data was successfully transmitted over the DC
>         (which infers a live nbr), then a verification of a
>         successful probe, in my opinion should proceed the
>         transmit of the application data.
>
>         Lastly, my MTU size packet is not to verify that the
>         link-MTUs match between the two nbrs. It is to verify
>         that MTU size buffers are available for the incoming
>         application traffic. It is assumed that a MTU probe
>         length, will be of an insignificant amount of additional
>         data and processing overhead.
>
>         Mitchell Erblich
>         Sr Software Engineer
>         -------------------
>
> Acee Lindem wrote:
> >
> > I agree with Abhay on all points.  Especially that we do not want
> > to make this a mechanism to verify MTU agreement or verify the
> > data plane. It is solely a mechanism to detech dead OSPF neighbors
> > over demand circuits.
> >
> > Abhay Roy wrote:
> > > 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
> > >>>>>
> > >>
> > >
> >
> > --
> > Acee
>