Subject: RE: [Diffserv] ifSpeed with DiffServ PIB and Framework PIB [Previ ously Re: draft-ietf-rap-frameworkpib-06]

From: Kwok Ho Chan <[email-masked]>
Date: Mon, 04 Feb 2002 11:35:28 -0500

Bert:
Please see response inline.
-- Kwok --

At 11:54 AM 2/4/02 +0100, Wijnen, Bert (Bert) wrote:
>Kwok writes:
> >
> > 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.
> >
>So to me that sounds as "duplicating" information.
>How does this new field get filled out by the PEP?

The "ifSpeed" being discussed is the information required for the PDP
to formulate the correct scheduling policy parameters based on network
wide policies.  May be we should not use the term "ifSpeed" and allow
the scheduling policy parameter be not tightly coupled to interface.
This field should be filled out by the PEP as it sees what it needs to be
controlled by policy, and this is not necessarily an interface.

>What if that field conflicts with ifSpeed?

The scheduling policy parameter here may be totally different from
ifSpeed in the IF-MIB.  So I don't think the notion of conflict exists.

>Would any network device not have the IF-MIB implemented anyway,
>so the fact that you remove the dependency from the PIB, does not
>mean that the IF-MIB does not have to be implemented in the device,
>does it?

The removal of this dependency from the PIB does not say anything about
implementation of the IF-MIB at all.  It is up to the implementation what it
wants/needs to do.

>Bert

_______________________________________________
diffserv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html

---

From: "Andrew Smith" <[email-masked]>
Date: Mon, 4 Feb 2002 10:30:40 -0800

I think you're all missing the point here. The relationship between the
"xxxRel" and the "xxxAbs" objects in the Diffserv PIB is just the same as in
the Diffserv MIB:

RateRel = [ (RateAbs * 1000) / ifSpeed ] * 10000

The reason that both objects are present is that sometime you want to set a
configuration based on an absolute bandwidth (e.g. 1 Mbps), sometimes you
want to set it based on a fraction of the link's bandwidth (e.g. 20% of line
rate). In order to allow people to use either type of "policy", we
duplicated the object and had the two incarnations of it linked by the above
equation (it's a clumsy solution but it seemed like the best we could do
given the languages we have for describing the semantics of objects in SMI
or SPPI).

The manager (or PDP) only has to set one of the two objects and, therefore,
does not need to know the ifSpeed if it sets the "xxxRel" object. If it sets
the "xxxAbs" object then it probably should have some way of knowing, a
priori, what speed each interface covered by a RoleCombination can handle -
I'd suggest that the ifTable is a good way of discovering this information
ahead of time, through SNMP probably. [There's a larger issue too: what is
the defined behaviour when one or more members of a RoleCombination cannot
support a given policy rule (e.g. manager tries to set a 10Mbps RateAbs
policy on a 2Mbps interface?]

So I'd object to Kwok's proposed change.

Andrew Smith

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Kwok Ho Chan
Sent: Monday, February 04, 2002 8:35 AM
To: Wijnen, Bert (Bert)
Cc: Kwok-Ho Chan; [email-masked]; [email-masked];
[email-masked]; [email-masked];
[email-masked]; [email-masked];
[email-masked]
Subject: RE: [Diffserv] ifSpeed with DiffServ PIB and Framework PIB
[Previ ously Re: draft-ietf-rap-frameworkpib-06]

Bert:

---

From: "Andrew Smith" <[email-masked]>
Date: Mon, 4 Feb 2002 15:44:04 -0800

Kwok wrote:
> But the policy does not always have to be
> associated to an interface, and that is where ifTable will not come into
play.
> And that is why we may only want to indicate the capability as a "sink"
> or "drain" rate out of a scheduler data path element.  Also even when only
> "xxxRel" is used, the PDP may still want to know the "xxxAbs" numbers
> to make sure a specific service is supported with the policy.

That's a whole different issue to that which Saurabh brought up. In the
Diffserv Management Model, all scheduler data path elements are associated
with a particular interface. It seems like you are describing a policy that
is formulated without reference to a specific interface but which will,
eventually, be applied to a set of interfaces (ideas like "bandwidth" and
"rate" are meaningless **until they are applied to an interface**, or
something physical like that). The value of "ifSpeed" to be used in the
equation is only relevant when the policy is actually applied to the set of
interfaces and, as you pointed out, a different value of ifSpeed may be used
for each interface instance in the set: you can only read back the set of
different ifSpeed values if you index the "read requests" by interface
number (sounds like an SNMP GET operation to me).

I don't understand your last sentence above: by definition, a PDP "knows the
xxxAbs numbers" - at least in the COPS model, PDPs know all the rules that
have been installed in a PEP. In this case the xxxAbs value will be either
(a) "don't care" for rules that were installed with a xxxRel value or (b)
the value that the PDP already installed for rules that were installed with
a xxxAbs value. A "policy install" operation often contains a bunch of
wildcards: one policy might choose a "RateAbs" value with "RateRel" as a
don't care. Another policy might choose the opposite. Another policy might
use just a scheduling-priority value and have both RateRel and RateAbs as
don't cares.

I guess the general issue is that you cannot always usefully do a "read
request" indexed by something abstract like policy-ID on objects that only
have relevance at the physical instance level - I am assuming that by "PDP
may still want to know" you are implying some such read request issued by
the PDP of the PEP. I'm not sure what COPS-PR protocol has to say about
this - perhaps it should say something. It's just as much an "snmpconf WG"
or "policy WG" issue as a "rap WG" one though (although it's not, I believe,
a "diffserv WG" thing, assuming we don't make any changes to the PIB in
question).

Andrew Smith

-----Original Message-----
From: Kwok Ho Chan [mailto:[email-masked]]
Sent: Monday, February 04, 2002 1:21 PM
To: Andrew Smith
Cc: Kwok-Ho Chan; Wijnen, Bert (Bert); [email-masked];
[email-masked]; [email-masked];
[email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: RE: [Diffserv] ifSpeed with DiffServ PIB and Framework PIB
[Previ ously Re: draft-ietf-rap-frameworkpib-06]

Andrew:
Thanks for the clarification,
Please see response inline.
-- Kwok --

>priori, what speed each interface covered by a RoleCombination can handle -

The above have not changed.  But the policy does not always have to be
associated to an interface, and that is where ifTable will not come into
play.
And that is why we may only want to indicate the capability as a "sink"
or "drain" rate out of a scheduler data path element.  Also even when only
"xxxRel" is used, the PDP may still want to know the "xxxAbs" numbers
to make sure a specific service is supported with the policy.

>ahead of time, through SNMP probably.

Notice my reply to Bert is this change does not say anything about
implementation and usage of ifTable.
If policy is associated with an interface, there may be an association.
But we may not want to have such a limitation from the policy sense.

>  [There's a larger issue too: what is
>Archive:
>http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h
tml

---

From: Kwok Ho Chan <[email-masked]>
Date: Mon, 04 Feb 2002 16:21:22 -0500

Andrew:

associated to an interface, and that is where ifTable will not come into play.

>http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html