RE: I-D ACTION:draft-kompella-tewg-bw-acct-00.txt

["Sudhakar Ganti" <sganti@tropicnetworks.com>]

Hi Amir,

A node allocates bandwidth based on it's own internal
resources (e.g, buffer), how much you want to book a 
link, design of the node itself, traffic models
assumed and other such factors. Therefore the BW
allocation is node's internal view and is implementation
specific.

All the drafts talk about advertising the "node's view" 
of the resources. That is logical and correct. This is 
needed so that a better decison can be made if "QoS 
routing" is employed in the network. There is no inter-
operability issue here. You make a routing decison based 
on the "current view" of the network resources.

-Sudhakar

> -----Original Message-----
> From: owner-te-wg@ops.ietf.org [mailto:owner-te-wg@ops.ietf.org]On
> Behalf Of Amir Hermelin
> Sent: Sunday, July 22, 2001 5:33 AM
> To: Sudhakar Ganti
> Cc: TE-wg (E-mail)
> Subject: RE: I-D ACTION:draft-kompella-tewg-bw-acct-00.txt
> 
> 
> > 1) First, I am surprised to see a draft describing
> >    bandwidth accounting (or CACing).Thought these 
> >    are internal to a node, implementation specific
> >    and should not be influenced by standards.
> 
> TE bw accounting is mostly *not* internal to a node, *not*
> implementation specific, and *should* be interoperable. Otherwise, why
> have drafts on advertising these values in the first place?
> 
> --
> Amir Hermelin                    <mailto:amir@cwnt.com>
> Charlotte's Web Networks Inc.     <http://www.cwnt.com>
> 
> 
> > -----Original Message-----
> > From: Sudhakar Ganti [mailto:sganti@tropicnetworks.com]
> > Sent: Saturday, July 21, 2001 12:20 AM
> > To: Kireeti Kompella
> > Cc: te-wg@ops.ietf.org
> > Subject: RE: I-D ACTION:draft-kompella-tewg-bw-acct-00.txt
> > 
> > 
> > Hi Kireeti,
> > 
> > A few more comments on the draft:
> > 
> > 1) First, I am surprised to see a draft describing
> >    bandwidth accounting (or CACing).Thought these 
> >    are internal to a node, implementation specific
> >    and should not be influenced by standards.
> > 2) The term "priority" is kind of overloaded in 
> >    Section 7.1. If priority is referring to a service
> >    class (or a PSC as in Diffserv), then please
> >    change the name appropriately. Or are you inferring
> >    preemption priority is one-to-one mapped to the service
> >    class? I am assuming that is not the case.
> > 3) I thought Class type is only useful in reducing the
> >    flooding information of IGP protocols and one needs
> >    per-class bandwidth accounting anyway. For example
> >    you can use different CAC parameters for the classes
> >    belonging to the same Class-type, but consume bandwidth
> >    from same aggregated pool. Therefore Class Type band
> >    width pool may not necessarily mean that we don't 
> >    need per-class bandwidth accounting.
> > 4) Is there any reason why you did not discuss FA-LSPs or
> >    hierarchical tunnels, corresponding bandwidth accounting,
> >    bandwidth accounting of LSPs riding on the tunnels and
> >    overbooking?
> > 
> > -Sudhakar
> > 
> > 
> 
>