Re: Two-octet bandwidth values

[Bora Akyol <akyol@pluris.com>]

Well maybe the right thing to do is not to use ISIS as a reliable 
multicast mechanism and hence not overload the routing protocol by 
flooding all sorts of G-MPLS, hierarchical LSP and also WSJ ticker 
information ;-)

I would agree that the information that is being flooded is remotely 
routing related (although not directly related to IP) but is there a way 
to create another PDU type that can be flooded via ISIS but has 
different packet formats and does not crowd the existing sub-TLV.


Coming to your comment about the math on the OC768c, even if I was 
wrong, 67 Mbps is still a large value to be off by. That is larger than 
a DS1, do you think that people will not notice some TE calculation 
being off by 67 Mbps? What if I were bonding (PPP LBD is a WG item in 
PPP EXT WG) 10 OC192c's, then I will be off by more than 100 Mbps.

I am repeating myself here, but I think we have better things to work on 
then redefining existing TE TLVs.



Bora



On Tuesday, March 27, 2001, at 07:11 PM, Qingming Ma wrote:

> At 05:15 PM 3/26/01 -0800, Bora Akyol wrote:
>
>> 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.
>
> No one said the present approach is wrong. The problem you will soon
> use out all sub-TLLV space in ISIS for further extensions. You can work
> with the  present  TE TLVs,  if there is enough sub-TLV space.
>
>
>>> 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.
>
> Again, it may not be very useful, if there is sufficient sub-TLV space.
>
>
>
>>> 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.
>
> First, you did not do your Math correct. If you have bandwidth
> value as large as OC768c, the accuracy can be at 67 Mbps
> level, rather than 400 Mbps. When you use the bandwidth value
> to select a path, I don't think you need to worry about the bandwidth
> value 67 Mbps more or less if the link has available bandwidth
> at 40 Gbps level.
>
>
>>> 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
>