Subject: Reconfigurability of FE graphs - weigh in please (was: RE: [FORCES] ForCES model - other thoughts)

From: "Putzolu, David" <[email-masked]>
Date: Mon, 10 Nov 2003 12:39:26 -0800

[chair hat back on]

Joel Halpern wrote>
> We are discussing reconfigurability.  I would really like to 
> retain that (as most folks have gathered by now.)

I have an impression that there is some consensus around retaining
at least some degree of reconfigurability.  I would like
to determine if this impression is correct or not.

I request that everyone weigh in on the mailing list as to whether
reconfigurability is desired or not.

Thanks,
David

---

From: Zsolt Haraszti <[email-masked]>
Date: Mon, 10 Nov 2003 21:20:53 -0500

LFB reconfigurability is a useful thing and we should address it
in the protocol/model.  Regarding hit-less reconfiguration,
I think we should have a statement that says that "hit-less
reconfiguration is not a requirement, though implementations
should obviously aim to minimize service interruption when
serving LFB reconfiguration requests."

/zsolt

---

From: Alistair Munro <[email-masked]>
Date: Tue, 11 Nov 2003 10:38:51 -0000

Hi All,

> to determine if this impression is correct or not.

I have tried to keep pace with, and understand, the thread and I would say
that there are sufficient claims of actual reconfigurability that it should
be retained. But the discussion has confused me a bit.

Some systems are reconfigurable by hot-plugging blades, reloading firmware,
etc. I can't see any conceptual or practical problem with this. Presumably
such events will generate a stream of notifications and messages to the CE
from the affected FEs.

Others are reconfigurable, or programmable, by rewiring the LFB topology,
and/or creating new LFB instances. I'm sceptical that this can be done
incrementally, (if not done incrementally then I suppose it is similar to
hot-plugging a blade), or that a functional model exists that will satisfy
all of us with prior art.

So, reconfigurability - SHOULD; programmability - MAY.

Note: lest there be any doubt, and because someone (Ram?) mentioned the
NPF, one objective of the NPF's model is to provide a framework in which FE
and LFB implementations from different vendors, using different component
realisations, can coexist on a blade or in a system. We have steered clear
of a programmable model so far, and nobody (in the NPF to my knowledge) has
yet come up with a requirement for it that can't be reduced to simple
whole-blade reconfiguration. But I'm sure someone will correct me.

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: John Renwick <[email-masked]>
Date: Tue, 11 Nov 2003 08:10:12 -0600

I'm not opposed to reconfigurability, but I'm concerned that it could in
some
cases give the protocol (or the NPF APIs) two equally valid ways of making
the
same change.  This would damage interoperability.

As a simple example: if a Meter LFB supports a table containing multiple
entries, each one holding the leaky-bucket parameters for one meter, you
could
create a new meter either by adding an entry to the table or by adding a new
Meter LFB and linking it in to the packet path.  If we permit such a choice
and
don't offer any guidelines or requirements on which to use, we could end up
with
two flavors of implementations and applications unnecessarily.

So if topological reconfigurability is supported in the protocol, the WG
should
try to restrict the available choices somehow, perhaps recommending that
protocol
implementations permit it only when the same change can't be made without
modifying the graph.

Regards,

--
John Renwick                          Agere Systems
Software Technical Manager            1230 Northland Drive
Phone: (651) 675-2986                 Mendota Heights, MN 55120
FAX:   (707) 897-7928                 Cell:  (612) 669-9397
mailto:[email-masked]             http://www.agere.com

> -----Original Message-----
> From: Forwarding and Control Element Separation
> [mailto:[email-masked]]On Behalf Of Alistair Munro
> Sent: Tuesday, November 11, 2003 4:39 AM
> To: [email-masked]
> Subject: Re: Reconfigurability of FE graphs - weigh in please (was: RE:
> [FORCES] ForCES model - other thoughts)
>
>
> Hi All,
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 11 Nov 2003 10:42:32 -0500

There are some interesting proprties of your example...
1) The presence of two methods does not reduce interoperability.  Assuming
that the capabilities of the FE indicate that reconfigurability is
permitted and that multiple meter LFBs are permitted, then the CE can try
adding an LFB if it wants.
2) In reality there are cases where you will need to do both.  Some
implementations will have limits (by hypothesis larger than 1) on the size
of a meter table.  Hence even in an FE which supports tabular meters there
will be times when one needs new meters.  Similarly, even systems which
support multiple dynamic meter LFBs will sometimes be unable to create new
meter LFBs.
3) While it is true that adding reconfigurability adds some complexity to
the protocol and to CEs, once we have done that interoperability still
exists even with FEs that are not reconfigurable.  And in particular, if an
FE supports new meter LFB creation and supports new meter table entries,
then the CE can use either one and it will work.

Yours,
Joel M. Halpern

---

From: Jamal Hadi Salim <[email-masked]>
Date: Tue, 11 Nov 2003 08:00:19 -0800

> then the CE can use either one and it will work.

How does this affect the protocol?
Maybe i am lookign at netlink2-centric view and so i may be missing the
subtle issues.

cheers,
jamal

---

From: John Renwick <[email-masked]>
Date: Tue, 11 Nov 2003 10:17:02 -0600

Joel,

You're right, of course.  In NPF we have an API that does the same thing
(add routes)
in two completely different ways, using either a single "unified" table or
"discrete"
tables of prefixes and next hops
(http://www.npforum.org/techinfo/IPv4_IA.pdf).  Since
we expected this choice to involve a performance trade-off within the
implementation,
we added a function by which the application (CE) can ask the implementation
(FE) which
method it "prefers" if it supports both.  I don't think anybody was
completely happy
with this, but it seemed to be necessary, given that no single approach
(unified vs.
discrete tables) could work acceptably well in all situations.
Interoperability was
assured only because we said implementations MUST support the (possibly
suboptimal)
unified mode, and could optionally support discrete mode.  We didn't feel we
could
require applications to attempt both, in order to find out which one the
implementation
supports, even though that's what is required if an application wants both
performance
and interoperability.

I think deciding on a single way of doing things is goodness.  In this
particular case,
there were significant performance issues that were mitigated by one
approach, and on
the other hand, popular applications that would have needed major
architectural changes
if that were the only option.  One way is better unless you *have* to have
two.

John

> [mailto:[email-masked]]On Behalf Of Joel M. Halpern
> Sent: Tuesday, November 11, 2003 9:43 AM

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 11 Nov 2003 11:26:34 -0500

In the particular case of meters, the existence of two "ways" is a
consequence of other choices, not a goal in and of itself.

We need to be able to create LFBs and adjust topology.
I expect that people will want to support indexed meter LFBs which can use
either port numbers of metadata to select the specific meter.  I would be
hestiant to prohibit such a thing from the model.

And of course in reality many FEs will have limits on how many meters they
can put into an LFB.  While some FEs will be able to cope with this by
creating multiple blocks under the cover, not all FEs will be that smart.

We should (when we get far enough to usefully do so) give advice for how to
use the various tools we will have in our tool kit.

Yours,
Joel

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 11 Nov 2003 11:18:08 -0500

The protocol effect of the question of reconfigurability is simply whether
there are protocol mechanisms to create (and presumably delete) LFBs and to
create (delete / modify) links between LFBs.

Once one has adopted such mechanisms, the ability to create meter instances
in two ways has no impact on the protocol, and does not adversely affect
interoperability.

Yours,
Joel

---

From: Jamal Hadi Salim <[email-masked]>
Date: Tue, 11 Nov 2003 08:38:51 -0800

> create (delete / modify) links between LFBs.

ok.
Netlink2 can do both (which is why i was confused it is was an issue).
Infact i talked about this in my presentation yesterday.
I would think this is basic requirememt to be met.

> in two ways has no impact on the protocol, and does not adversely affect

nod. More related to LFB implementation details. Post association
Forces shouldnt care.

cheers,
jamal

---

From: John Renwick <[email-masked]>
Date: Tue, 11 Nov 2003 10:40:53 -0600

Please forgive my ignorance of the details of the three proposed protocols.

Can the protocol be designed to make changes in a way that doesn't express
whether the result will be adding to a table or changing the topology, and
let the implementation decide how to do it?  If so, topology changes could
take place without the knowledge of the CE unless it explicitly rediscovers.

John

> Sent: Tuesday, November 11, 2003 10:18 AM

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 11 Nov 2003 12:08:15 -0500

The protocol will (I expect) be explicit about whether something is an LFB
attribute vs a separate LFB.
However, the entire LFB structure is simply a model for exchange between
the FE and the CE.  The FE can do whatever it wants internally to meet the
request.
The FE can also say "no" to the requests.

I believe / expect that the two methods of adding meters will be visible in
the protocol.  I believe it would be a mistake to refuse to allow adding
LFBs because it can produce this duplication.   I also believe that it
would be an excessive topology and FE implementation requirement to say
that we will never allow muti-entry meters  (such a restriction would
undermine our statements so far that meta-data is a useful part of the
system.  Removing this just to avoid one non-problematic duplication would
also seem to be a mistake.

Yours,
Joel M. Halpern