Subject: RE: [Forces-protocol] Issue 0: Application addressing

From: "Putzolu, David" <[email-masked]>
Date: Tue, 9 Mar 2004 09:04:06 -0800

Hi Jamal.

I think this was the email you where asking for a response
to - my response inline :) 

Jamal wrote >
> Figure2 shows the role of the FEC; it MAY manages one or more LFBs.
> The communication mechanism used there is again beyond the scope of
> ForCES.

I agree, this is implementation specific. Also, the figures where 
a good idea & good way to get the point across.

> Messages arriving at either of the sockets could end up in 
> two sorts of
> general classes of destinations:
> 1) for the FE - in which they are serviced by the netlink2 daemon.
> 2) for any of FEC0 to FECx; in that case the netlink2 daemon 
> multiplexes them to those entities.

Agreed.

> As an example, there may be a FEC which controls several LFBs; 
> Another example is an FEC which sends and receives OSPF hellos.
> Each FEC has a counterpart which understands it on the CE side.
> The CE piece of OSPF (call it CEC) sends messages to
> a specific PID when it wants to talk to the FEC portion (the hello
> offloader).
> As you can see this is application talking to another application;
> this could be looked at as essentially IPC. Therefore the 
> concept of PID
> is useful.

My impression is that the existance of FECs is implementation
specific - i.e. one implementation may have different processes
implementing forwarding. Another may contain all forwarding in
the same process as the one receiving ForCES messages, and another
may have one process per LFB.  The ForCES daemon FEd (that received
the ForCES messages over the wire) would either:
i) consume & act on the message if it is a FE-wide message
   (although it might call some admin process under the covers -
   again implementation specific)
ii) Look at the LFB the message is addressed to, and based
    on that, hand the message to the right LFB, or to the right
    process that owns the LFB. If multiple LFBs are addressed
    in a single message, it might deliver the relevant parts of
    the message to each LFB/LFB container process.  So the FEd
    would probably have a table of LFB --> (how to contact
    process|which API to invoke|what file to write|etc)

Not sure if I am disagreeing with you here or not - trying to
elaborate to see if we have the same idea here :)

> I think we all agree on the broadcast or multicast to a specific
> type of entities.
> 
> >>- a set of LFBs on an FE
> > - a set of LFBs on different FEs 
> > 
> > [Wang Re: Are the set of LFBs of the same type?]
> 
> Yes, example "all IPV4 fwding LFBs" instead of "all LFBs".

It sounds like there are two different kinds of addressing
being proposed here:
i) Single LFB unicasting - this message should only be
   received by/acted on by a single FE in the entire NE
ii) Type-based broadcasting - this message should be received/
   acted on by all LFBs of a specific type

I think there is another kind of addressing needed - call
it type-based multicasting: This message should be received/
acted on by a subset of all LFBs of some type.  As an example,
consider a router that has several line cards, all of which
have an instance of the IPv4 forwarding LFB performing 
forwarding for Internet traffic, and one of the line cards has
an IPv4 forwarding LFB instance performing forwarding on a
company intranet using private addressing.  

> > - proxies for LFBs,
> > - proxies for control application in the form on the CEs, 
> > 
> > [Wang Re:  If ever we have these proxies, are they need to 
> be seen at the protocol layer? 
> 
> No, there is nothing speacial needed at the protocol header. The list 
> was an exhaustive example.
> 
> > Moreover, how about FE proxies then?]
> 
> They dont need to be addressed by anything speacial in the header.

I agree, proxies should be indistinguishable from the
thing they are proxying for.

> [HK] Could you give me an example of why this is limiting? 
> 
> I was refering to the fact that you have a single ID to address
> entities within an FE or CE. In my diagram i am rtying to show theres
> more than one class of end targets. So calling it CEID or FEID
> is limiting.

Is this same ID used to identify LFBs as well?  I guess
I'm not sure what is the right way to do this.  If everything
is in the same namespace, name collisions need to be 
managed (e.g. making sure two entities don't pick the
same ID for themself).

> > I would like
> > to know if using 16 bits would break in some scenarios. If 
> this was part
> > of a TLV I wouldn't care as much, but since this is the 
> common header, I
> > am a bit concerned...acting stingy :-))
> ..
> 
> [HK] Exactly, ForCES has much limited/specific scope (NE) than general
> > purpose middleware such as Corba. You cannot compare these 
> 2 because of
> > the difference in scope.
> 
> I gave the historical experience of PCs (by quoting a naive 
> bill gates), 
> IPV4(by making a mockery over the famous last words that 
> brought IPV6 to 
> the world)  and  now i can add the experience of unix which 
> would have 
> been more interesting with 64 bit PIDs.
> Summary: Nothing would break; however it is useful to learn 
> from history
> and say lets go with something larger.

I can't remember what the 16 bits are referring to.
If it is referring to commands that can be issued to
a FE (as opposed to LFBs) then I think 16 bits is
enough, simply because I think humans are too lazy
to come up with 2^16 different FE commands. 

-David

_______________________________________________
Forces-protocol mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/forces-protocol

---

From: Jamal Hadi Salim <[email-masked]>
Date: 09 Mar 2004 12:47:24 -0500

David,
Thanks for taking the time.

> to - my response inline :) 

Yes, this is it;->

> Jamal wrote >
[Reducing size of email as much as possible as promised; alos breaking
this into two emails]

> specific - 

absolutely; the idea i had was to share an experience to explain
the value for IDs: That a single FE could have multiple addressable
targets.

>  The ForCES daemon FEd (that received the ForCES messages over the wire) 
> would either:

correct.

>     process|which API to invoke|what file to write|etc)

Correct. Again implementation details; 
bottom line of the example was to show the value
of the PID and that it means several processes/threads etc are addressed
within a CE/FE.

cheers,
jamal

---

From: Jamal Hadi Salim <[email-masked]>
Date: 09 Mar 2004 13:03:31 -0500

>    received by/acted on by a single FE in the entire NE

To be precise message is received by a single entity since there could
be multiple entities in the FE.

>    acted on by all LFBs of a specific type

right. All bcast could be directed at the FEs or CEs without
being meant to be for a LFB processing. I could provide examples.

> acted on by a subset of all LFBs of some type.  

Ok, never thought of this one. We didnt implement this but it is
valuable.

> managed (e.g. making sure two entities don't pick the

I was trying to avoid refering to LFBs with the PID and rather restrict
the PID to some OS-process/app such as an FEC. The identity of
an LFB class would be the type field; this way a single OS process may
handle multiple LFB classes.

Let me provide an example walk:
1) FEd receives message. Based on dst PID sends it to the right location
(an app like FEC for example) or consumes it.
2) FEC validates that it can process that message and understands what
LFB/LFBs to muck with. 
3) The decoded TLVs further reference entities
within an LFB class i.e an LFB class essentially owns multiple instances
of that LFB type. FEC now configures LFB.

Now of course you could take the LFB instances such as an
index of a nh table and give that a NE-universal id; but that would
require a huge address space (maybe 128 bits may be insufficient).

Collision resolution can be discussed later; i can explain how we did it
but it is not going to add much value.

> to come up with 2^16 different FE commands. 

reference was to the ID field in the header.
My opinion is given that there is possibility of addressing several
processes per FE/CE, then no harm in using 32 bits. 

Again, bottom line of what i was trying to get through:
- The different addressing schemes in previous email
- That 32 bit ID was reasonable
- That this was one way to implement without trying to enforce it on
anyone.

cheers,
jamal

---

From: "Wang,Weiming" <[email-masked]>
Date: Wed, 10 Mar 2004 21:05:04 +0800

Hi Jamal, Hormuzd, David, and all,

As Jamal asked, I'll first clarify what the tree FEID:FETypeID:FEInstanceID
means.
Firstly, I should say, there are two possible descriptions for such a tree
structure:
The first is to have it as a whole ID and put it at the ForCES message header,
and at the receiver side to resolve it from the head to the tail. I'l call this
as an explicit description. I think Jamal actually means this description.
The second is to have it implicitly described in the ForCES messages. That is,
for instance, to have FEID put in the message header and may have put LFBTypeID
and LFBInstanceID in the message body if needed.

I would say the second method is more flexible and reasonable, and what I mean
is actually the second one.

Then, I have a suggestion that how about Let's try to find out the disadvantages
for the two differenct addressing ways(PIDs based and FEID:FETypeID:FEInstanceID
based),  so that we may compare which is better.

Please alow me first to try to show some limitations when using PIDs based
addressing:

1. In ForCES architecture, it has already assumed that FEs and CEs may be from
different vendors. As a CE that uses ForCES protocol, it has no right to control
how an FE is implemented. This means, one vendoer may prefer to have LFB1 and
LFB2 managed by one process (or say FEC) while another vendor may have one
process (FEC1) for LFB1 and another process(FEC2) for LFB2. I just wonder how in
this case the PID will be uniformly arranged to address the both cases.

2. In the PIDs scheme, it seems there is no idea like LFB type used as
addressing index, all LFBs are actually represented by their instance IDs (which
are defined also as PIDs), and the instance IDs are globally defined within a
NE. This has lead two unhappy things:
1) ForCES user shoud carefull arrange these IDs so that there are no conflict on
the instance IDs in the NE.
2) This has made the broadcast/multicast that is based on LFB types quite
difficult, I suppose David also means this.
On the contrary, in the tree structured addressing, the LFBInstanceID is local
in a LFB type in a FE. Different FEs may use the same LFB instances, and
different LFBs can also use the same instance ID. Therefore it's quite easy to
arrange this IDs. Moreover, the broadcast/multicast based on LFB types can be
implemented very easily in the tree structure addressing just by the use of
FETypeID along with the FE ID as addressing ID.

3. The PIDs scheme also has put more burden on CE. The CE then need to manage a
quite big database of PIDs, which include all managable entities in all FEs as
well as CEs, and the database is basically linearly strucutured. While in tree
structure, the CE only needs to maintain a very simple database for entity
addressing (therorically only need to resolve the FE ID), leaving many ID
resolution tasks done by individual FEs. The cause the tree structure can
achieve this advantage is it actually maps the ForCES FE framework structure
well.

Jamal, I truly hope you may also point out the limitations for the tree
structured addressing way. In this way, I think we may be easier to reach an
agreement.

Yours,
Weiming

---

From: Alex Audu <[email-masked]>
Date: Wed, 10 Mar 2004 13:58:01 -0600

Exactly! This is exactly the point I made in my previous e-mail.

Alex.

---

From: Jamal Hadi Salim <[email-masked]>
Date: 10 Mar 2004 16:28:36 -0500

The one day i decide to not look tons of responses show up.
I like the momentum, please keep it up.
 
> As Jamal asked, I'll first clarify what the tree FEID:FETypeID:FEInstanceID

Initially you said [FE ID: LFB ID: LFB Instance ID]
Is this a typo or are you rethinking?

> as an explicit description. I think Jamal actually means this description.

No - this is not what i was saying. But let me read on.

> and LFBInstanceID in the message body if needed.

Ok, now you are getting back to [FE ID: LFB ID: LFB Instance ID]
I am assuming your earlier description was a typo. I am for putting
LFBInstanceID in the message body for practical purposes (example it
would make sense to have a table entry to hold LFB instance state; and
it would not be unusual to have a million such entries).  

> is actually the second one.

You attributed the first thing as something i said; it may be a
misunderstanding. Let me explain what i said using your description
above:
FEID identifies a termination point on the FE of the consumer of the
message. This would typically be a OS process. I am suggesting there
could in fact be multiple such processes on the physical FE.
The LFBID i refered to as a typeid. 
We went into a small discussion of whether what you refer to as LFBID 
belongs in the header or the body for batching purposes. I pointed out
that there is a threshold point where it would make sense to put it
in either the body or the header - we then defered that discussion.
The LFBInstanceID definetely belongs to the message body.

> based),  so that we may compare which is better.

So now you are back on a different scheme i think. What is a FETypeID?
It seems you may be saying two different things since you are repeating
it again.

> how an FE is implemented. 

Agreed.

> This means, one vendoer may prefer to have LFB1 and

The FEID/PID on a Forces message is static. You seem to be implying it
is the OS PID - it is ABSOLUTELY NOT.
I am trying my best to avoid implementation details; let me say that If
you read Davids response, it is very clear that what the relationship
is. To quote him:

---
The FE daemon would ..
---

> NE. 

You have misunderstood what i said. Read all i have said above and then
lets revisit. Since the rest of your message is derived from this
misunderstanding i will not respond so we can get back in sync.

cheers,
jamal