Re: why i should like pibs

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

Bert,

This is a thoughtful and rational justification to your position. If I may
paraphrase, your primary concerns are:
1. That the level of interest in this new approach is currently low.
2. That the value is low given the overlap with MIBs.
3. That the incremental cost of developing PIBs for all areas in the IETF is
huge.

Let's consider this from the operations perspective. First of all, the
pervasive perspective that there is only one operations organization is very
misleading. In fact, most providers have multiple operations organizations.
One organization may be responsible for a given backbone while other
organizations within the same provider are responsible for specific
businesses (some regulated and some not), and business models. In many
cases, there are even multiple backbone organizations. These organizations
all have different needs and some are grossly under-represented in our
discussions. In my opinion, this is primarily because many are interested in
service deployments/revenue generation and less interested in low level
transport issues. This perspective has been reinforced by a variety of
discussions I have had with several Tier 1 providers. Hence, a true
understanding of operational needs is far beyond our grasp because we don't
have a statistically significant sample or a true understanding of actual
operational models. Therefore, drawing conclusions about the value of COPS
or PIBS to operators is premature. That said, I would like commend both Bert
and Randy for the initiative they have shown in trying to better understand
operational environments and requirements.

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.

Stats Collection has the following characteristics. It is non-real-time, it
consumes lots of bandwidth, and it is not transactional. They are more
suitable to a protocol like TCP that is sensative to congestion control,
which explains why stats are often sent with FTP rather than SNMP.

Events are real time, small and infrequent messages and non-transactional.
They require guaranteed delivery irrespective of network congestion or loss.
This application is ideally suited to the capabilities of SNMP, which is why
it is so broadly deployed for this purpose.

Static config is performed in the core of networks where network stability
is critical. This means infrequent changes and the changes that are made are
typically at the transport level (links, routes, route policies, and
filters). Static config messages require transactional and non-real time
messaging. The configurations are complicated. CLI is prefered over SNMP
because the language is simpler than attribute level pokes, because textual
is not significantly more overhead than binary and because the language
provides an abstraction.

Dynamic config occurs and the edges and focuses exclusively on dynamic
service deployment. It requires frequent updates. In some cases frequent
means every time a user logs in, in other cases it means when a VPN is bound
to a new user, and in other cases every time a service is activated (a
telephone call is made). In this environment, which not adequately addressed
with current technologies, config changes must be performed quickly to
accommodate systems or users waiting for authorization (login, call setup
delay, etc.) Further, because the configurations are relatively complex,
they need large multi-packet messaging and transactional capabilities.
Finally, because most service changes are transitory (when the call
completes, the configs should be uninstalled), a mechanism that simplifies
this process is ideal. IMO, given the requirements, COPS-PR is the optimal
choice amongst the available alternatives. However, I do not believe it is a
suitable technology for the other three operational issues.

Given the diverse requirements for each aspect of NM, I would suggest that
there is no silver bullet here. No single protocol, transport, or language
can viably meet all the requirements of every aspect of NM.

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.
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.
Given the unique applicability of COPS-PR, PIBs should be defined
specifically for this purpose and only this purpose. 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.

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. It also does nothing about the overall progress in the O&M area
that Juergen alluded to. This was in essence the point I was trying to make
in my earlier message to Randy.

regards,

-Walter


> -----Original Message-----
> From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
> Sent: Thursday, March 21, 2002 4:13 PM
> To: rap@ops.ietf.org
> Cc: diffserv@ietf.org; ipsec-policy@vpnc.org
> Subject: RE: why i should like pibs
>
>
> All,
>
> Let me post to these lists a similar statement as I made in the
> RAP WG meeting at this 53rd IETF, so that everyone has the same
> info. Here we go. I would prefer to have andy reactions (if any)
> posted to just one mailing list (the RAP wg mailing list).
>
> When the WG completed WG Last Call and reached consensus on
> the FRAMEWORK PIB, the WG chairs asked me (the primary AD
> for the WG) to consider this document for Proposed Standard.
> Normally I then review and ask for IETF wide Last Call and
> if no valid objections are received, then I put the document
> on the IESG agenda for approval.
>
> My current evaluation however for this document at this time
> is as follows:
> - If we look at the NM related activities, then we can see
>   that for SNMP/MIBs, the majority of work/time/effort is
>   spent in the MIB development. It also touches on virtually
>   all WGs. Same will be true for COPS-PR/PIBs if we start to
>   put PIBs on the standareds track.
>   This could be a VERY BIG thing. In SNMP, the real investment
>   is in MIBs. This is true for MIB design (IETF), for vendor
>   implementation effort, and for user deployment. If IETF
>   working groups start to develop PIBs they would be faced
>   with significant extra, and in many cases, redundant effort
> - We have accepted COPS and COPS-PR 2-3 years ago as PS.
>   That was the start of a duplicate approach, which only
>   provides marginal improvement in some areas, and possibly
>   a negative effect in some other areas.
> - We have also accepted SPPI as a duplicate approach, again
>   with only marginal improvement. It allows to define PIBs,
>   most of which I think can also be done with MIBs or
>   better/different MIB design.
> - Note that PIBs are basically intended for configuring
>   network devices and services.
> - Two years back, the ADs and Diffserv WG chairs agreed to do
>   a MIB and a PIB for standards track. And we agreed with the
>   RAP WG to develop a set of base PIBs for standards track.
> - Meanwhile, we have seen:
>   - Some key players withdrew from COPS and PIBs approach
>     They claim there is no market, and with reduced budgets
>     there is no place to just do multiple solutions to same
>     address space.
>   - In most cases, PIB development is done by different people
>     than MIB development, if we're lucky they talk to each other.
>   - WGs in general have very little interest in MIBs or in PIBs,
>     let alone both.
>   - Operators (ISPs) tell us they do not see much use for binary
>     interfaces (be it SNMP/MIBs or COPS-PR/PIBs or other) to
>     configure their network devices/services. The reality is that
>     they use (and expect to have to continue to use) ASCII based
>     CLI-type interfaces (Maybe ASCII should read human readable)
>   - We have started an effort to try and consolidate SMI and SPPI
>     We may want to await the results before we invest in the
>     standardization of PIBs.
>   - The NM community in the IETF (lots of SNMP folk, but COPS,
>     Policy WG and Operators are participating too) are trying to
>     come up with some vision/framework to address Operator (ISP)
>     concerns. Discussions is only in beginning stages and not any
>     IETF sanctioned status yet.
>   - IAB is planning a NM Architecture Workshop this summer (as
>     announced at the IAB plenary on Wednesday March 20th)
> - We (the IETF/IESG) are to decide on the first IETF produced PIBs.
>   If we approve them as standards track, then:
>   - I suspect we will find a lot of duplicate work, i.e. MIBs and
>     PIBs, to be designed, tested, handled-for-stds-track approval
>   - Vendors and users may be faced with the big duplicate investment.
>     They can opt to not do so, but of course the more PIBs we approve
>     as stds track, the more the pressure will be put on them.
>   - We are telling the market that we cannot decide and let them do it.
>     Maybe this is OK. But not in my mind, I do not think we do the
>     IETF community or the world a favor by approving this duplicate
>     approach
>
> As a result, I cannot propose to the ISG to approve the FRMAEWORK-PIB
> (or any PIBs for that matter) on the standards track at this point
> in time. I strongly recommend to publish them as Informational for
> now. We can revisit this after we get some better architectural
> guidelines/help from the current actitivities that are taking
> place in informal gatherings and the upcoming IAB NM Workshop.
>
> I understand that this is sort of "breaking the contract" with
> the RAP WG on my part. But the situation has changed quite a bit
> from 2 years ago when we started down this path (agreed on the WG
> charter).
>
> Bert
>