Subject: Re: [netmod] ForCES Forwarding Element Model

From: "tom.petch" <[email-masked]>
Date: Wed, 1 Oct 2008 16:31:55 +0200

Belatedly, yes I have been tracking the ForCES model, do understand it (but
found it very hard work to understand).  The terminology caused me much grief -
same words given a special meaning in ForCES when they already had one in XML -
so I pressed for and got changes there, making it more XML-friendly.

I had not seen it as a candidate for YANG (assuming that that is what you mean
by being a NETMOD candidate) but as I expect you are aware, the author is active
on both Netconf and NETMOD working group lists and may have his own view

Tom Petch

----- Original Message -----
From: "Romascanu, Dan (Dan)" <[email-masked]>
To: "NETMOD Working Group" <[email-masked]>
Sent: Wednesday, September 24, 2008 4:17 PM
Subject: [netmod] ForCES Forwarding Element Model

> I am reviewing
> http://www.ietf.org/internet-drafts/draft-ietf-forces-model-15.txt which
> is on the IESG table for approval. It looks like a good candidate for
> NETMOD if the language was ready. Is any of you folks familiar with this
> work and thought how NETMOD would apply? Other comments?
>
> Dan
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

_______________________________________________
netmod mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netmod

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 01 Oct 2008 12:36:14 -0400

My own take was that ForCES was not well matched to the NetMod / NetConf 
needs.
Firstly, the ForCES model and protocol are aimed at a very fine level of 
detail.  Much moee detailed than would normally be visible in a CLI.
Secondly, and closely related to the first, ForCES uses a state oriented 
view, rather than an operational oriented view.  ForCES is about 
configuring fine grained logical function blocks, and stringing those 
blocks together to actually deliver packet behaviors.

Which brings us to the conceptual difference.  In the ForCES model, 
while forwarding elements can be affected with SNMP, it is assumed that 
the normal use of configuration operations (SNMP, CLI, NetConf) would be 
with the CE.  And that hese operations would be in terms of higher level 
constructs (traffic classes and their per hob behaviors, for example.) 
The Control Element (CE) is responsible for translating that into the 
details required to configure the distinct FEs (possibly from different 
vendors, with differing capabilities) to deliver the user requested effects.

Note that as a result of these decisions, for example, the ForCES 
protocol is not XML at all.  It is operations using the model defined by 
XML documents.  But those operations are encoded in a binary TLV 
protocol, since it is for use by the CE, which is presumed to know the 
XML definitions of the various components.

Yours,
Joel M. Halpern

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 2 Oct 2008 10:47:14 +0200

> -----Original Message-----
> From: tom.petch [mailto:[email-masked]] 

> I had not seen it as a candidate for YANG (assuming that that 
> is what you mean by being a NETMOD candidate) but as I expect 
> you are aware, the author is active on both Netconf and 
> NETMOD working group lists and may have his own view

Actually what I had in mind was using NETMOD to meet the goals of ForCES
but I am aware as I said that the timing was working against such a
course of the events. The other course that you are mentioning would
have been an interesting path that I frankly did not think about, but
this is also by now just another not walked what-if path in the history.

Yes, I would also be interested to listen opinions from the principal
author or other ForCES contributors on these topics. 

Dan