Subject: An oversimplified comment on protocols and operations

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 3 Nov 2003 15:53:51 -0500

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.

---

From: Jamal Hadi Salim <[email-masked]>
Date: Mon, 3 Nov 2003 17:00:35 -0500

> protocol is defined to carry an opaque block to be interpreted by the element.

You must be refering to netlink2 with the above statement - in which
case you have oversimplified. What you refer to as "operation" is infact
both an operation and a reference/addressing to a specific LFB.

> then to return operation results.

Everything you describe above already happens with netlink2 with a
caveat that the operation results are optional; you have to request for
them otherwise you dont get them.

>  And each element type definition

Should this be a discovery phase activity?

> be very different, then the protocol ought to be designed to carry more

It doesnt buy you much in terms of saving bits or looking beautiful.
You can move the LFB referencing to somewhere else on the header
and keep specific operations; end result is you will end up using just
as many bits. Infact there cant be that many operations per LFB other
than the classical add/del/get so it should be a lot more efficient
in bit-saving to have one space for both LFB-addressing and operation.
(In netlink2 the add/del are also polymorphic and reused for event
throwing - saving even more space).

cheers,
jamal

---

From: Alistair Munro <[email-masked]>
Date: Tue, 4 Nov 2003 09:22:08 -0000

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: Weiming Wang <[email-masked]>
Date: Wed, 5 Nov 2003 23:09:47 +0800

Joel's question and the followed comments remind me of a feedback from ADs, as following link

http://peach.ease.lsoft.com/scripts/wa.exe?A2=ind0307&L=forces&T=0&F=&S=&P=2166

I understand the question Joel raised just as how much shall we put off-loaded functions to FE. The 
extreme is for LFB to support codes, just like what active network does. I'm afraid to put more or less 
maybe not just tradeoff between extensibility and efficiency, it may also include trade of complexity, 
feasibility. Experience of active network may give us some feedback information on this. It is also 
a question if the interoperability of LFBs will be more, not affected, or even less by puting 
more off-loaded on them? 

I should state that what I addressed is only something I understood to the question. I don't have any mean
to any proposal. I think current proposals are all far away from the problems I addressed.

Regards,
Weiming Wang