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

[Kwok Ho Chan <khchan@NortelNetworks.com>]

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

At 10:30 AM 2/4/02 -0800, Andrew Smith wrote:
>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 -

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.

>I'd suggest that the ifTable is a good way of discovering this information
>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
>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: owner-rap@ops.ietf.org [mailto:owner-rap@ops.ietf.org]On Behalf Of
>Kwok Ho Chan
>Sent: Monday, February 04, 2002 8:35 AM
>To: Wijnen, Bert (Bert)
>Cc: Kwok-Ho Chan; rap@ops.ietf.org; diffserv@ietf.org;
>saurabh.kapoor@wipro.com; srinivasu.nampelli@wipro.com;
>ravi.attili@wipro.com; naganna.vydyula@wipro.com;
>krishna.akkineni@wipro.com
>Subject: RE: [Diffserv] ifSpeed with DiffServ PIB and Framework PIB
>[Previ ously Re: draft-ietf-rap-frameworkpib-06]
>
>
>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
>diffserv@ietf.org
>https://www1.ietf.org/mailman/listinfo/diffserv
>Archive: 
>http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html