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

["Amir Hermelin" <amir@cwnt.com>]

Sudhakar,

let me clarify: CSPF calculations are used to find paths that meet
certain traffic constraints (e.g. remove congestion, etc.). QoS has do
with queues, scheduling, etc. TE and QoS are two entirely different
terms.
Engineering traffic according to certain constraints is what the user
wants to do. If those constraints involve QoS, and if he/she wants to
engineer the traffic across multiple platforms, than these constraints
cannot be internal (yes, I know QoS behavior is something vendors do
differently - that's why you don't see a lot of QoS-TE these days...).
If those constraints involve available bandwidth for TE (which is NOT
related to QoS), and the user wants to engineer traffic across multiple
platforms, than vendors have to agree on how to advertise the values
needed as input for the computation - or else it will not generate
correct results. Then, if some vendor wants to allocate RSVP traffic to
queue #5 with high-drop-probability etc. that's their business...

The point is this: *engineering* traffic needs to be based on some
inputs - those have to be set the same in a multi-vendor environment,
whether Diffserv or not. Don't you agree?

--
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: Monday, July 23, 2001 4:19 PM
> To: Amir Hermelin
> Cc: TE-wg (E-mail)
> Subject: RE: I-D ACTION:draft-kompella-tewg-bw-acct-00.txt
> 
> 
> 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
> > > 
> > > 
> > 
> > 
>