Re: Zero as ospfIfRetransInterval

Eric Gray <ewgray@GRAIYMAGE.COM> Wed, 25 June 2003 15:23 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 LAA15156 for <ospf-archive@LISTS.IETF.ORG>; Wed, 25 Jun 2003 11:23:49 -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 <19.00A312C8@cherry.ease.lsoft.com>; Wed, 25 Jun 2003 11:20:13 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 46593686 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 25 Jun 2003 11:20:05 -0400
Received: from 12.129.211.119 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 25 Jun 2003 11:10:05 -0400
Received: from [65.211.67.100] (helo=GraIyMage.com) by host19.ipowerweb.com with asmtp (Exim 3.36 #1) id 19VBu5-0001Pt-00; Wed, 25 Jun 2003 08:09:45 -0700
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD NSCPCD47 (WinNT; I)
X-Accept-Language: en,pdf
MIME-Version: 1.0
References: <E7E13AAF2F3ED41197C100508BD6A328DD4547@india_exch.corp.mot.com> <3EF84BA9.6090701@redback.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - host19.ipowerweb.com
X-AntiAbuse: Original Domain - peach.ease.lsoft.com
X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [0 0]
X-AntiAbuse: Sender Address Domain - graiymage.com
Message-ID: <3EF9BA41.8370DC42@GraIyMage.com>
Date: Wed, 25 Jun 2003 11:05:37 -0400
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Eric Gray <ewgray@GRAIYMAGE.COM>
Subject: Re: Zero as ospfIfRetransInterval
Comments: To: Acee Lindem <acee@redback.com>
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

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?

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