Subject: Re: model draft comments

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Tue, 14 Jan 2003 20:20:51 -0800

Jamal,

unfortunately i am unable to understand what your objection is ?
you agree that the FE capabilities are imp and need to be expressed,
but you dont want them to be expressed as a graph ??
you seem to contradict yourself or may be i am misunderstanding....
could you pls explain yourself may be by using some examples as
to your objection and describing the complexity of this issue ?
also, if you could explain what the simpler approach is using an
example that would help.

Thanks
Hormuzd
-----Original Message-----
From: Jamal Hadi Salim [mailto:[email-masked]]
Sent: Monday, January 13, 2003 3:10 AM
To: [email-masked]
Subject: Re: [FORCES] model draft comments

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".
> I suggest you read the "Capability Model versus State Model"
> section again.
>

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

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

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

> 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: Wed, 15 Jan 2003 11:00:06 -0500

> but you dont want them to be expressed as a graph ??

  I'll reply with my understanding of the issues.

1. Once you have a known handle, addressing and configuring a particular
NE element of an FE is relatively simple.

2. Representing trivial graphs is relatively simple.  e.g. 'a->b, a->c,
b->c' is a graph.

3. Representing the capabilities of the inter-element links is
difficult.

4. Representing the topology reconfiguration limitations of the
inter-element links is difficult.  (e.g. can the link a->c be deleted?)

5. Having the CE *interpret* any graph is difficult.

  The question which comes from #5 is:  How do you use a CE to convert a
collection of FE's and NE's, with their topology, into a router with
certain capabilities?

  The answer to that question is usually: Write an application which is
dedicated to those elements, and to that topology.

> also, if you could explain what the simpler approach is using an

  I'm inclined to ask the question the opposite way.  Some people
believe X is easy, others believe it's hard. I would say it's up to the
people saying it's easy to demonstrate why.

  What we're talking about is a complex graph, with capabilities,
functionalities, and/or code associated with both elements and
transitions between elements.  The CE we're trying to develop is capable
of understanding the graph, the transitions, and the capabilities.  The
CE is capable of taking that understanding, and turning it into nearly
any kind of network-aware device.

  Are there existing examples of this kind of capability and
configuration?  As I said, I think it's a *very* hard problem.

 For real-life examples, see lex, yacc, or www.ragel.ca.  All of these
take parse rules & associated code as input, and produce a state machine
which is the end application "managing" the data.  What I think we're
talking about here is the ability to have both a lex-style "NE/FE
grammar", and instead of C code for state transitions, have a "CE
interpreter", which uses the grammar to build network devices.

  I can't see why anyone would view this as easy.  Then again, I could
be missing something.

  e.g. The diffserv functional model defines a well-known graph
topology, with well-known behaviour.  It should be easy to generalize
the FE/NE's underlying a diffserv router, so that the CE can configure
and control them without knowing vendor-specific details.

  I understand how that can be done in ForCES, without too much
complexity.  As Jamal said, I'm also unclear on how that model can be
generalized to allow the CE to control *any* graph topology, with *any*
network functionality.

  Alan DeKok.

---

From: Jamal Hadi Salim <[email-masked]>
Date: Mon, 20 Jan 2003 04:45:19 -0500

> to your objection and describing the complexity of this issue ?

Please reread emails from both myself and Alan.
There are some very fundamental issues that need to be addressed. It may
require rewritting the whole draft - so no point in discussing pieces of text
that could be reworded (and no point in repeating here, read the emails i or
Alan sent).
Unfortunately, the authors of the draft are probably too pre-occupied
elsewhere - we need to hear from them as well.
Else lets rename this working group as "ForCES for QoS and IPV4 forwarding".

> also, if you could explain what the simpler approach is using an

Theres work in progress here which assumes :
http://www.cyberus.ca/~hadi/patches/action

unfortunately the docs are sparse and it is just that work in progress when i
get bored (A lot more features havent been exposed yet)

cheers,
jamal

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