Re: Two-octet bandwidth values

["Frank Hujber" <fhujber@hotmail.com>]

I guess, if the need to specify down to the tesn of bits per second is
critical, then the only way is to find a way to expand the IEEE floating
point format. Ugly.

Is the possibility of adding a sub-TLV for this all that objectionable?

Frank
fhujber@hotmail.com

----- Original Message -----
From: "Bora Akyol" <akyol@pluris.com>
To: "Frank Hujber" <fhujber@hotmail.com>
Cc: "Kireeti Kompella" <kireeti@juniper.net>; "CCAMP List"
<ccamp@ops.ietf.org>; "John Drake" <jdrake@calient.net>
Sent: Tuesday, March 27, 2001 8:08 PM
Subject: Re: Two-octet bandwidth values


> Frank
>
> Bonds are not proprietary, our implementation (even though implemented
> independently and without knowledge of the document) is quite a like the
> PPP LBD draft in the PPP-EXT working group.
>
> The point is that 10 bits is not enough to represent large chunks of
> bandwidth accurately.
>
> Bora
>
>
> On Tuesday, March 27, 2001, at 01:44 PM, Frank Hujber wrote:
>
> > It occurs to me that the smallest increment of reservable bandwidth,
> > from a
> > practical perspective, is a DS1 (1.544 Mbps). If this is so, why do we
> > need
> > to be able to represent values to +/- 10bps?
> >
> > The builders of OXCs and PXCs can see down the road to OC-3072 even
> > though
> > there's not much being spent on it in the lab just yet, and some of
> > aren't
> > even looking much further back than OC-48. "Bonds" sound linke a
> > proprietary
> > implementation which no one will want to be beholden to.
> >
> > This ought to be considered further, even if it has to be put in a
> > separate
> > sub-TLV for backward compatibility reasons.
> >
> > Frank Hujber
> > fhujber@hotmail.com
> > ----- Original Message -----
> > From: John Drake <jdrake@calient.net>
> > To: 'Bora Akyol' <akyol@pluris.com>; Kireeti Kompella
> > <kireeti@juniper.net>
> > Cc: <ccamp@ops.ietf.org>; <OSPF@DISCUSS.MICROSOFT.COM>
> > Sent: Monday, March 26, 2001 8:36 PM
> > Subject: RE: Two-octet bandwidth values
> >
> >
> >> ditto
> >>
> >> -----Original Message-----
> >> From: Bora Akyol [mailto:akyol@pluris.com]
> >> Sent: Monday, March 26, 2001 5:16 PM
> >> To: Kireeti Kompella
> >> Cc: ccamp@ops.ietf.org; OSPF@DISCUSS.MICROSOFT.COM
> >> Subject: Re: Two-octet bandwidth values
> >>
> >>
> >>
> >> On Sunday, March 25, 2001, at 08:05 PM, Kireeti Kompella wrote:
> >>
> >>> Let's get the ball rolling.  Please send questions and comments to the
> >>> list.  Here are mine:
> >>>
> >>> Questions to vendors:
> >>> 1) Is floating point arithmetic a burdensome requirement?  Is having
> >>>    a new library of functions for the two-octet "floating point"
> >>>    representation a burdensome requirement?
> >>>
> >>
> >> I don't see what exactly is wrong with the present approach, we have no
> >> problem working with the present TE TLVs and no problems with floating
> >> point.
> >>
> >>> 2) Is halving the size of the bandwidth TLVs a big win (keep in mind
> >>>    that more bandwidth TLVs are being proposed)?
> >>>    (a) for ISIS?
> >>>    (b) for OSPF?
> >>>    (c) if the answers for ISIS and OSPF differ, is it acceptable to
> >>>        have different formats for the two protocols?
> >>>
> >>
> >> I think it is unacceptable to have OSPF and ISIS TE TLVs differ. I
> >> think
> >> halving the size of the bandwidth TLVs is not very useful. It causes
> >> yet
> >> another "transition" problem just as people are getting used to the
> >> present scheme.
> >>
> >>
> >>> Questions to vendors & carriers:
> >>> 1) Is 10 bits of dynamic range (0.1% accuracy) good enough?
> >>>
> >> This depends a lot on the bandwidth, on an OC768c this will translate
> >> to
> >> a whopping 400 Mbps, which to me is inadequate.  Our routers also
> >> support bundled links which we call "Bonds" that can achieve bandwidths
> >> much larger than 40 Gbps. So my answer to 10 bits of dynamic range is
> >> NO.
> >>
> >>> 2) Are you in favor of this draft, or against?
> >>>
> >>
> >> Seems like we have more important stuff to focus on then this
> >> particular
> >> topic.
> >>
> >> Bora
> >>
> >>
> >
>
>