Subject: [Diffserv] RE: why i should like pibs

From: "Weiss, Walter" <[email-masked]>
Date: Mon, 18 Mar 2002 14:45:06 -0500

Randy,

I have two responses.

1. Political:
Why are you asking? Why do you keep asking? And more importantly why, based
on your criteria, haven't you asked for every non-monitoring MIB, or for
various other works such as Policy Framework. I don't mind if we want to
have a substantive discussion around the evolution of configuration
management if you applied your own metrics consistently. If you believe that
none of these technologies meet's your requirements, then freeze them all.
At least then there will be some pressure on all the parties to converge to
a common approach. Personally, I believe your question is a waste of time
since the existing IETF process addresses your question when there is
sufficient implementation to transition standards from proposed standards to
draft standards. Certainly there have been lot's of standards that have
never made it past proposed for the very reasons you describe.

2. Technical:
Given your role, I would not expect you to use this PIB. The very argument
justifying DiffServ is the same one that Operators use to manage their
networks. Both share the goal of making the core of the network static and
stupid (minimal configuration). By recognizing that the core should be kept
as simple as possible, we also all understand that removing complexity from
the core only moves the complexity to some other location: the edge. If the
edge must configure bindings of QoS, Security, Access Control, Tunneling,
Usage Accounting, etc, this drives specific requirements that COPS-PR comes
closest to meeting. I could go into all the details here, but given that
this thread inevitably de-evolves to the usual suspects and the usual
posturing, I have serious doubts about the value of going into any more
details.

regards,

-Walter

> -----Original Message-----
> From: Randy Bush [mailto:[email-masked]]
> Sent: Monday, March 18, 2002 9:13 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: why i should like pibs
> 
> 
> wearing my iesg hat but being just a stupid operator, i am trying to
> understand the pib/mib controversy.  fyi, i currently use snmp heavily
> for monitoring devices on my network.  i configure using 
> large db-driven
> code and spew text-based cli to the devices.
> 
> let's assume i want to take the leap to a binary, as opposed 
> to textual,
> configuration language.  i.e. for some reason(s) [which we will PLEASE
> NOT discuss here] i decide to move from pushing text-based cli configs
> out to pushing a binary format.
> 
> hence, i would have to push my vendors to implement snmp/cops 
> writes for
> all configuration aspects of all devices.  this would be big cost for
> both me and for my vendors.
> 
> why would cops/pibs be significantly better (remember it has 
> to replace
> my current investment, so it can not be 'just as good') than 
> snmp/mibs?
> 
> randy
> 
> 

_______________________________________________
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: "Bokaemper, Martin" <[email-masked]>
Date: Mon, 18 Mar 2002 16:03:02 -0500

> wearing my iesg hat but being just a stupid operator, i am 
> trying to understand the pib/mib controversy.  
> fyi, i currently use snmp heavily for monitoring devices 
> on my network.  i configure using large db-driven code 
> and spew text-based cli to the devices.
[...]
> to replace my current investment, so it can not be 'just as 
> good') than snmp/mibs?

In my view COPS and PIBs don't provide very significant 
advantages for the generic configuration of the whole device.

The main advantage of COPS is the state keeping capability - 
the PDP can make 'immediate' decisions based on the up-to-date 
knowledge of the PEPs state.   This is obviously useful for 
COPS/RSVP and the outsourcing model, but also applies to COPS-PR.

Up-to-date state and immediate provisioning is required 
for some applications that usually only affect small parts 
of a devices configuration. The rest of the configuration is 
(mostly) static and COPS offers little advantages there.

For the static configuration, something built on top of the 
OPS-NM work seems to be the most promising path to me.

Martin.
--

---

From: "Yavatkar, Raj" <[email-masked]>
Date: Mon, 18 Mar 2002 16:38:51 -0800

Brian:

This work got chartered more than two years back. The technical issue you
list was discussed at the beginning when existing alternatives had to be
listed and proposed work had to be justified. I am sure IESG took a look at
this before chartering the work.

We had discussion on this topic many times before and as Walter says, it
goes down to same supsects with same posturing. The fact is that real
vendors with real products see the need for this work.

I wish all the discussions and posturing at IETF (especially by IESG
members) was purely technical -- we need to address somewhere how IESG works
and how a single individual or two can hold up the work by many others.

Raj

-----Original Message-----
From: Brian E Carpenter [mailto:[email-masked]]
Sent: Monday, March 18, 2002 3:00 PM
To: Yavatkar, Raj
Cc: 'Weiss, Walter'; 'Randy Bush'; [email-masked]; [email-masked];
[email-masked]
Subject: Re: [Diffserv] RE: why i should like pibs

Let's try to stick to technical issues please, at least if
you want to keep the diffserv list on this thread.

The technical issue is: does COPS-PR have *significant* technical
advantages over the existing alternatives, that would justify
the added mechanisms and complexity?

   Brian

"Yavatkar, Raj" wrote:
> 
> Hi Walter:
> 
> Thanks for a really nice summary. I continue to be amazed at how Randy is
> applying a set of inconsistent standards to this work vs other work being
> done. Rob Coltun put the current state of IETF well in his departing
message
> -- I was hoping that would wake up IESG to move away from such political
> shenanigans to getting work done especially when vendors with products or
> implementations are working towards standardization.
> 
> Raj
> 
> From: Weiss, Walter [mailto:[email-masked]]
> Sent: Monday, March 18, 2002 11:45 AM
> To: 'Randy Bush'; [email-masked]; [email-masked]
> Subject: [Diffserv] RE: why i should like pibs
> 
> Randy,
> 
> I have two responses.
> 
> 1. Political:

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

---

From: "Rawlins, Diana" <[email-masked]>
Date: Tue, 19 Mar 2002 17:11:54 +0000

I'm not wild about the binary either, but SMIv3 was chosen back in the days
when Moore's Law was just taking off. I think an xml based structure over a
reliable TLS or authenticated/encrypted counterpart would be great!
 
The advantage I get with a PIB is a COPS protocol. The protocol informs me
if my transaction succeeded, or not. It enforces a single connection between
the client-server so I know the origin of the updates and I get the nice
side-effect of concurrency control. It gives me a feedback mechanism on how
the policy is doing if I so desire it. 
 
-Diana

-----Original Message-----
From: Randy Bush [mailto:[email-masked]] 
Sent: Monday, March 18, 2002 8:13 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: why i should like pibs

wearing my iesg hat but being just a stupid operator, i am trying to
understand the pib/mib controversy.  fyi, i currently use snmp heavily
for monitoring devices on my network.  i configure using large db-driven
code and spew text-based cli to the devices.

let's assume i want to take the leap to a binary, as opposed to textual,
configuration language.  i.e. for some reason(s) [which we will PLEASE
NOT discuss here] i decide to move from pushing text-based cli configs
out to pushing a binary format.

hence, i would have to push my vendors to implement snmp/cops writes for
all configuration aspects of all devices.  this would be big cost for
both me and for my vendors.

why would cops/pibs be significantly better (remember it has to replace
my current investment, so it can not be 'just as good') than snmp/mibs?

randy

---

From: [email-masked]
Date: Tue, 19 Mar 2002 23:01:57 -0500

David Durham's list is comprehensive enough. How much more does IESG need? Since as many indicated that it is probably pointless to re-open all the discussions, why can't we just move the Framework and Diffserv PIBs to ps and let the market decide the usefulness of PIBs instead of trying to decide for the market? 

Man Li

-----Original Message-----
From: ext Randy Bush [mailto:[email-masked]]
Sent: March 18, 2002 09:13 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: why i should like pibs

randy

---

From: "Moisand, Jerome" <[email-masked]>
Date: Wed, 20 Mar 2002 08:53:30 -0500

Sounds to be the wise approach... Can't agree more.

Jerome Moisand
Unisphere Networks

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, March 19, 2002 11:02 PM
To: [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: why i should like pibs

David Durham's list is comprehensive enough. How much more does IESG need?
Since as many indicated that it is probably pointless to re-open all the
discussions, why can't we just move the Framework and Diffserv PIBs to ps
and let the market decide the usefulness of PIBs instead of trying to decide
for the market? 

Man Li

-----Original Message-----
From: ext Randy Bush [mailto:[email-masked]]
Sent: March 18, 2002 09:13 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: why i should like pibs

randy

======================================= 
This email message is for the sole use of the intended recipient (s) and may
contain confidential and privileged information, including without
limitation, Confidential and/or Proprietary Information belonging to
Unisphere Networks, Inc. Any unauthorized review, use, disclosure or
distribution is prohibited. If you are not the intended recipient, please
contact the sender by reply email and destroy all copies of the original
message.

---

From: Kwok Ho Chan <[email-masked]>
Date: Wed, 20 Mar 2002 15:20:09 -0500

Agreeing on the approach of progressing both draft-ietf-rap-frameworkpib
and draft-ietf-diffserv-pib as Proposed Standards.
And let the market decide.
-- Kwok --

---

From: "Sahita, Ravi" <[email-masked]>
Date: Thu, 21 Mar 2002 09:04:34 -0800

Juergen,

I've added some items in addition to what you've enumerated. 
Some of these are direct effects of the PIB data 
model, and some of them because of usage of the
data model with COPS-PR.

a. I think the PIB data model is better since:

a.1. Other additions which formalize Pointers, typed and
untyped, Tag-Groups and single-inheritance (via EXTENDS)
allow code generation by an algorithm to generate 
entire funtional PIB layers over COPS-PR, and make 
processing of PIB transactions and error handling easier.

a.2. PIB PRCs do not require some SMIv2 column attributes 
which are needed there due to multi-managers support, and 
hence do not have that complexity.

b. Reuse of 'all'(a special client-type) and other 
assigned client-type PIBs via Client-type infrastructure
that allows the work by a wg of subject-matter experts,
to be reused by another group that needs those entire
modules or specific PRCs defined within them.

c. Some of the advantages of the framework-pib (which
is specified as an 'all' client-type) and hence the
advantages are distributed to other PIBs also are:

c.1. Facility to report subject-matter specific 
capabilities and PRC and/or attribute level 
implementation limitations which allows the PDP to 
validate configuration for a device to be configured 
effectively and unambigously amongst heterogeneous 
devices to which that configuration applies. 

c.2. Facility to install multiple contexts of
device configuration (with one active configuration 
context) and the ability to switch between them with 
very small decisions. This helps in bulk configuration.

d. Ability to outsource requests or provision decisions 
using the same data model, which gives you more than
just yes/no answers for resource allocation.

e. Allows resource management interaction at a PDP which
may be managing multiple resources (or client-types)-which
gives one the facility to build a closed-feedback system
where one client-type interaction may cause a change in another
client-type. This bullet point talks to the state maintenance
point that many people mentioned.

These I think are in addition to what you and Dave have
mentioned.

Ravi

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]]
Sent: Thursday, March 21, 2002 2:30 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: why i should like pibs

I tried to incorporate Dave's feedback and here is my updated list of
the major technical contributions of COPS-PR over SNMP:

a) TCP transport for large transactions when the network is up and
   running.

b) Reduced OID overhead and less degrees of freedom to achieve the same
   thing.

c) Improved data definition language. (There is disagreement how much
   improvement there really is.)

d) State sharing and one manager assumption for a given set of instance 
   data.

e) Some failover support built into the protocol.

Dave, do you agree with this revised list?

/js

-- 
Juergen Schoenwaelder    <http://www.informatik.uni-osnabrueck.de/schoenw/>