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

[Alex Audu <[e-mail]>]

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.

Jamal Hadi Salim wrote:

>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
>[e-mail]
>https://www1.ietf.org/mailman/listinfo/forces-protocol
>  
>