Subject: LFB data sharing proposal/suggestion/discussion

From: Jamal Hadi Salim <[email-masked]>
Date: Fri, 17 Dec 2004 16:10:10 -0500

Folks,

Steve/Zsolt wrote a draft on this topic - and Steve presented on it; so
i wont go justfiying its need[1]. Summary: LFB instances may need to
share attributes.

A simple example:
- A nexthop id in a LPM LFB instance pointing to a NH table entry
in the NH LFB instance in the same LFB instance topology.
 
My recommendation is to change the LFB schema a little to allow soft
links (like unix file symbolic links thought mentioned in the draft for
simplicity sake). 
As in symbolic links: 
a) multiple links (from one or more LFB instances) can point to the real
data/attribute. 
b) you need permission to read/write the data; the ACLs we use may have
to be modified a little to allow for multi user access control.
c) The data is held and owned by one LFB instance.
d) The data may be deleted at the owner LFB instance location and leave
dangling links. This has repurcasssions: I think you could use
bidirectional pointers (such as those used in SNMP port stacking) but
the complexity is not worth it IMO.

So heres how this works:
- "participating" attributes/data are going to be either "shared" or an
"alias". **This is the first change needed to the schema**.

Example the nhid in a LPM LFB instance pointing to a NH table entry
would be marked as aliased and the real data in the NH LFB would be
tagged as "shared". 
An attribute not tagged with either shared/alias is essentially local to
the LFB instance (and not "exported/imported"). 
ACL on the attribute would further refine how shareable it is. The
tagging of whether they can be shared or aliased is done at xml
definition time.

+A shared attribute may need to have some user(reference)count if you
want to do it sanely - although i dont think it is necessary since this,
like the port stacking approach, would add a lot more complexity.

+ An alias would have a alias-path constituting a LFBSelector:path
combination to where the real shared attribute sits. 
So for example if a NH entry being refered to is to be found in NH LFB
instance 10, path = { 1.2.3.4} then the LPM NHindex alias would refer
to: NH:10:{ 1,2,3,4} 
Essentially it is a pointer to the real data. I left out specifying an
FEID because this would be a violation of layering as well as what we
are doing/chartered.
A speacial section is needed in the LFB template to have these
translation tables. **This is the second change needed for LFB schema**.

The alias-path is set by the CE at runtime upon policy setup i.e linking
together of LFB instances. This detail is implementation specific.

Please comment since I need this soon. I would be more than happy to
discuss/consider any other sanely implementable schemes. I will also
send the schema changes once i get feedback on the idea.

cheers,
jamal

[1]
http://www.sstanamera.com/~forces/Old/draft-blake-forces-attrib-00.txt

On the 3 issues the draft raises - I only wish to solve the shared
attribute challenge. This allows for to reduce the data replication clog
by referencing attributes instead of copying them
(as well as the good reasons outlined in that draft).  
Bundling (of LFB instances in a topology) i believe is a policy issue -
and the protocol already allows for it if you ask it. 
Inter-LFB control comes out to me as an implementatio detail.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 17 Dec 2004 16:32:36 -0500

This looks like a good solution.  I don't think the problem will come up 
very often, but it will arise.

I think that there is one constraint, and a clarification / implication 
that needs to be spelled out, and one way to simplify further the notion of 
what is being referenced:

The constraint is that an alias variable still needs a type.  And the both 
the CE and FE are required to ensure that when creating a soft link it 
points to an instance variable of the right type.  (One could go further 
and have the LFB variable target declared at declaration time, but I think 
that might be too restrictive in some cases.

With that constraint, then we can easily follow paths.
When following an LFB select path, if one arrives at an alias variable, and 
one has not exhausted the path, then one follows the alias.

This leaves open the case when the path references the alias 
variable.  Rather than making special case rules about ~if read, follow the 
alias, if write then replace the alias~ how about just using one of the 
flags associated with the path.  The flag is only meaningful if the path 
terminates at an alias variable.  If unset, the alias is followed.  If set, 
the variable itself (the alias path) is returned.

We will need to define a type construct in the XML library for an alias 
path descriptor.

Yours,
Joel

PS: The "shared" attribute is presumably a hint to the FE that the given 
variable is likely to be referenced by other things.

---

From: Jamal Hadi Salim <[email-masked]>
Date: Fri, 17 Dec 2004 18:00:05 -0500

On Fri, 2004-12-17 at 16:32, Joel M. Halpern wrote:
[..]
> that might be too restrictive in some cases.

I cant come up with a scenario where a shared attribute will be of
different type relative to alias(es). What do you have in mind?

> one has not exhausted the path, then one follows the alias.

nod.

> variable.

You mean path termininating at the variable i think?

>   Rather than making special case rules about ~if read, follow the 

Sounds reasonable to me. This should probably apply as well to the first
(non-terminal) case, no?
When you say "replace the alias" you mean the LFBSelect:path or the data
value at the remote location (as opposed to at the aliased location)?
 
> variable is likely to be referenced by other things.

Are you thinking that "shared" doesnt need any construct in the xml?
Also the other thing is i thought there may be need for is a LFBClassDef
"alias transalation table". From what i read above you seem to be
suggesting putting the alias path within the attribute - which is also
fine if it doesnt complicate things.

cheers,
jamal

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 17 Dec 2004 19:56:27 -0500

We may have different declaration models in our heads.

I am imagining that some structure is declared, looking like:
struct foo
    field1: type1
    field2: type2
    field3: alias tpe3
end

This means that when the struct foo is used in some lfb, or in some table 
in some lfb, that field3 will always be an alias that points to something 
else.  However, the constraint is that whatever field3 points to, it must 
be of type type3.
I think this is an easily met constraint, and result what one might call 
type-sensible behavior.  But since it was not spelled out, I thought I 
should state it.

Then, operationally, when I want to set field3 (i.e. create the alias) I 
issue a PUT, with the "set alias" flag set, and with the path pointing to 
the field3 instance I want to set.
Normally, I will reference field3 (or fields nested within whatever type 
field3 has been declared to be) with normal paths with the flag bit not 
set, in which case the FE controller will follow the alias to find the 
value to be fetched or replaced.

In this model, a shared declaration amounts to saying "this variable can be 
referenced by aliases, as long has they have a suitable type."  While this 
may a mildly useful hint, I am not sure it is worth it.

Yours,
Joel

---

From: Jamal Hadi Salim <[email-masked]>
Date: Mon, 20 Dec 2004 22:04:19 -0500

Joel,
I think we are in agreement - the "shared" hint may not be needed.
Questions/comments for you:

1) We may need a "depends on" similar to the "provides" so the CE
knows if there are dependencies and what to use for aliasing. Eg a LPM
LFB depends on NH LFB.
2) Can we have an update to a single alias infact translate to more than
one attribute being updated in possibly more than one LFB instance?
3) Are you going to update the LFB schema with the results from this
discussion?

cheers,
jamal

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 20 Dec 2004 23:27:17 -0500

Given that the CE can read the aliases, I think it gets the "depends on" 
automatically.  The one implication is that we probably need to be clear 
that the follow aliases bit has no effect on non-alias variables.  That 
way, the CE can fetch a struct which includes aliases, and decide whether 
it wants the alias values or the target values.

Given taht several alias variables can in principle point to the same 
element in some LFB, I guess it follows that a write to that element 
through any one path will appear as a change to all the aliased elements.

Zsolt and I will get this included in the Schema, if the working group 
agrees to it.  (You, me, Zsolt, and Steve are probably not enough voices on 
this one.)  We are working on some other issues, and we need to resolve the 
subscripting mechanisms before we can actually produce an update.
In this particular case, I think the hard part will be the english 
description of the semantics.  The XML is pretty easy.  Even the XML for 
the type for an alias reference will not be particularly difficult (once we 
decide about subscripting).  The path sequence for exaple will simply be an 
octet string.

Yours,
Joel

At 10:04 PM 12/20/2004, Jamal Hadi Salim wrote:
> > > > When following an LFB select path, if one arrives at an alias 
> variable,
> > > and

---

From: Jamal Hadi Salim <[email-masked]>
Date: Tue, 21 Dec 2004 06:27:04 -0500

> it wants the alias values or the target values.

Just to be sure we are on the same wavelength:
I am talking essentially about "dependency resolution" of LFBs. As an
example, assume the LPM LFB cant be in a policy topology without the NH
LFB being in existence. So before even the CE gets to set or read
aliases it would be beneficial to know the validity of a policy
within a topology. You could build the dependencies as part of an
operators contraints within the CE, but i see an opportunity in their
explicit definition within the LFB schema.    

> through any one path will appear as a change to all the aliased elements.

I was thinking more of a "broadcast/multicast" update i.e a sort of
concurent change to several instances of an LFB(s).
Example: if i want to send a message from the CE to set an aliased
attribute X in LFB Y, that the result of that is puking several LFB
Selectors and either sending in one PL message or several 
PL messages ...

> decide about subscripting).  The path sequence for exaple will simply be an 

Sounds good. Please just keep me in the loop because we want to be
implementing this piece starting first or second week of January. 

cheers,
jamal

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 21 Dec 2004 08:21:47 -0500

I doubt that there is any need for broadcast / multicast capability from a 
protocol point of view.
If the LFB represent real things, then these aliases may get complicated to 
implement.  However, I would expect that to be the FE controller's problem, 
not a protocol visible aspect.

Given that the CE knows what aliases are already set up, and is setting the 
aliases for new variables, I think it knows the variables.  Note that when 
necessary a CE can create an LFB(A) without linking it into the data 
path.  Then it can create an LFB(B), set its aliases pointing to A, and put 
B in the data path.  Then, when it is ready, the CE can insert A in the 
data path.  So I think all dependencies can be dealt with.

At the same time, I would hope that the design will be such that aliases 
are sparsely used.   Designing the use of lots of aliases without making 
the CE design a nightmare seems to become more complex as the numbers go up.

Part of the key is to remember (as you and I have discussed off list, but I 
wanted to bring up on the list) that an LFB does not need much in the way 
of "informational" attributes.  If some value is not actually used by an 
LFB, there is no need for the attribute even ifwe are used to associating 
the two pieces of information.

Yours,
Joel

---

From: Jamal Hadi Salim <[email-masked]>
Date: Wed, 22 Dec 2004 11:22:45 -0500

Ok, fine. Without going into any points in your email - for now lets
just keep it simple - experience may show something else.

cheers,
jamal