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

[Erblichs <[e-mail]>]

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