Subject: Re: An oversimplified comment on protocols and operations

From: "Yang, Lily L" <[email-masked]>
Date: Tue, 4 Nov 2003 10:32:34 -0800

A somewhat related issue (or an instance of the general issue at hand): 
A few weeks back Joel brought up the issue on FE topology and how that should/could be discovered by CE. Joel suggested that FE connectivity with its neighbors (that is, info about how an FE is connected with other neighboring FEs) can be viewed as part of FE attributes, and hence part of FE model. So such connectivity can be queried by the CE via generic attribute query message in the ForCES protocol. The alternative would be to define FE topology specific query message in the ForCES protocol. 
Since this is one of the open issues on FE model team's open issue list, I just want to raise this again and see if indeed people agree that such FE connectivity info (local info from that FE's point of view) should be embedded in the information element carried by ForCES protocol so the base protocol doesn't need to deal with it directly and explicitly?

> -----Original Message-----
> From: Forwarding and Control Element Separation
> [mailto:[email-masked]]On Behalf Of Alistair Munro
> Sent: Tuesday, November 04, 2003 1:22 AM
> To: [email-masked]
> Subject: Re: An oversimplified comment on protocols and operations
> 
> 
> Hi All,
> 
> Based on Joel's observations and Jamal's comments on them:
> 
> > I will admit that both extreme approaches (and most midpoints) can
> > work.  One can suggest that this is a philosophical 
> difference.  But it
> > has practical implications in the protocol structuring.
> 
> I don't think it's a philosophical difference, more a real 
> practical one.
> There are many lessons - RPC, SNMP, IPFIX, MIDCOM,...
> 
> Generic create/add/get/set/query base functions tend to be 
> qualified by
> references to specifics: next-hop, rule, counter, etc. as well as
> per-transaction handles for LFB instances, resources and so on.
> 
> If we embed the specifics then we trade extensibility for 
> efficiency; if we
> don't then we risk a low level of interoperability. I think
> interoperability should be the (first) main concern, less so 
> efficiency, so
> let's look at embedding specifics (or candidates that do so).
> 
> Given the likely diversity of LFBs and devices built from 
> them, I would
> like to see a protocol built from small modules specific to LFBs. This
> seems to me to reflect the diversity in the model and I think it would
> align nicely with developing NPF work. Topology/capability 
> discovery will
> tell the CE which (versions of which) modules to use.
> 
> My second main concern is the CE-FE transport, but I don't 
> know if I have
> anything new to contribute here - just a concern based on
> discussions/choices in other groups. Our position is possibly 
> better than
> theirs as we don't have to allow arbitrary CE-FE distance.
> 
> Regards,
> 
> Alistair
> 
> --
> Alistair Munro,
> Principal Engineer, U4EA Technologies Ltd.
> City Point, Temple Gate, Bristol, BS1 6PL, U.K.
> E-mail: [email-masked]
> Tel: (work) +44-117-373-6765, (home) +44-1275-462707, (mobile)
> +44-7974-922-442;
> Fax: +44-117-373-6751
> Web: http://www.u4eagroup.com
>

---

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Tue, 4 Nov 2003 11:48:41 -0800

Hi Joel

You have brought up a v. good point. 
I don't think this is one of the big differences between the protocols.
As far as I know, all the protocols have defined some sort of operations
to be performed on the LFBs like Add/Delete, etc. But the question is
whether
the model should also define operations or methods on individual LFBs.
I don't believe this is a good design practice; I have attended a lot
of IETF meetings in which I have heard a lot of vendors complaining
about
how ugly it is to have methods as part of MIBs and how much complexity
it adds to the implementation. My understanding is that one of the
reasons 
why this is needed with SNMP is cause the protocol does not support
command
bundling. However, there may be other reasons as well for doing this.
But my point is that as long as the protocol is designed to support
features
like command bundling and defines the generic operations or methods to
be applied on LFBs or modules in the data model, I don't think that
methods
belong in the data model as part of LFBs unless there are very good
reasons
for doing so. This would cause unnecessary implementation complexity
and would be redundant if protocol operations are defined.

Thanks
Hormuzd

-----Original Message-----
From: Forwarding and Control Element Separation
[mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: Monday, November 03, 2003 12:54 PM
To: [email-masked]
Subject: [FORCES] An oversimplified comment on protocols and operations

In looking at the protocol proposals, I have been trying to understand
the
significant differences between them.

One interesting difference is in the way "operations" on entities are
supported.
[What follows is over-simplified and not intended to denigrate any of
the
proposals.]

In some of the proposals, the base protocol has the "operations".  The
defined operations tend to be read and write.

In some of the protocols, the elements each define the operations, and
the
protocol is defined to carry an opaque block to be interpreted by the
element.

One could also imagine an intermediate point where the protocol is
defined
to carry a target, and operation identifier, and operation parameters,
and
then to return operation results.  And each element type definition
included the list of permitted operations.

It seems to me that if LFBs (target elements) will have very similar
operations most of the time, then those operations ought to be called
out
in the base protocol.  On the other hand, if the operations on LFBs tend
to
be very different, then the protocol ought to be designed to carry more
generic blocks.

This topic comes up in many management / control applications.  It would
seem to behoove us to address it directly and explicitly rather than
choosing a protocol and then accepting the operational implications of
the
protocol.

Yours,
Joel M. Halpern

PS: I will admit that both extreme approaches (and most midpoints) can
work.  One can suggest that this is a philosophical difference.  But it
has
practical implications in the protocol structuring.