Subject: Re: model draft comments

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Fri, 17 Jan 2003 16:48:12 -0800

Hi Alan

Thanks for the detailed reply, its helpful to understand your view.
I agree with a lot of things your saying below and I don't think that
everything you have stated below (e.g. merging FE Caps from multiple
FEs) needs to be done at the ForCES protocol level. However, the protocol
should facilitate this, to be done by any app on the CE in a standard way.
And the FE model is one way of expressing these caps. Is there any specific
text in the draft which you think could be reworded or causes this
understanding ?

Pls point it out. Also, I have given more comments below.

Thanks
Hormuzd
-----Original Message-----
From: Alan DeKok [mailto:[email-masked]]
Sent: Wednesday, January 15, 2003 8:00 AM
To: [email-masked]
Subject: Re: [FORCES] model draft comments

"Khosravi, Hormuzd M" wrote:
>
> 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 ??

  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.
[HK] I agree

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

3. Representing the capabilities of the inter-element links is
difficult.
[HK] Does the draft mention inter-element caps ? When you say inter-element,

do you mean inter-FE or inter functional block? If the latter,
why do they need capabilities?

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?

[HK] I don't think merging capabilities from different FEs in a single
graph is something that the ForCES protocol needs to do or contain logic
for. However, the ForCES protocol would facilitate this by providing
the CE with the FE Capabilities. Its up to the CE as to what it does with
this information.

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

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

  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.

[HK]The model is a proposal as to how to do it.

  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.

[HK] This seems like the most powerful, but also most complex, possible
approach to building a CE.  Why not start with a CE that recognizes
the presence of certain fairly simple graphs and uses those?

  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.

[HK] Sure, we can start by building a fairly dumb CE that can control
common graphs and then extend it to more functions.

---

From: Alan DeKok <[email-masked]>
Date: Mon, 20 Jan 2003 13:39:03 -0500

"Khosravi, Hormuzd M" wrote:
> FEs) needs to be done at the ForCES protocol level.

  I agree.  But a generic "understanding" CE like you propose will have
to do that.  If we don't know how to have the CE merge the FE
capabilities to create a network device, then I don't see how a generic
capability description is useful.

> However, the protocol

  My main is section 5, item 10.  I agree that the FE's must provide
topology information to the CE, but I'm unclear as to what kind of
topology information is required.

  e.g.  "This FE implements the DiffServ model" is a topology
description, which would appear to satisfy the requirements.

  One topic of research, I think, is how much topology information is
useful, and how we can use that information.  If we decide that we don't
know what to do with complex topologies & configurations, then there
isn't much point in requiring the implementations to supply that
information.

> why do they need capabilities?

  I mean inter-functional block capabilities.  I believe that they *may*
need capability descriptions, because different inter-element
connections have different physical capabilities.  Since those
differences exist, we cannot create a complete functional model of the
device without also modelling those capabilities.

> the CE with the FE Capabilities. Its up to the CE as to what it does with

  If we don't know how the CE would use this information, then I
question the need for supplying it.

> [HK]The model is a proposal as to how to do it.

  I believe that the model document is still incomplete, and that there
are unsolved issues which it hasn't addresses.

> [ lex, yacc, etc ]

  I agree completely.  But that's for a well-known topology, where you
know where certain elements are located, and *why*.

> common graphs and then extend it to more functions.

  I doubt it's that easy.  If it was, then we would be able to take a
UML document describing the desired interaction of network devices, and
run it through a "compiler", which would generate:

  - protocol description
  - protocol stack
  - conceptual model
  - applications

  We just can't do this.  It took what, 2 years for the Diffserv group
to come up with the information management model (RFC 3290).  You're
proposing that the CE has this capability for *any* network
configuration, and *any* FE, and *any* network protocol?

  It's an astonishingly difficult problem.  That's why we have working
groups in the IETF.

  Alan DeKok.