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

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Wed, 10 Mar 2004 00:20:50 -0800

Hi Jamal

This issue is very fundamental and should be resolved before we move
forward. I see what youre saying about FEC, CEC and remember having
worked on these concepts while co-authoring the original netlink RFC
with you.

FEC or FE component is nothing but an abstraction of FE functionality
just like LFBs. You seem to have distinguished them below giving a 1:n
example but fundamentally both are abstractions. The ForCES WG and Model
team have decided on using LFBs as a way to abstract FEs and we
(protocol team) should stick to that. I don't see the value of adding
another layer of abstraction over LFBs, your case for FEC/PID seems very
implementation specific to me.
Actually, I am surprised that you are bringing this up cause I remember
the netlink2 team having clearly stated during one of your IETF
presentations that you will be updating netlink2 terminology to be
inline with the model and replace FEC with LFB in your draft, infact I
believe you did this.

Anyways, the other issue is of having LFB IDs or types in the common
header.
I don't think this is needed for the following reasons..
1. Not all messages are addressed to LFBs
2. Some messages are addressed to multiple different LFBs (command
bundling)
3. It's a good design practice to separate the LFB type/ID namespace
from FE ID, CE ID namespace as David suggested.
4. I don't see how anything will break if LFB type/IDs are part of TLVs
following the common header.

I think there is a common understanding between the FACT and GRMP teams
on this issue and I hope we can all reach a common view on this soon
before moving forward.

Regards 
Hormuzd
p.s. I am sure we will easily reach a conclusion on the length of the FE
ID, CE ID once we agree on the semantics.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Jamal Hadi Salim
Sent: Monday, March 08, 2004 5:04 AM
To: [email-masked]
Subject: Re: [Forces-protocol] Issue 0: Application addressing

Hormuzd, Weiming,

Apologies for long email; i am attempting to respond to two emails in
one.

Ok, let me provide an example of an FE (same concept applies at
the CE). 
Heres a diagram that may help to clarify what i have been refering
to; note that netlink2 did not start like this, however over
time implementation ended being like this; this shows an FE
side implementation. I have attached the two diagrams so they
dont get mangled.

Figure 1. shows the netlink2 manager ( a s/ware daemon) managing
two socket connections on the lower side labelled as wire0 and wire1
and entities called FECs on the upper side.
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.
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.

Although i only list two classes, there could be more - but thats beside
the point.
FECs are OS processes/applications. (How they communicate to the
netlink2 daemon is beyond the scope of ForCES; lets say it could be a
local OS IPC.)

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.

Now to address your emails:

On Mon, 2004-03-08 at 00:07, Wang,Weiming wrote:

Weiming, could you make sure your emails wrap around at 80 characters?
It helps when i am trying to respond.

> We think a layer-based tree structure according to the ForCES
architecture 
> is efficient to do such addressing. If we address entities at
> the FE coarse layer ( to take the FE as a whole entity, which idea is
also 
> used by new version of FE model ), we only need to 
> have a FE ID.  

If i am not mistaken what you are talking about is a detail
on how the address gets split; i.e you want to have a hierachical
addressing - as an example you want to split the address above to
FEx:FECx or CEx:CECx (refer to the meanings of CEC and FEC above).
If this is the case, i think it is a small detail and we could move
on and talk baout it later; if not please look at the diagram and 
tell me how you would split the ID to configure LFB0. I actually have 
a feeling your approach to this would be VERY different from Hormuzd ;->

>  To address 
> CEs, we use CE ID.  By defining IDs for FE broadcast, LFB broadcast,
LFB 
> Instance broadcast, and CE broadcast, following addressing can be 
> implemented:

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

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

On Mon, 2004-03-08 at 01:54, Khosravi, Hormuzd M wrote: 

> [HK] Great, seems like Weiming would also prefer CE, FE ID. Can we go
> with that terminology then?

Lets talk about what needs to be addressed first before we jump to that.
Refer to the two diagrams i sent.

> [HK] I don't see the value of having an App ID in the common header.
How
> is it useful ? May be if you could give a good example of how this can
> be used, it would help. The ForCES endpoints are CEs and FEs which
> should be addressed in the common header. LFBs are like knobs on the
FEs
> used to program its functionality. I am sure you know all this very
well
> and I think most folks will agree on this. If we go with a different
> view, we will probably land up breaking the FE Model as well. Other
> views on this one ?

Refer to the two diagrams i sent for an example, then lets discuss.

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

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

Again, apologies for long email; hopefully this would group
things together.

cheers,
jamal

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

---

From: Jamal Hadi Salim <[email-masked]>
Date: 10 Mar 2004 06:48:06 -0500

Hormuzd,

> worked on these concepts while co-authoring the original netlink RFC

I can see where the confusion is.
The names are maintained as in netlink (just like PID was) - the
architecture described is NOT related to what is on netlink. 

I can change the name to FEA - for FE Application. However,
this is an implementation detail (and i am not sure it even belongs
in a draft).

> just like LFBs. 

Its merely an implementation detail. The desire
is to have multiple addressable entities. Given you saw it as a
netlink FEC, i would suggest you revist my original posting (or just
go by what i am describing here).

> You seem to have distinguished them below giving a 1:n
> (protocol team) should stick to that. 

Again, its an implementation (abstraction) detail. The closest thing (in
modelling - not sure if it is in the model draft) an FEC comes to
is a proxy for LFBs. 
Lets me ask this: how many _types_ of entities as addressable via the ID
do you see? It seems to me you are saying theres only one (example the
FE).

Since the issue of the model draft keeps coming up, heres my opinion:
I honestly dont care what the model draft says; it should be used
as a guideline and not as dogma - we are here to decide on a good
design of a ForCES protocol; if theres something that needs fixing
on the model draft then it should be fixed. I dont see this issue
as something that would need to be fixed on that draft.

> I don't see the value of adding

This detail was not on the Netlink2 draft. Grab the last netlink2 draft
and grep for FEC and you will not see a single occurance.
LFB is NOT an FEC. FEC is an application that is NOT on the data path.
LFB is on the datapath. 
Can you clarify how you implemented? Maybe this would help. 

>From your email i am coming to the conclusion that our main difference
seems to be the target of the destination of the ID. In your view theres
only one class of destination, the members of the class being either an
FE or CE. In my view i see it as an application (in the same philosphy
as TCP/UDP ports) and there could be many of those in the FE or CE.
I think we can make progress if at least see our differences; did
i capture your opinion correctly?

I will split the email here for readability. 

cheers,
jamal

---

From: Jamal Hadi Salim <[email-masked]>
Date: 10 Mar 2004 07:00:01 -0500

Part 2.

> Anyways, the other issue is of having LFB IDs or types in the common

I said no such thing. I think you may be thinking of Weiming who
has suggested the target of an ID as [FE ID: LFB ID: LFB Instance ID]

> following the common header.

I think it is becoming clear that our diference maybe what is the
target of the ID. Can you clarify how many _types_ of targets do you see
addressable.
Weiming, can you clarify on your side as well? I think this will help us
settle faster.

> on this issue 

You keep saying this but i dont think theres any commonality between you
and GRMP on this issue;-> You may have missed Weiming saying
things are addressed by: [FE ID: LFB ID: LFB Instance ID]

> and I hope we can all reach a common view on this soon
> before moving forward.

Indeed.

cheers,
jamal

---

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

Jamal,

It seems you are proposing a way to address components all the way to 
process level?
Hmm..  Here are some problems I see with that:
1)  The number of proceses running in an FE and the corresponding 
Process IDs are
      are arbitrally  assigned by the native OS on that FE.  Thus, FEA 
from vendor A and
      FEB from vendor B providing the same capabilities will most 
probably have entirely
      different process ID maps while running. If your CE wants to 
address common LFBs
      in these FEs, which processID are you going to use in your header?

2)  ProcessIDs are very low level identifiers. They probably map to 
certain ports, and
      based on the implementation , you can have more than process map 
onto the same
      port ID.  This complicates the scenario even further.

So,..why are we wasting all the bandwidth talking about addressing 
processes?  It  really
has no value. Let the OS resolve what process gets what message.

Regards,
Alex.