Subject: Re: LFB topology reconfguration

From: "Deleganes, Ellen M" <[email-masked]>
Date: Thu, 6 Nov 2003 17:25:29 -0800

It seems like what is being proposed here is for the case of a very
generic FE that contains a lot of different kinds of LFBs, and the
services that can be supported depend on the topology configured for
those LFBs (or various subsets of the LFBs). In this case, I can see
where expressing all of the possible topologies might not be feasible.

However, in the case where all possible (or even reasonable) topologies
for all of the services cannot be expressed, the operator must be aware
of what the FE is capable of supporting and how to configure the FE to
provide the desired service. The operator may not be able to depend
solely on the FE protocol to determine its capabilities and the
configuration that is required in order to support such a capability. It
seems like the operator may need to use some vendor-supplied tools to
add a service or new capability to a service. In this case, I'm not sure
how much sense it makes to have a generic protocol.

Regards,
Ellen

-----Original Message-----
From: Forwarding and Control Element Separation
[mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: Thursday, November 06, 2003 2:49 PM
To: [email-masked]
Subject: Re: LFB topology reconfguration

I would argue that there is no such thing as "the diffserv path".
Diffserv
is a mechanism for offering a number of services.  While one can have an
FE
that has a fixed toplogy of classifiers, markers, meters, queues and
schedulers, many FEs will have some flexibility in that topology.
It is quite likely that even if one could envision the topology for all
possible services, there are not enough LFBs to offer them all
simultaneously.  So the operator picks the ones he is offering now, and
uses some of the resources to offer those.  As he decides to offer more
services, he provisions them on the FE (via the CE) and makes them
available to customers.

I do not know of an operator who can determine at box installation time
all
the services he will offer from that platform.
Equally, I do not know any operator who will be happy being told that
new
service offerings will requrie that he disable the box.
And there seems to be no point in having some other protocol for
extablishing these.

Let me put it another way.
Someone has to tell the FE what that initially topology ought to be.  It
may be fixed by the factory.
If it is not fixed by the factory, it is clearly the CEs job to set it
up.
It is clearly desirable to be able to change that setup during
operation.
If the FE can support such a change, it is clearly the CEs job to make
such
a change.

And it is not possible to enumerate all possible graphs, or all possible
services.

Yours,
Joel M. Halpern

At 02:33 PM 11/6/2003 -0800, you wrote:
>Seems like most people agree that micro-change within one given service
>(protocol as Alan put it) does not result in topology change. so no
>argument there.
>
>Now lets look at the macro-change which invovles change of service
>("service provisiong" as Joel called it).
>
>For example, suppose FE0 supports IPv4 forwarding, DiffServ and MPLS.
But
>the operator only wants to use IPv4 at the beginning. Well, the FE can
>still be modeled by a topology that includes all the services it is
>capable of. So the CE can model the FE by a topology like this (or, FE
can
>just report its topology to CE):
>+------------------+
>|classifier V  out1|-----> IPv4 path (subgraph)
>|                  out2|-----> DiffServ path (subgraph)
>|                  out3|-----> MPLS path (subgraph)
>+------------------+
>Note that each path by itself is a subgraph potentially involving
multiple
>LFBs and multiple datapath.
>
>Now, "classifier V" is only a virtual classifier. FE0 may not have a
>classifier at all. But we use "classifier V" to model FE0's ability to
>support multiple services. Now at the begining since only IPv4 is used,
CE
>can configure "classifier V" such that packets all go to out1 (IPv4
path).
>
>Later (like a month later), the operator want to use MPLS instead, they
>can configure classifier V such that packets now flow to out3.
>
>Another month later, if they want to use both IPv4 and DiffServ, sure.
>But the topology remains static.
>
>Now, what if the operator wants to do IPv6, but FE0 does not support
that
>to begin with. Well, the operator either buys another FE (FE1) that
>support IPv6, or he takes FE0 down and loads up the code to do IPv6,
plug
>it in, and start all over again.
>
>Remember, all we do here is just modeling the "logical" bahavior of FE
>with a bunch of "logical" LFBs. I can't see why we can't model the
service
>provisioning this way, without the need to reconfigure LFB topology.
>
>Lily
>
>
> > -----Original Message-----
> > From: Forwarding and Control Element Separation
> > [mailto:[email-masked]]On Behalf Of Alan DeKok
> > Sent: Thursday, November 06, 2003 7:33 AM
> > To: [email-masked]
> > Subject: Re: LFB topology reconfguration
> >
> >
> > "Joel M. Halpern" wrote:
> > >
> > > My guess is that
> > > 1) To assign a subset of customer traffic to an existing
> > DiffServ service
> > > will not require LFB reconfiguration on almost any FE.
> > ...
> >
> >   I would tend to agree.
> >
> >   For me, the boundary between internal changes to an LFB's
> > configuration, and changes to inter-LFB connections is most often a
> > protocol boundary.  Provisioning new connections/services within a
> > protocol requires updating entries in the LFB's which implement that
> > protocol.  Provisioning a new protocol requires re-arranging LFB's,
or
> > creating new LFB's.
> >   Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Fri, 7 Nov 2003 13:14:26 -0500

> where expressing all of the possible topologies might not be feasible.

  Some vendors systems are highly programmable (e.g. software), and thus
can do "anything".  It's difficult for those vendors to see why they
should restrict their solutions to being described in LFBs.  It's also
difficult for them to see why they need to describe their solutions,
because they can do "anything".

  At the other extreme, we have vendors with dedicated (and limited)
hardware.  Their systems are too simple to implement any ForCES
protocol, and can be easily described without resorting to LFB's.

  ForCES allows everyone to meet in the middle.  This means that most
vendors have to perform additional work to support ForCES, without clear
and immediate benefits.  Much of the conversations (and concerns) on the
list have been about agreeing on what, exactly, those benefits are.

  Alan DeKok.