headers
Jamal Hadi | 2 Jan 2003 00:30

model draft comments

Folks,

I finally read or more like attempted to read but couldnt get myself to
really focus on completely digesting the draft. I see this draft as
attempts to be too many things at once without addressing clearly what i
see as the real issues.
I was tempted to write an alternative point of view, but realize we may
not be that much different in the perspective of looking at this. So heres
the way i see it:

- I believe there are two layers to the modelling and your draft doesnt
make a clear distinction between the two and hence the chaos.

1) A functional block layer:
A functional block provides a mechanism for packet massaging.
It must be told how to treat packets that traverse it.
Typical modelling of a functional block would involve a table of sorts.
The rows would represent states of _instances_ of the functional block.

2) A datapath layer:
This is a graph/serialization of _instances_ of functional blocks as
defined in a _policy_.

Figure 6 in the draft is a good represantation the two. There are several
instances of meters for example (representing layer 1 above) and a
policy is used to interconnect them. In my opinion, this is sufficient
representation.

To digress: the ForCES protocol tells the individual functional blocks
what to do (i.e it populates their tables with appropriate parameters).
(Continue reading)

Permalink | Reply | 4 comments |
headers
Alan DeKok | 6 Jan 2003 20:04
Favicon

Re: model draft comments

Jamal Hadi wrote:
>
> - I believe there are two layers to the modelling and your draft doesnt
> make a clear distinction between the two and hence the chaos.
>
> 1) A functional block layer:
> A functional block provides a mechanism for packet massaging.
> It must be told how to treat packets that traverse it.

  I agree.

> 2) A datapath layer:
> This is a graph/serialization of _instances_ of functional blocks as
> defined in a _policy_.

  I agree.  Note that it's possible to define, address, and manage
functional blocks, completely independently of their interconnections
(graph topology.)  In addition, doing topology discover and
configuration is an *extremely* difficult task.

  Page 5 of the draft, near the bottom, has the text:

    "However, the CE cannot reconfigure the graph topology
     dynamically, such as adding another meter or queue onto
     the FE in Figure 6 on the fly."

  To me, this would indicate that it's probably not necessary for the CE
to know the topology.  That is, if your "configuration" and "control" of
something is limited to knowing it exists, then it you might as well
treat it as if it didn't exist.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Internet-Drafts | 7 Jan 2003 14:28
Picon
Favicon

I-D ACTION:draft-ietf-forces-framework-04.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Forwarding and Control Element Separation Working Group of the IETF.

        Title           : Forwarding and Control Element Separation (ForCES)
                          Framework
        Author(s)       : L. Yang et al.
        Filename        : draft-ietf-forces-framework-04.txt
        Pages           : 25
        Date            : 2003-1-6

This document defines the architectural framework for the ForCES
(Forwarding and Control Element Separation) network elements, and
identifies the associated entities and the interaction among them.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-forces-framework-04.txt

To remove yourself from the IETF Announcement list, send a message to
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
        "get draft-ietf-forces-framework-04.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Joel M. Halpern | 8 Jan 2003 18:50

Re: model draft comments

We have a basic choice about where on the spectrum of CE / FE
controllability we wish to be.
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, 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.

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.

As far as I can tell, while we can adjust where in this middle ground we
are (and we should try for a good balance between power and simplicity in
the point we select), we must operate in this middle ground.

Yours,
Joel M. Halpern

At 02:04 PM 1/6/2003 -0500, Alan DeKok wrote:
>Jamal Hadi wrote:
> >
(Continue reading)

Permalink | Reply | 2 comments |
headers
Alan DeKok | 8 Jan 2003 19:36
Favicon

Re: model draft comments

"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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jamal Hadi Salim | 8 Jan 2003 23:52

Re: model draft comments

On Wednesday 08 January 2003 12:50, Joel M. Halpern wrote:
> We have a basic choice about where on the spectrum of CE / FE
> controllability we wish to be.
> 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, but we we will be restricted in the
> services a CE can enable by the graph that actually exists on the FE.

The FE should really only own the component/node/element and its config. It
should be able to refuse a config for a node - but thats as far as it should
go if it should stay simple. Policy control should not be under the FEs
domain (rather owned by the CE).

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

The graph layouts aka policy being owned by the CE is a very good start i.e
the CE sees the big picture. You can embed the intelligence in the CE to
decide what the possible configuration of the graph elements are. You can
also embed the intelligence of what possible per-element configs are in the
CE (either after youve discovered them or by virtue of them being well
known). The graph element should be able to reject specific configs (in which
case the graph instance is incomplete).

> 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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Alex Audu | 9 Jan 2003 23:21
Picon
Favicon

Re: 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),
(Continue reading)

Permalink | Reply | 1 comment |
headers
Alan DeKok | 10 Jan 2003 16:22
Favicon

Re: model draft comments

Alex Audu wrote:
>
>   The information conveyed by the "graph" is pretty important for it
>   determines the beahvior
>   of the FE in relation to the overall NE.

  Sure, but the draft says it doesn't support reconfiguration or
reconnection of the graph topology.  So if it's static, then knowing the
topology is much less important than if it could change.

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

  It's also extremely difficult, which is why it's currently outside of
the scope of ForCES.

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

  I disagree *completely*.  I deal with graph topology and manipulation
every day, and it's just not that easy.  You can have 1-N, N-1, or N-M
(Continue reading)

Permalink | Reply | 0 comments |
headers
Alex Audu | 10 Jan 2003 19:23
Picon
Favicon

Re: model draft comments

Alan,

The current FE Model draft doesn't rule out "dynamic FE control and configuration". In fact, it plans to
support it
"to a certain degree when it makes sense".
I suggest you read the "Capability Model versus State Model"
section again.

As for topology representation, surely, graph topology
representation and manipulation could be quite complex, especially when you allow arbitrary
transitions between nodes.
Luckily, our problem domain is not that complex. So we need
a constrained graph that maps nicely to our problem space.
I mean, I don't see any reason to allow for loops in a data flow path in an network element.

I suggest you look at the IEEE P1520 specs to get an insight
as to how linked lists could be used to represent dynamically
configurable data flow paths in a network element.

Cheers,
Alex.

In a message dated 1/10/2003 10:22:08 AM Eastern Standard Time, Alan DeKok <alan.dekok <at> idt.com> writes:

>Alex Audu wrote:
>>
>>   The information conveyed by the "graph" is pretty important for it
>>   determines the beahvior
>>   of the FE in relation to the overall NE.
>
(Continue reading)

Permalink | Reply | 4 comments |
headers
Alan DeKok | 10 Jan 2003 20:09
Favicon

Re: model draft comments

Alex Audu wrote:
>
> Alan,
>
> The current FE Model draft doesn't rule out "dynamic FE control and configuration". In fact, it plans to
support it

  I've never disagreed with that.

> "to a certain degree when it makes sense".
> I suggest you read the "Capability Model versus State Model"
> section again.

  I don't understand what the problem is.  I think you've misunderstood
my point.

  I will quote a line from the FE functional model draft, in the section
you would have me re-read.  I had previously quoted this section in my
message of January 6, to the list.  Near the bottom of page 5:

        "However, the CE cannot reconfigure the graph topology
        dynamically, such as adding another meter or queue onto
        the FE in figure 6 on the fly."

  This kind of graph topology reconfiguration is explicitely outside of
the scope of ForCES.  I agree with that limitation of the scope.

> As for topology representation, surely, graph topology
> representation and manipulation could be quite complex, especially when you allow arbitrary
transitions between nodes.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane