Subject: Re: model draft comments

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Fri, 10 Jan 2003 14:02:33 -0800

Hi All,

I agree with Alex. I think its basically essential to have knowledge about
the functionality or capabilities of the FE in order to control/configure
it.
For example, if the FE has 2 functional blocks, an IPv4 block followed
by a NAT block, its necessary to know the order in which these blocks are
linked in order to configure them. For example, a NAT function may change
a packet's source or destination IP address.  Any number of other logical
functions (e.g., layer 3 forwarding, ingress/egress firewall) may make use
of the source or destination IP address when making decisions.  The CE needs

to know whether to configure these logical functions with the pre-NAT or
post-NAT IP address. The Requirements draft speaks about importance of
ordering
in section 6.3 and the Model draft is basically following all the
requirements.

Another thing is that, I don't think this is complicated or adds complexity
to the protocol. This information is inherently present on the FE and has to
be conveyed to the CE, which could be done in a single protocol message...
one way is described below by Alex. There are well known and easy to
understand
data structures that can be used to represent graphs, it is not a
fundamentally
hard problem.

Thanks
Hormuzd
-----Original Message-----
From: Alex Audu [mailto:[email-masked]]
Sent: Thursday, January 09, 2003 2:21 PM
To: [email-masked]
Subject: Re: [FORCES] model draft comments

Hi Alan,

  The information conveyed by the "graph" is pretty important for it
  determines the beahvior
  of the FE in relation to the overall NE. I am assuming the "graph" in
  this sense represents
  the relative placements (or location in the data path) of the resources
  in the FE. Making such
  placements configurable (by CE or otherwise) will allow bahvioral
  modifcation or programmability
  of the NE. This is a good thing.  The extent of that programmabiility
  however depends on advances
  in chip technology of which FEs are made. But logically, this shouldn't
  be too difficult to do.

  It will probably be useful to come up with a set of graphs of those
  resources, and then provide
  a documented mapping between each graph and the corresponding FE
  behavior. rfc 3290 is a
  useful starting point towards this goal.

  To answer your questions:
  1. How do we represent the graph?
    We can possibly assign unique IDs to the resources or components.
  Once that is done,
    stringing then up in a sort of linked list to reflect the graph
  becomes easy.

  2. Where is that graph representation stored at boot time?
     In the case where resource graphs are preset (most restrictive),
  graphs could be stored in
     non-volatile memory of some sort. However, assuming programmability,
  the FEs will
     probably boot up with unconfigured graphs. It is up to CE to
  configure the graphs based on
     intended beahviors for the FEs. In this case, the graph will be
  stored in RAM,..which could
     then be saved off into a more persistent storage if need be.

  3. How is that information communicated to the elements which need it?
     This will be domain of the inter FE and CE protocol (e.g. FACT).

  Cheers,
  Alex.

In a message dated 1/8/2003 1:36:59 PM Eastern Standard Time, Alan DeKok
<[email-masked]> writes:

>"Joel M. Halpern" wrote:
>>
>> We have a basic choice about where on the spectrum of CE / FE
>> controllability we wish to be.
>
>  My opinion is that we can avoid much of this discussion by agreeing on
>elements which are common across the spectrum, or models.
>
>  e.g. Addressing a particular component of the graph is independent of
>how the graph is represented, and who represents it.  The CE could
>simply be told "here's a collection of handles to components", and can
>often manage those components without knowing their relationships.
>
>> We could declare that the component graph is strictly under the control
of
>> the FE, and the CE has no say in it.  If we say that, we will still need
a
>> way for the CE to understand the graph,
>
>  I agree it would be useful for the CE to understand the graph, but I'm
>not sure it's required.  I would like to have diagrams and examples of
>the various scenarios to put the discussion on a concrete setting.
>Until then, the discussion is too vague to enable us to move forwards.
>
>> but we we will be restricted in the
>> services a CE can enable by the graph that actually exists on the FE.
>> We could declare that the CE must be able to change the component graph
in
>> any way it wants to.  This would allow any service in principle.  In
>> practice, this would be impossible, as no FE will allow every possible
>> configuration of any possible number of graph elements.
>
>  And the connections between the graph elements are often static, and
>defined by physical traces on a board.
>
>> Thus, it seems (and has seemed) to me that we need to allow the CE to
>> discover and manipulate the graph.  There are limitations on that graph
>> manipulation (and on the element manipulations) which can readily be
>> communicated (in capabilities for example) so that the CE will generally
>> know what it can and cannot do.  There will be limitations on the graph
and
>> element manipulations which will not be captured in the capabilities, and
>> will result in the CE receiving errors when it attempts some service
>> establishments.
>
>  I agree.  We now have some interesting questions.
>
>1. How do we represent the graph?
>2. Where is that graph representation stored at boot time?
>3. How is that information communicated to the elements which need it?
>
>  e.g. Systems with PCI busses can do PCI queries, and have a
>well-defined way of discovering any graph topology at boot time.
>Application-layer changes aren't required.
>
>  Do we want systems supporting ForCES to have a similar discovery
>protocol?  How do we address the graph components?  How do we
>communicate component capabilities?
>
>
>  Graph topology is a difficult area to work with.  I'd like to see
>those issues seperated from the component configuration and control,
>which is where I see ForCES being applied.
>
>  Alan DeKok.
>

---

From: "(Ram Gopal )" <[email-masked]>
Date: Tue, 21 Jan 2003 10:35:25 -0500

Hello Jamal,

By seeing you first email 2 weeks back, I responded to you privately and mentioned that I vacation time. I  resumed office yesterday and catching up with the mailing list discussion hopefully able to participate actively by evening.    

Anyway, thanks for your concern.   BTW,  I agreed to Alex, Hormuzd comments and also with Joel,Alan, we should focus on how we are solving issues rather than who is responding to the issues. 

Regards
Ramg

> From: ext Jamal Hadi Salim [mailto:[email-masked]]
> Sent: Tuesday, January 21, 2003 4:09 AM
> Subject: Re: model draft comments
> 
> 
> Why is Hormuzd doing all the responding on behalf of the model draft's
> authors? Occasionaly Joel appears, you pose a question to him then he
> disappears.
> I think we should kill the current model draft and start a 
> new one perhaps
> with new authors. I honestly see no point in discussing it at 
> all if the
> authors dont bother to participate.
> 
> cheers,
> jamal
> 
> On Tuesday 21 January 2003 09:48, Alan DeKok wrote:
> > "Khosravi, Hormuzd M" wrote:
> > > One clarification before I reply, I was looking at model-01 draft
> > > and section 5 does not have item 10. do you mean section 4.3.2 ?
> >
> >   Sorry.  I meant the requirements document, section 5, item 10.
> >
> >   My comments were not that the requirments document had to 
> be revised,
> > but that the model document should make it clear how it will satisfy
> > those requirements.  Simply saying "we represent a graph 
> topology and
> > the CE interprets it" is insufficient for me to understand how it's
> > supposed to work.
> >
> >   Alan DeKok.
>

---

From: "Putzolu, David" <[email-masked]>
Date: Tue, 21 Jan 2003 09:56:28 -0800

FYI, Lily Yang, one of the co-authors, is on sabbatical
until late February and is totally beyond the reach
of email.  The other authors have already responded.

Note that the model draft is an individual contrib -
it has not been accepted as a working group document.
Alternative proposals are welcomed, or debate and
changes to the current proposal.

Cheers,
David

> From: Jamal Hadi Salim [mailto:[email-masked]]
> Sent: Tuesday, January 21, 2003 1:09 AM

---

From: Alex Audu <[email-masked]>
Date: Tue, 21 Jan 2003 13:18:59 -0500

Jamal,

Your policy/service idea is best kept at a much higher level
than the framework that ForCES is being specified for. This is the application that uses ForCES to provide services.

Again, I'll suggest a quick look at the work that has been
done under IEEE P1520 (specification for programmable router
interfaces). (You can point your browser to your favorite
search engine and search for IEEE P1520 to get to it,..or
you can go to the IEEE's web site).

In there, you'll see three main layers: Service abstraction,
Resource Abstraction and then Hardware Abstraction in that
order. You can have a policy layer on top of the service layer. The resource abstraction is basically your building blocks (shaper, dropper, filter,..etc). The service layer programs the lower resource layer to provide specific services,..which in turn programs the hardware layer.

In ForCES, the service layer is the high level application
that sits in CE that makes sense of the topology information
obtained from FEs. It then configures the topology for
specific services. Now, the level of that configuration may
be different. It may just be parameter modifications, or in
the extreme case, it may also include placing resources in a
particular data path. The FE will be the programmable hardware.

Cheers,
Alex.

In a message dated 1/21/2003 6:16:27 AM Eastern Standard Time, Jamal Hadi Salim <[email-masked]> writes:

>
>The main contention as i see it are:
>a) Forces is not just about QoS and diffserv alone; in my opinion they are
>merely examples of the larger forces model. Diffserv and QoS fit within the
>larger ForCES model but the vice-versa is not necessarily true.
>b) There are infact layers for the model to make sense: The lower two being a
>policy/service layout of a graph of functional block/elements and beneath it
>being the functional block itself which is not aware of the larger picture.
>
>The draft model does lump the two layers in b) together or at least does not
>unambigously declare them separate.
>
>To me the above  makes any discussion on the draft hard to start.
>
>> You are certainly free to write an internet draft that takes the
>> perspective you think is helpful.  Such a draft might allow others in the
>> working group to understand what problem you are trying to raise.  We might
>> decide that yours was a better direction.
>>
>> However, I can not see throwing away the current draft without having a
>> working group accepted alternative in hand.
>>
>
>I didnt wanna exercise the option of releasing another draft yet(i did in the
>case of the requirements draft after similar frustration); i was hoping we
>could reach some understanding.
>
>cheers,
>jamal
>
>> Yours,
>> Joel M. Halpern
>>
>> At 04:08 AM 1/21/2003 -0500, Jamal Hadi Salim wrote:
>> >I think we should kill the current model draft and start a new one perhaps
>> >with new authors. I honestly see no point in discussing it at all if the
>> > >   My comments were not that the requirments document had to be revised,
>> > > those requirements.  Simply saying "we represent a graph topology and

---

From: Jamal Hadi <[email-masked]>
Date: Tue, 21 Jan 2003 19:49:37 -0800

Alex,

I forgot about those layers in 1520.
Essentially it is along the lines of what i was getting to.
I am not sure i understand why you say this layering cant be part of the
model. In my opinion when you provide a policy, you are describing a
service instantiation and if you are going to provide a protocol tga

cheers,
jamal

On Tuesday 21 January 2003 13:18, Alex Audu wrote:
> than the framework that ForCES is being specified for. This is the
> application that uses ForCES to provide services.
>
> order. You can have a policy layer on top of the service layer. The
> resource abstraction is basically your building blocks (shaper, dropper,
> filter,..etc). The service layer programs the lower resource layer to
> provide specific services,..which in turn programs the hardware layer.
>