Subject: Re: model draft comments

From: Alex Audu <[email-masked]>
Date: Fri, 10 Jan 2003 13:23:37 -0500

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 <[email-masked]> 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.
>
>  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
>relationships between graph elements.  You can have loops.  You can have
>cross-connections.
>
>  Linked lists are insufficient.  Naive solutions are inadequate.
>
>  Alan DeKok.
>

---

From: Alan DeKok <[email-masked]>
Date: Fri, 10 Jan 2003 14:09:46 -0500

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

> I suggest you read the "Capability Model versus State Model"

  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.

> Luckily, our problem domain is not that complex.

  I'm not sure that we can make that statement.

> So we need

  There are logical loops and physical loops.  The same NE may process a
packet twice, and that ability should be shown in any graph which
represents the FE.  However, from the point of view of a packet, it
simply transits a number of NE's, and probably doesn't know or care that
some may be the same.

> configurable data flow paths in a network element.

  Do you have a URL to a specific document?

  Alan DeKok.

---

From: Jamal Hadi Salim <[email-masked]>
Date: Mon, 13 Jan 2003 06:10:10 -0500

On Friday 10 January 2003 13:23, 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 "to a certain degree when
> it makes sense".

Lets not even go there first. We need to resolove a very simple question
under discussion at the moment.

> 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

This should be left to the intelligence in the CE. I may want to allow loops.

> I suggest you look at the IEEE P1520 specs to get an insight

You mean a marketing insight? Please let sleeping horses lie.

On Friday 10 January 2003 17:02, Khosravi, Hormuzd M wrote:
> 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

sure - btw, dont think anybody disagreed with this.

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

the contention point is whether that ordering belongs in the FE block or
whether it belongs in the policy which builds a collection of blocks.
As far as the NAT block is concerned, and i hate to use obscene words, but if
you design it right, it doesnt have to know whether it is doing pre or post
NAT activity. Ordering is a policy requirement.

And no graphing of these blocks is not a simple thing unless you are talking
about simplistic models like the one below or the one used by COPS.

cheers,
jamal

> configurable data flow paths in a network element

> >>   the relative placements (or location in the data path) of the
> >> resources in the FE. Making such

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 13 Jan 2003 14:45:20 -0500

I must be misunderstanding your concern.

No one is asking for a system where the CE can tell the FE to do something
it is not capable of.  No one is asking to mandate that all FEs have
adjustable paths between components.
But some FE do have such power.
And allowing the control expressions to specify connectivity, given that
the model has to already represent connectivity, conditionals (which
packets which take which exit from a multi-exit block), and API semantics
(what information is preserved across the interfaces between model blocks,
does not seem to add complexity.

I think I am missing something in your complexity assertion.  The policy
framework Qos Device Datapath Information Model is not simple.  But it is
not intractable either.  The DIffServ framework model is somewhat simpler,
and still quite powerful.

Personally, I would guess that the logic in the standard for describing a
sufficiently powerful forwarding table block (which is a single block) is
going to be more difficult than the potential for graph manipulation.  We
do have to be careful. But it does not seem to be a show stopper.

Yours,
Joel M. Halpern

---

From: Jamal Hadi Salim <[email-masked]>
Date: Tue, 14 Jan 2003 04:41:27 -0500

> But some FE do have such power.

no arguement there.

> does not seem to add complexity.

By "control expressions to specify connectivity" i take it you mean "policy"
or some layer above the configuration of a specific block.
What needs to be defined in a model are the two layers. Do you think this is
outside the scope of a model?

> and still quite powerful.

I am not arguing on intractability; however, i worry about statements like
the one you make in equating this to a qos model (these assertions are made
by a lot of other people ofcourse); the qos model is _simpler_
with well defined elements and a path in a graph (regardless of the
multi-exit paths). The FE model in Forces MUST be able to express the above
two models and a little MORE - hence my complexity assertion. In other words,
you can reduce the Qos model to a forces model but not the other way round.

> do have to be careful. But it does not seem to be a show stopper.

I think they are equally complex. You can make the graph simpler by enforcing
a set of functions and a fixed path at the expense of loosing valuable
flexibility. I believe we should be able to make it both simple and and
flexible and while i think the qos models have things to offer, they are a
subset of the Forces FE problem domain. I apologize if i am sounding
religious.

cheers,
jamal

> >And no graphing of these blocks is not a simple thing unless you are
> > talking about simplistic models like the one below or the one used by
> > COPS.
> >
> >cheers,
> >jamal