Subject: [forces] I-D Action: draft-ietf-forces-model-extension-00.txt

From: [email-masked]
Date: Wed, 25 Sep 2013 08:53:40 -0700

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           : ForCES Model Extension
	Author(s)       : Evangelos Haleplidis
	Filename        : draft-ietf-forces-model-extension-00.txt
	Pages           : 27
	Date            : 2013-09-25

Abstract:
   Forwarding and Control Element Separation (ForCES) defines an
   architectural framework and associated protocols to standardize
   information exchange between the control plane and the forwarding
   plane in a ForCES Network Element (ForCES NE).  RFC5812 has defined
   the ForCES Model provides a formal way to represent the capabilities,
   state, and configuration of forwarding elements within the context of
   the ForCES protocol, so that control elements (CEs) can control the
   FEs accordingly.  More specifically, the model describes the logical
   functions that are present in an FE, what capabilities these
   functions support, and how these functions are or can be
   interconnected.

   RFC5812 has been around for two years and experience in its use has
   shown room for small extensions without a need to alter the protocol
   while retaining backward compatibility with older xml libraries.
   This document extends the model to allow complex datatypes for
   metadata, optional default values for datatypes and optional access
   types for structures.  The document also introduces three new
   features, bitmap as a new datatype, a new event condition
   BecomesEqualTo and LFB properties.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-forces-model-extension

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-forces-model-extension-00

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: "Haleplidis Evangelos" <[email-masked]>
Date: Wed, 25 Sep 2013 20:22:10 +0300

Greetings to the list,

Just submitted the new version of the model extension.

After the discussion in the Berlin meeting there are two outstanding issues
to complete the draft. Namely bitmap and LFB properties. 
Based on the excellent meeting minutes I'll recap the discussion and point
the issues.

1. LFB properties.
There are two issues in regards to the LFB properties. 
A. Is there a need for such an LFB properties definition?
I can see the need and it's useful for having these specific LFB properties
and a way to retrieve such properties.
Also as Joel suggested to look for which LFB properties are needed, please
let me know if you require these or any other LFB properties.

B. The ambiguity of path selection using the GET property. GET property
/LFBClass/LFBInstance/IDx, what should it return - property IDx of the LFB
or the whole struct of properties of component with ID x?
A simple solution for this issue would be to explicitly define that the path
data refers to the LFB instead of a component as a path flag in the path
data.

2. Bitmap datatype.
There is a fundamental question whether we actually need a bitmap datatype.
As Joel suggested, it is possible to simulate bitmaps of size up until 64
bits by using the base datatypes. For larger sizes the alternatives are a
struct of basic datatypes to reach the required bits or a table of booleans.
However there is now other way to set/get a single or a set of bits without
having the bitmap datatype.
An additional issue arises with having to define the data packing rule of
transporting the bitmap by the protocol.

I would like the opinion of the working group on these issues to resolve
them. I think that the LFB properties are a nice addition. Bitmap are useful
but not necessary and as they can be simulated, but cannot be explicitly
defined with the model.
	
Regards,
Evangelos Haleplidis.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of [email-masked]
> Sent: Wednesday, September 25, 2013 6:54 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [forces] I-D Action: draft-ietf-forces-model-extension-00.txt
> 
> 
> Please note that it may take a couple of minutes from the time of
> submission until the htmlized version and diff are available at
> tools.ietf.org.
> 
> _______________________________________________
> forces mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/forces

---

From: Jamal Hadi Salim <[email-masked]>
Date: Thu, 26 Sep 2013 11:54:55 -0400

Greetings Evangelos,

Comments below:

> let me know if you require these or any other LFB properties.

In my implementation experience it ends up boiling down to having to implement
stats for _almost every_ LFB I have come across.
As you mention in the draft, in the minimal, the need is for debugability.
In other words, there is a work around today. But if this is such a common need,
I would argue we need it.

> data refers to the LFB instead of a component as a path flag in the path

With "dont change the protocol" approach:
Could we not reserve certain property ids?
Actually come to think of it: Component ID 0 is not used today.
Could we not have "Set/GetPropetyLFBClass/LFBInstance/0/IDx"
kind of semantics to imply we are referring to the property with IDx?

> but not necessary and as they can be simulated, but cannot be explicitly

To answer Joel's and your question: I think these are again commonly used
types, so we may need to define them somehow. Even if it turns out elsewhere
in an informational draft.

One implementation approach i have found Linux uses is by defining two fields.
Lets say i want to define a 32 bit map (in which i wish to specify
"bits to un/set").
Then two 32 bit fields suffice. Call the first 32 bit the "selector".
If you set a bit
in the selector you are indicating that the bit is to be un/set. Then
call the second
32 bit field the "value". As an example, is selector bit 3 is set then
when value
bit field 3 is set, it means I want to set bit 3. If value bit 3 is 0,
it means I want
to unset bit 3. Off the top of my head i cant come up with the right
term for the
logical function that would describe the operation between "selector"
and "value";
(xor or nor seem wrong).
So in the worst case where you want to communicate one bit you waste one
32 bit value compared to boolean. In the best case you are 30 times better in
terms of bit-on-the wire preservation.
You can use the approach for 64 bit(map) etc.
I think Joel's view of bitmap is in a desire not to send all the bits
one is not interested
in setting, but i would argue you cant beat the above in terms of bit
optimization ;->

cheers,
jamal

PS:- I am reading the draft and will provide more comments.

---

From: "Haleplidis Evangelos" <[email-masked]>
Date: Fri, 27 Sep 2013 01:00:55 +0300

Greetings Jamal,

Thanks for the response. Please see inline.

Regards,
Evangelos Haleplidis.

> > B. The ambiguity of path selection using the GET property. GET
> > property /LFBClass/LFBInstance/IDx, what should it return - property
> > IDx of the LFB or the whole struct of properties of component with ID
> x?
> > A simple solution for this issue would be to explicitly define that
> > the path data refers to the LFB instead of a component as a path flag
> > in the path data.
> >
> 

[ΕΗ] I guess we could mandate from this document that Component ID 0 is
reserved. That would certainly solve the issue.

> > As Joel suggested, it is possible to simulate bitmaps of size up
> until
> > 64 bits by using the base datatypes. For larger sizes the
> alternatives
> > are a struct of basic datatypes to reach the required bits or a table
> of booleans.
> > However there is now other way to set/get a single or a set of bits
> > without having the bitmap datatype.
> > An additional issue arises with having to define the data packing
> rule
> > of transporting the bitmap by the protocol.
> >
> > I would like the opinion of the working group on these issues to
> > resolve them. I think that the LFB properties are a nice addition.
> > Bitmap are useful but not necessary and as they can be simulated, but
> > cannot be explicitly defined with the model.
> >
> 
> To answer Joel's and your question: I think these are again commonly
> used types, so we may need to define them somehow. Even if it turns out
> elsewhere in an informational draft.
> 
> when value bit field 3 is set, it means I want to set bit 3. If value
> bit 3 is 0, it means I want to unset bit 3. Off the top of my head i
> cant come up with the right term for the logical function that would
> describe the operation between "selector"
> and "value";
> (xor or nor seem wrong).
> 32 bit value compared to boolean. In the best case you are 30 times
> better in terms of bit-on-the wire preservation.
> one is not interested in setting, but i would argue you cant beat the
> above in terms of bit optimization ;->

[ΕΗ] I agree that this is more optimal but it's not a clean bitmap solution.
However having such a solution that is only 2 times more than the cost of
sending one bitmap, instead of a multiple of 32bits*number of bits may be
preferable than creating a new data packing rule.

---

From: Joel <[email-masked]>
Date: Fri, 27 Sep 2013 04:43:46 -0400

I rather like the idea of taking component 0 and using it to mean 
"this", and that things following that move to the properties side.  So 
an LFB ID with a path starting with 0 means the properties of the LFB, 
and a path to a structure with a following component of 0 means that the 
following components reference the properties of the structure.

Yours,
Joel

---

From: Jamal Hadi Salim <[email-masked]>
Date: Sat, 28 Sep 2013 13:42:17 -0400

On Fri, Sep 27, 2013 at 4:43 AM, Joel <[email-masked]> wrote:
> I rather like the idea of taking component 0 and using it to mean "this",
> and that things following that move to the properties side.  So an LFB ID
> with a path starting with 0 means the properties of the LFB,

Ok, great - so to re-iterate a GET or SETPROPERTY to:

  /FE/x/LFBy/0 accesses "properties of the LFB class y, all instances on FEx"
 /FE/x/LFBy/z where z>0 accesses "properties of the LFB class y
instance z on FEx"

correct?

> and a path to a
> structure with a following component of 0 means that the following
> components reference the properties of the structure.

We dont have a problem there at the moment. A GET/SET property works fine.

cheers,
jamal

---

From: Joel <[email-masked]>
Date: Sat, 28 Sep 2013 13:51:33 -0400

Yep, that is what I was thinking.
Yours,
Joel