Re: Zero as ospfIfRetransInterval

Acee Lindem <acee@REDBACK.COM> Thu, 26 June 2003 14:17 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 KAA27350 for <ospf-archive@LISTS.IETF.ORG>; Thu, 26 Jun 2003 10:17:30 -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 <17.00A34118@cherry.ease.lsoft.com>; Thu, 26 Jun 2003 10:17:24 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 46716084 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 26 Jun 2003 10:17:22 -0400
Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 26 Jun 2003 10:16:22 -0400
Received: from redback.com (login005.redback.com [155.53.12.60]) by prattle.redback.com (Postfix) with ESMTP id 2B513D9200 for <OSPF@PEACH.EASE.LSOFT.COM>; Thu, 26 Jun 2003 07:16:21 -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: <E7E13AAF2F3ED41197C100508BD6A328DD456F@india_exch.corp.mot.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Message-ID: <3EFB004E.7010605@redback.com>
Date: Thu, 26 Jun 2003 10:16:46 -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
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list
Content-Transfer-Encoding: 8bit

Hi Vishwas,

Manral, Vishwas wrote:
> Hi folks,
>
> Some similar thoughts.
>
> 1. RFC2328 says that: -
>
>     InfTransDelay
>         The estimated number of seconds it takes to transmit a Link
>         State Update Packet over this interface.  LSAs contained in the
>         Link State Update packet will have their age incremented by this
>         amount before transmission.  This value should take into account
>         transmission and propagation delays; it must be greater than
>         zero.
>
> MIB allows it to be 0.
>
>    ospfIfTransitDelay OBJECT-TYPE
>          SYNTAX       UpToMaxAge
>          MAX-ACCESS   read-create
>          STATUS       current
>          DESCRIPTION
>             "The estimated number of seconds it takes to
>             transmit a link state update packet over this
>             interface."
>          DEFVAL { 1 }
>          ::= { ospfIfEntry 7 }
>
> 2. Also what would a value of 0 for RestartInterval mean. Though it would
> not create a problem.
>
> 3. Besides what would a value greater than 1800 mean for
> RetransmitInterval(no problem caused by it though). May be the limit could
> be RefreshInterval.
>
> I will change these in the OSPFv3 MIB atleast.

Sounds good - we should definitely fix these.


>
> Thanks,
> Vishwas
>
> -----Original Message-----
> From: Schrodi Karl [mailto:karl.schrodi@SIEMENS.COM]
> Sent: Thursday, June 26, 2003 13:33
> To: OSPF@PEACH.EASE.LSOFT.COM
> Subject: AW: Zero as ospfIfRetransInterval
>
>
> Hi Acee,
>
> I fully understand that retransmission is mandatory - but does it really
> make sense to have a retransmission interval of zero? Wouldn┬┤t it be like
> some kind of a DoS attack against yourself and your neighbour(s)?
>
> Well, probably nobody reasonably will set this interval to zero - but ...
>
> I would prefer something like the previous proposal of Vishwas, i.e. putting
> a limitation in the object description in the MIB.
>
> Regards
> Karl
>
>
> -----Urspr├╝ngliche Nachricht-----
> Von: Acee Lindem [mailto:acee@REDBACK.COM]
> Gesendet: Mittwoch, 25. Juni 2003 19:03
> An: OSPF@PEACH.EASE.LSOFT.COM
> Betreff: Re: Zero as ospfIfRetransInterval
>
>
> 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
>


--
Acee