Subject: Re: draft-ietf-rap-frameworkpib-06

From: Kwok Ho Chan <[email-masked]>
Date: Fri, 01 Feb 2002 18:18:23 -0500

Saurabh:
Sorry for not responding to this earlier.
Currently the "ifSpeed" refers to the interface speed provided by
the MIB's ifTable in RFC 2863.
Design of the DiffServ PIB is to be Role Combination specific and not
interface specific.  We also didn't want to pull in the MIB's ifTable into
a PIB as there are many proprietary extensions to the ifTable already.
Another point is that we can add this as part of the capabilities for
a specific Role Combination, but we may want to have a single Role
Combination containing interfaces of more than one interface speed.

I would like to leave it the way it is and just use the ifSpeed from the 
MIB's ifTable.
Let the DiffServ PIB get to Proposed Standard RFC.
Get more implementation experience to determine what is the right thing to do
before modifying it, as there are other things we will learn from more
implementation experience.

-- Kwok --

At 06:21 PM 1/2/02 +0530, [email-masked] wrote:
>     The qosAssuredRateAbs parameter of the qosAssuredRate table specifies
>the minimum absolute rate, in kbps that a downstream scheduler element
>should allocate to the queue.
>This attributes value is coupled to that of qosAssuredRateRel : changes to
>one will affect the value of other. They are related to each other by the
>equation :
>RateRel = [ (RateAbs * 1000) / ifSpeed ] * 10000
>
>My question is how does the PDP get the value of 'ifSpeed'? Does the PEP
>specify the value? If yes, then in which PIb is the value found ?
>
>Regards,
>Saurabh Kapoor
>----------------------------------------------------------------------------
>----------
>
>
>

---

From: Kwok Ho Chan <[email-masked]>
Date: Sun, 03 Feb 2002 09:55:57 -0500

An alternative to the treatment of ifSpeed by the DiffServ PIB is to add
an attribute qosIfSchedulerCapsIfSpeed to qosIfSchedulerCapsEntry
to indicate the bit rate that can "sink" the output of the Scheduler
Data Path Element.  This will allow the DiffServ PIB to not rely on the
Interface MIB.

The above alternative is possible because the Framework PIB now
allows multiple interface capability sets belonging to the same Role
Combination, hence policies belonging to the same Role Combination
can be used for interfaces with different interface capability sets
(different interface speeds).

I have also put this on the diffserv mailing list as this need to be decided
with the DiffServ WG.
I can change this in the DiffServ PIB-06 I am submitting.
Notice DiffServ PIB-05 have already passed WG Last Call,
so this will be a minor change after WG Last Call before IESG Review.

-- Kwok --