Re: Zero as ospfIfRetransInterval

Acee Lindem <acee@REDBACK.COM> Wed, 25 June 2003 17:06 UTC

Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21421 for <ospf-archive@LISTS.IETF.ORG>; Wed, 25 Jun 2003 13:06:08 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.00A3173C@cherry.ease.lsoft.com>; Wed, 25 Jun 2003 13:06:09 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 46608560 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 25 Jun 2003 13:06:08 -0400
Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 25 Jun 2003 13:06:08 -0400
Received: from redback.com (login003.redback.com [155.53.12.55]) by prattle.redback.com (Postfix) with ESMTP id BCAD579EA80; Wed, 25 Jun 2003 10:06:03 -0700 (PDT)
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02
X-Accept-Language: en-us, en
MIME-Version: 1.0
References: <E7E13AAF2F3ED41197C100508BD6A328DD4547@india_exch.corp.mot.com> <3EF84BA9.6090701@redback.com> <3EF9BA41.8370DC42@GraIyMage.com>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Message-ID: <3EF9D5BC.4030805@redback.com>
Date: Wed, 25 Jun 2003 13:02:52 -0400
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Acee Lindem <acee@REDBACK.COM>
Subject: Re: Zero as ospfIfRetransInterval
Comments: To: ewgray@GraIyMage.com
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Eric Gray wrote:
> Acee,
>
>     Why would it be wrong to set a retransmit interval to zero?  Usually,
> setting a retransmit interval to zero would have the special meaning that
> retransmission does not occur (i.e. - the interval is infinite).  Is that not
> an intended meaning in this case?

Nope - not retransmitting would make the flooding unreliable and
would violate the base protocol specification (RFC 2328).

>
> Acee Lindem wrote:
>
>
>>Manral, Vishwas wrote:
>>
>>>Hi Acee,
>>>
>>>If we do not intend to define new variables, we may want to at least put the
>>>limitation of 0, in the object description in the MIB.
>>
>>Hi Vishwas,
>>
>>That sounds like a good idea since any implementation that allows
>>write access to set the variables to 0 is broken.
>>
>>Thanks,
>>Acee
>>
>>
>>>Thanks,
>>>Vishwas
>>>
>>>-----Original Message-----
>>>From: Acee Lindem [mailto:acee@REDBACK.COM]
>>>Sent: Tuesday, June 24, 2003 18:16
>>>To: OSPF@PEACH.EASE.LSOFT.COM
>>>Subject: Re: Zero as ospfIfRetransInterval
>>>
>>>
>>>Hi Dan,
>>>
>>>Daniel Joyal wrote:
>>>
>>>
>>>>You're not allowed to change the syntax unless
>>>>it's equivalent to the old syntax.
>>>
>>>
>>>Even if the old syntax doesn't match the protocol
>>>specification?
>>>
>>>
>>>
>>>
>>>>So in this
>>>>case, we would need to deprecate/obsolete.
>>>
>>>
>>>Then I don't think it is worth defining
>>>new MIB variables given that ospfIfTransitDelay,
>>>ospfIfRetransInterval, ospfVirtIfTransitDelay, and
>>>ospfVirtIfRetransInterval have served us thus far.
>>>
>>>Other opinions are welcome.
>>>
>>>Thanks,
>>>Acee
>>>
>>>
>>>
>>>>-Dan
>>>>
>>>>
>>>>>-----Original Message-----
>>>>>From: Acee Lindem [mailto:acee@redback.com]
>>>>>Sent: Monday, June 23, 2003 11:35 PM
>>>>>To: Mailing List; Joyal, Daniel [BL60:NP30:EXCH]
>>>>>Subject: Re: Zero as ospfIfRetransInterval
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>Igor Miroshnik wrote:
>>>>>
>>>>>>All,
>>>>>>
>>>>>>Can anybody clarify the physical sense of assigning
>>>>>>ospfIfRetransInterval to zero? RFC1850 allows such an assignment.
>>>>>
>>>>>I believe UpToMaxAge should range from 1..3600 rather than 0..3600.
>>>>>
>>>>>Dan - can we change this in the MIB update without
>>>>>deprecating variables?
>>>>>
>>>>>
>>>>>>Thanks
>>>>>>
>>>>>
>>>>>
>>>>>--
>>>>>Acee
>>>>>
>>>>>
>>>>
>>>
>>>--
>>>Acee
>>>
>>
>>--
>>Acee
>
>
>
>


--
Acee