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
- Zero as ospfIfRetransInterval Igor Miroshnik
- Re: Zero as ospfIfRetransInterval Acee Lindem
- Re: Zero as ospfIfRetransInterval Daniel Joyal
- Re: Zero as ospfIfRetransInterval Acee Lindem
- Re: Zero as ospfIfRetransInterval Manral, Vishwas
- Re: Zero as ospfIfRetransInterval Acee Lindem
- Re: Zero as ospfIfRetransInterval Jeff Parker
- Re: Zero as ospfIfRetransInterval Greg Mirsky
- Re: Zero as ospfIfRetransInterval Eric Gray
- Re: Zero as ospfIfRetransInterval Acee Lindem
- Re: Zero as ospfIfRetransInterval Manral, Vishwas
- Re: Zero as ospfIfRetransInterval Acee Lindem