Subject: Re: Requirements Document - Capabilities Model

From: "Durham, David" <[email-masked]>
Date: Tue, 11 Jun 2002 09:06:35 -0700

I agree with Joel that the DiffServ MIB has no capabilities model, it is
primarily state. Nevertheless, the DiffServ PIB together with the Framework
PIB actually have a very complete capabilities model. They describe
everything from what data structures the device can understand, to what
values it supports, it even lets you specify how to configure the state on
the device itself.

-Dave

> -----Original Message-----
> From: Olivier Marce [mailto:[email-masked]]
> Sent: Tuesday, June 11, 2002 4:10 AM
> To: [email-masked]
> Subject: Re: Requirements Document - Capabilities Model
>
>
> Hi Joel
>
> "Joel M. Halpern" wrote:
>
> > The DiffServ conceptual model (and MIB / PIB) which have
> been mentioned as
> > starting points for the capabilities model are actually
> state models, not
> > capabilities models.  There is no way to tell from these
> models how many
> > filters a device can handle, or whether it is capable of
> > metering.  However, you can tell at any given time exactly
> what filters it
> > has, how they connect to markers, meters, queues, etc.
> When you want to
> > configure additional processing elements into the
> processing path, you
> > reference the elements of this model.
> >
>
> What's about the section 1.2 of RFC3084 ?
> "   When a device boots, it opens a COPS connection to its Primary
>    PDP.  When the connection is established, the PEP sends information
>    about itself to the PDP in the form of a configuration request.
>    This information includes client specific information (e.g.,
>    hardware type, software release, configuration information)."
>
> Ins't it an sufficient capabilities description step ?
>
>
> --
> Olivier Marce (ARX Project/Active Network WP)
> Alcatel R&I Dept                        Tel: +33 (0) 1 69 63 41 67
> Route de Nozay                          Fax: +33 (0) 1 69 63 13 59
> F-91461 Marcoussis Cedex (France)
>

---

From: Olivier Marce <[email-masked]>
Date: Wed, 12 Jun 2002 10:17:04 +0200

> values it supports, it even lets you specify how to configure the state on

With this in mind, what's about considering COPS + Framework PIB as a candidate
to FORCES ?

---

From: avri <[email-masked]>
Date: Wed, 12 Jun 2002 14:35:23 +0200

> With this in mind, what's about considering COPS + Framework PIB as a candidate

in many respects this is an excellent suggestion. from the
beginning i have thought that cops could well be part of the
solution. though it would take creating a specific info model/PIB
for ForCES in addition to use of other existing PIBs.

with the rumors that fly, however, about the continued acceptance
of COPS, is this considered a 'safe' candidate?
every time i suggest a cops based solution to someone, they tell
me it is dead (after suppressing giggles at my naiveté).

are companies actually building and _selling_ COPS engines?

the reason i ask is getting the info model and PIB done is a
significant task, and if COPS is not not really real, then the
effort may be better spent elsewhere.

a.

(a proposer of cops based solutions and co-author of a pib who 
despairs of ever seeing really real implementations)

-- 
Mobile: +46 73 029 8019
Office: +46 920 49 3030
In US:  +1 401 663 5024

http://homepage.bethepeople.com/mphp/VXEU-2002/avri

---

From: Jamal Hadi Salim <[email-masked]>
Date: Thu, 13 Jun 2002 06:41:54 -0400

On Wednesday 12 June 2002 08:35, avri wrote:
> Olivier Marce wrote:
> > With this in mind, what's about considering COPS + Framework PIB as a
> > candidate to FORCES ?
>

Which is one of the reasons why COPS is a bad choice.
Out of curiosity, why COPS say in a local scope. Think of a very simple setup 
with a controller and the FEs sitting in the same chasis. Why not SNMP for 
example? 

cheers,
jamal

---

From: avri <[email-masked]>
Date: Thu, 13 Jun 2002 19:15:03 +0200

> with a controller and the FEs sitting in the same chasis. Why not SNMP for

SNMP? Have you looked at how hard and complicated it is to even
configure an MPLS label swtich with MIBS? ForCES seems like it
would be even more difficult.

Plus the info model for a MIB is pretty much the same level of
difficulty as one for a PIB. As is translation into the Info Base.

a.

--
Mobile: +46 73 029 8019
Office: +46 920 49 3030
In US:  +1 401 663 5024

---

From: Jamal Hadi Salim <[email-masked]>
Date: Thu, 13 Jun 2002 09:50:21 -0400

On Thursday 13 June 2002 13:15, avri wrote:
> > Out of curiosity, why COPS say in a local scope. Think of a very simple
> > setup with a controller and the FEs sitting in the same chasis. Why not
> > SNMP for example?
>

I was just being a devils advocate ;-> 

> difficulty as one for a PIB. As is translation into the Info Base.

snacc compiles both PIBs and MIBS.
The main positive both COPS and SNMP have is that they are widely used ;->
Some people tend to have emotional attachments to things that they are
comfortable with.
I am not a fan of either COPS or SNMP.  I think the protocol should include
good built in event management and reporting, one-to-many communication, and
easy to extend models.

cheers,
jamal

---

From: Alistair Munro <[email-masked]>
Date: Fri, 14 Jun 2002 08:03:27 +0100

Hi All,

I'm glad that the suggestion of SNMP is not intended to be serious.

I have had the dubious pleasure of working on element management using
SNMP (vanilla V.2). It failed mainly because the semantics of a MIB is
too poorly defined. To allow implementers to build agents that behave
consistently from product to product (even from the same vendor) you
have to build a model of the FE at a very detailed semantic level, which
is seldom done. Also the FE model diverges so widely from the
operational situation in which a FE is being used that it is difficult
to build an efficient control/configuring client protocol on SNMP.
Finally, although it has improved significantly, SNMP is still
fundamentally unsuitable as a protocol for a long-lived controlling
relationship (i.e. writing lots of data to many FEs).

I have the same reservations about using other existing protocols by
imposing alternative semantics on the content of their PDUs. A protocol
is designed for a specific purpose and should be used only for that
purpose.

The MIDCOM group appears to be asking a similar question. However,
everybody seems to have a different view of what a middlebox is and does
(i.e. anything and everything), so (IMO) it's never going to go anywhere
until answers this question first.

Regards,

Alistair

--
Dr. Alistair Munro,
Chief Systems Engineer, Degree2 Innovations Ltd.
Regus House, 1 Friary, Temple Quay, Bristol, BS1 6EA, U.K.
E-mail: [email-masked]
Tel: (work) +44-117-900-8114, (home) +44-1275-462707, (mobile)
+44-7974-922-442;
Fax: +44-117-900-8151
Web: http://www.u4eagroup.com

> From: Forwarding and Control Element Separation
> [mailto:[email-masked]] On Behalf Of Jamal Hadi Salim
> Sent: 13 June 2002 14:50
> > > Out of curiosity, why COPS say in a local scope. Think of a very
> > > simple setup with a controller and the FEs sitting in the same
> > > chasis. Why not SNMP for example?
> >
> > configure an MPLS label swtich with MIBS? ForCES seems like
> it would
> > be even more difficult.
> >
>
> The main positive both COPS and SNMP have is that they are
> widely used ;-> Some people tend to have emotional
> attachments to things that they are comfortable with. I am
> not a fan of either COPS or SNMP.  I think the protocol
> should include good built in event management and reporting,
> one-to-many communication, and easy to extend models.
>
> cheers,
> jamal
>
>
>
> > a.
> >
> >
> > --
> > Mobile: +46 73 029 8019
> > Office: +46 920 49 3030
> > In US:  +1 401 663 5024
> >