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

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Mon, 10 Nov 2003 20:31:35 -0800

Nope, its not directly related. However, it would be nice to have this
clarification.

Hormuzd
-----Original Message-----
From: Forwarding and Control Element Separation
[mailto:[email-masked]] On Behalf Of Zsolt Haraszti
Sent: Monday, November 10, 2003 6:15 PM
To: [email-masked]
Subject: Re: [FORCES] Reconfigurability of FE graphs - weigh in please
(was: RE: [FORCES] ForCES model - other thoughts)

Hormuzd,

I agree that this is an important issue (e.g., to allow efficient
multicast of config requests to many same LFBs across many FEs),
but we can answer David's original straw poll without nailing
this issue down.  Or is there a reverse dependence you see?

/zsolt

"Khosravi, Hormuzd M" wrote:
>
> I would like to have one clarification in context with this issue.
> In the current model, does the FE instantiate LFBs or assign Instance
> IDs to LFBs or is it the CE ? In other words, does the LFB Instance ID
> namespace belong to the FE or CE ? I have heard most everyone agreeing
> that FE assigns LFB instance IDs, but just wanted to make sure.
>
> Thanks
> Hormuzd
>
> -----Original Message-----
> From: Forwarding and Control Element Separation
> [mailto:[email-masked]] On Behalf Of Putzolu, David
> Sent: Monday, November 10, 2003 12:39 PM
> To: [email-masked]
> Subject: [FORCES] Reconfigurability of FE graphs - weigh in please
(was:
> RE: [FORCES] ForCES model - other thoughts)
>
> [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: "(Ram Gopal )" <[email-masked]>
Date: Tue, 11 Nov 2003 12:22:52 -0500

Hello Joel,

> 
> 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.

FACT protocol has mechanism to do this.

> 
> 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.

FACT protocol is transparent to such operation

Regards
Ramg

> 
> Yours,
> Joel
> 
> At 08:00 AM 11/11/2003 -0800, you wrote:
> >On Tue, 11 Nov 2003, Joel M. Halpern wrote:
> >
> > > 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.
> >
> >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: "Putzolu, David" <[email-masked]>
Date: Tue, 11 Nov 2003 09:50:16 -0800

Forwarding to list (issue with email address not matching
subscribed address).

-David

-----Original Message-----
From: Susan Hares [mailto:[email-masked]] 
Sent: Tuesday, November 11, 2003 9:32 AM
To: Forwarding and Control Element Separation
Subject: RE: [FORCES] Reconfigurability of FE graphs - weigh in please

I agree with John.  It would be nicer to have a 
Single interface.  But if large data bandwidht 
interactions with FEs may need a different interface.

John and Dave P. Did a good job on the NPF forum
work.

sue

-----Original Message-----
From: John Renwick [mailto:[email-masked]]
Sent: Tuesday, November 11, 2003 11:17 AM
To: [email-masked]
Subject: Re: [FORCES] Reconfigurability of FE graphs - weigh in please

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
> Subject: Re: Reconfigurability of FE graphs - weigh in please (was:
RE:
> [FORCES] ForCES model - other thoughts)
>
>
> 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
> FE supports new meter LFB creation and supports new meter table
entries,
> Joel M. Halpern
> At 08:10 AM 11/11/2003 -0600, you wrote:
> >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
> >
> > > [mailto:[email-masked]]On Behalf Of Alistair Munro
> > > Sent: Tuesday, November 11, 2003 4:39 AM
> > > Subject: Re: Reconfigurability of FE graphs - weigh in please
> (was: RE:
> > > Hi All,
> > > 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: "Yang, Lily L" <[email-masked]>
Date: Tue, 11 Nov 2003 22:27:25 -0800

In the case that FE boots up with a static LFB topology already, it
simply is more straightforward for FE to report the LFB topology to the
CE with the LFB instance ID assigned already. 
In the case that CE wants to reconfigure LFB topology on the FE, it
seems ok for either CE or FE to assign the ID. But it probably is a good
idea to let FE do that so that it is consistent in either case.

-----Original Message-----
From: Forwarding and Control Element Separation
[mailto:[email-masked]] On Behalf Of Khosravi, Hormuzd M
Sent: Monday, November 10, 2003 1:58 PM
To: [email-masked]
Subject: Re: Reconfigurability of FE graphs - weigh in please (was: RE:
[FORCES] ForCES model - other thoughts)

Thanks
Hormuzd

-----Original Message-----
Subject: [FORCES] Reconfigurability of FE graphs - weigh in please (was:

[chair hat back on]

Joel Halpern wrote>

Thanks,
David

---

From: Tom Petch <[email-masked]>
Date: Thu, 20 Nov 2003 14:20:20 -0000

Definitely a good idea; I am very much with Joel on this one.

And for me as a consumer, the hot-pluggable blade is not leading edge, as some
e-mails have put it, but the norm since about 2000.

Tom Petch

-----Original Message-----
From: Putzolu, David <[email-masked]>
To: [email-masked] <[email-masked]>
Date: 10 November 2003 20:39
Subject: Reconfigurability of FE graphs - weigh in please (was: RE: [FORCES]
ForCES model - other thoughts)

[chair hat back on]

Joel Halpern wrote>

Thanks,
David