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

Hormuzd,

On Wed, 2004-03-10 at 03:20, Khosravi, Hormuzd M wrote:
> 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.

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

> FEC or FE component is nothing but an abstraction of FE functionality
> 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
> 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. 

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

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

_______________________________________________
Forces-protocol mailing list
Forces-protocol@ietf.org
https://www1.ietf.org/mailman/listinfo/forces-protocol