Re: [Diffserv] Re: why i should like pibs

[John Schnizlein <jschnizl@cisco.com>]

[ post by non-subscriber ]

It seems time again for me to summarize my concern about COPS-PR
and PIBs. The intensity of feeling, apparent in the Plenary, that 
the ADs have done other than what we expect of them both motivates 
me to repeat what was ignored some time ago in Policy Framework
interim meetings and makes me recall that the little boy who said 
what he saw in the Emperor's New Clothes" fared poorly.

The fundamental problem with distributing policy to traffic-forwarding
devices rather than translating policy into configurations under the
constraints of the composition (topology) and capabilities of the
devices in the path of the traffic remains. It is essentially wishful
thinking that individual devices can determine the correct configuration
of their local parameters without the domain-wide information. I have
not been persuaded that the capability-exchange between the PEP and PDP
solves this problem. There are hints of importance of the domain-wide 
context in DiffServ's per-domain behavior (PDB) specifications.

It is even a mistake IMHO to invite network administrators to establish
policies their networks cannot deliver. Although consensus was never
reached on the architecture for policy networking, the insistence that
policy be independent of the devices and topology that started there 
seems to persist under the surface of the COPS-PR development.

My concerns about distributing un-interpreted policy appears to be
shared by the network operators who shared their view with people
soliciting "requirements for network configuration" when they say 
they do not want policy, or even configuration, distributed to devices
until they know what it will do to the network.

Response to particular points:

At 04:50 PM 3/26/2002, Walter Weiss wrote:
>... First of all, the pervasive perspective that there is only one 
>operations organization is very misleading. ... Therefore, drawing 
>conclusions about the value of COPS or PIBS to operators is premature. 

Good point. Standardizing without expected value is not the IETF way.

>I would also like to consider this issue from a requirements perspective. In
>my view, we can divide operational needs into four areas: Stats Collection,
>Events, Static config and Dynamic config.

This taxonomy of operational needs for network management is novel.
Instead of the 5 FCAPS categories, it creates 4, with a new distinction
in configuration that may or may not have value. It also seems that
this Dynamic Config has a lot in common with what has been supported in 
RADIUS as user profiles. Why is this not better treated as a QoS case
of authorization? 

>I would also like to reconsider Bert's points. First, I would agree that the
>level of interest in COPS-PR is relatively small. However, I would argue
>that this is because Dynamic Config is only starting to become important as
>mappings for QoS, Security, and Tunneling are coming to the forefront.

Maybe we should see if this new category of Dynamic Config really develops
before standardizing it into existence.

>Second, I disagree that there is overlap with PIBs. While the DiffServ PIB
>and MIB are nearly identical, this was done because it was assumed that they
>were both addressing the config space that CLI is so clearly dominating. In
>the absense of a common model for all config, I believe this was a mistake.

Don't follow this. You think any correspondence in the data models for the 
DiffServ application is a mistake without a "common model for all config"?
Wouldn't incremental steps be more practical?

>Given the unique applicability of COPS-PR, PIBs should be defined
>specifically for this purpose and only this purpose. 

Which unique applicability of COPS-PR is this? The newly proposed
Dynamic Config?

>On Bert's third point,
>I would argue that the investment in PIBs is far smaller than he suggests.
>Given the specific scope of applicability, PIBs would not be appropriate for
>most IETF activities involving failure events or static config (routing,
>transport and applications). Hence, the number of PIBs is relatively small.
>Further, I do not believe that any of the alternatives on the table can meet
>these requirements to the extent that COPS-PR can.
>
>I would agree with Juergen that what we have today is a hodge-podge of
>protocols and mechanisms for configuration management and little incentive
>for changing the situation. As such, I see two alternatives:
>1. We can use COPS-PR and restrict it specifically to the area that it
>addresses most effectively: dynamic config management (at the network edge).
>2. We can block progress on all config drafts/standards to motivate a
>solution to Juergen's larger issue of concerted participation in a single
>and uniform set of standards.

No one has proposed to "block progress on all config drafts/standards"
up until this point. Way back in the Configuration Management BOF in
Washington, I thought Bert supported Experimental status as the best
way to explore the new ideas proposed with COPS-PR and PIBs.

>We could also block the advancement of COPS-PR. However, that prevents us
>from addressing the dynamic config space and does not advance an
>alternative. 

Bert's original suggestion of Experimental seems again the best way to
encourage use of the new ideas in COPS-PR. I have never seen him (or
Randy, for that matter) try to "block advancement".

John