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

["Walter Weiss" <w.weiss@attbi.com>]

John,

Sorry for the late reply. I missed your posting.

Comments follow inline.

regards,

-Walter

----------
[snip]
> 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.
>
I can't speak for others but the capabilities aspects of COPS-PR have always
troubled me although for slightly different reasons. It is my view that
capabilities are abstractions of implementations. However, it is difficult
to decide where to stop. It is fine to say that a router supports
classification. But it is not that simple. A policy server (and I use the
term very loosely :) would also like to know how many classifiers, whether
ranges or lists are supported, and where classifiers can be placed in a
datapath. There is far more complexity in representing capabilities than it
appears. Therefore, my view of capabilities is that it is a convenient
mechanism not for identifying the implementation, but for defining the
hardware and software versioning that allows a policy server to implicitly
know what configuration will and won't work.

> 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.
>
Since policies within the context of COPS-PR are specific to a given device,
clearly the implication that COPS-PR provides network level policy
functionality is erroneous.

> 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.
>
Given the scope of application I am offering (binding of edge resource
consumers to specific services), I would suggest that core operators would
be unaffected and unaware of these configurations.

> Response to particular points:
>
> At 04:50 PM 3/26/2002, Walter Weiss wrote:
[snip]
> >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?
>
We had private discussions along similar lines at the last IETF meeting. The
challenge has always been that the RADIUS protocol has serious limitations
in it's ability to support edge provisioning issues (security, QoS, Tunnels,
etc.) Conversely, COPS PIBs, while offering more sophisticated provisioning
capabilities have not adequately addressed the authentication and access
management issues. The AccessBind PIB makes some strides towards addressing
this, but it is by no means comprehensive.

> >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.
>
It already has. There is just no standard for it. There are lots of devices
(CMTSes, GGSNs, and BRAS products) that are using COPS, SNMP, and RADIUS in
proprietary ways to support the functionality I have described. The 3GPP
have agreed on COPS-PR because they have this very need. This is not about
whether the category exists but what the IETF will do (if anything) to
provide a standard for supporting it.

> >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?
>
I actually favor incremental models over comprehensive models. Comprehensive
models are really complicated and have to consider many factors. Data models
(MIBs, PIBs, MOFs, Schemas, etc.) represent behavioral interfaces. If the
behavioral requirements are different for different parts of the network,
different technologies, and different implementations, the model quickly
turns into an excercise in boiling the ocean. My point was that the MIB and
PIB were conceived to address provisioning of the core of the DiffServ
network. Given the clear domination of CLI in this space, the model is not
ideally suited for edge config either.

> >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?
>
Correct.

> >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.
>
Yes and in that same discussion, it was also agreed that if PIBs were put on
an experimental track, SNMPCONF MIBs would also be put on a experimental
track. As long as we consider the larger question (config) rather than
looking at a specific instance of the question (PIBs) I am fine with any
answer. For me at least, the question is not what should be done with PIBs,
but what should be done with config in general. When we have answered the
second question the first one becomes easy. In the mean time all config
related standards (Policy Framework, writable MIBs, and PIBs) should be
treated consistently until we sort out the first question.

> >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".

I believe Randy at least is still considering his position on this. However,
Bert should be able to offer a pretty clear position on whether he is in
favor of Experimental or Informational (which to me amounts to blocked
advancement).