Re: Zero as ospfIfRetransInterval

"Manral, Vishwas" <VishwasM@NETPLANE.COM> Thu, 26 June 2003 12:43 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 IAA20365 for <ospf-archive@LISTS.IETF.ORG>; Thu, 26 Jun 2003 08:43:54 -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 <18.00A33DB0@cherry.ease.lsoft.com>; Thu, 26 Jun 2003 8:43:47 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 46706841 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 26 Jun 2003 08:43:45 -0400
Received: from 129.188.136.101 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 26 Jun 2003 08:43:02 -0400
Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id h5QCh2G9018890 for <OSPF@PEACH.EASE.LSOFT.COM>; Thu, 26 Jun 2003 05:43:02 -0700 (MST)
Received: from xover.corp.mot.com (xover.corp.mot.com [10.1.148.18]) by il06exr03.mot.com (Motorola/il06exr03) with ESMTP id h5QCh0SR020936 for <OSPF@PEACH.EASE.LSOFT.COM>; Thu, 26 Jun 2003 07:43:00 -0500
Received: by xover.corp.mot.com with Internet Mail Service (5.5.2653.19) id <NNKYZF24>; Thu, 26 Jun 2003 08:42:40 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Message-ID: <E7E13AAF2F3ED41197C100508BD6A328DD456F@india_exch.corp.mot.com>
Date: Thu, 26 Jun 2003 08:44:30 -0400
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: "Manral, Vishwas" <VishwasM@NETPLANE.COM>
Subject: Re: Zero as ospfIfRetransInterval
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list
Content-Transfer-Encoding: quoted-printable

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.

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