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

[Acee Lindem <[e-mail]>]

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