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

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Wed, 10 Mar 2004 13:41:12 -0800

Jamal,

It seems like there is a typo below, I didn't notice it before.
I am agreeing to FEID:LFBTypeID:LFBInstanceID scheme being
proposed for the protocol and model.

Thanks for clarifying this,
Hormuzd

-----Original Message-----
From: Jamal Hadi Salim [mailto:[email-masked]] 
> 
> As Jamal asked, I'll first clarify what the tree
> FEID:FETypeID:FEInstanceID

> [HK] I definitely agree with Weiming on this addressing scheme and how
> to place it in the protocol. This is same as the FE Model and I don't
> see any issues with this scheme.

Hormuzd,
What is it that you are agreeing to? is it the
FEID:FETypeID:FEInstanceID or FEID:LFBTypeID:LFBInstanceID scheme
he described?

cheers,
jamal

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

---

From: "Wang,Weiming" <[email-masked]>
Date: Thu, 11 Mar 2004 11:16:36 +0800

Hi Jamal, Hormuzd,

It's just a misprint of FEID:LFBTypeID:LFBInstanceID. Does
FEID:FETypeID:FEInstanceID really mean something?

Weiming
----- Original Message -----
From: "Khosravi, Hormuzd M" <[email-masked]>
To: <[email-masked]>
Cc: "Wang,Weiming" <[email-masked]>; <[email-masked]>
Sent: Thursday, March 11, 2004 5:41 AM
Subject: RE: [Forces-protocol] Issue 0: Application addressing

Jamal,

-----Original Message-----

Hormuzd,

cheers,
jamal

---

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

Weiming,

> FEID:FETypeID:FEInstanceID really mean something?

FEID and FEInstanceID may have valid meaning; in any case check the
discussion so far.
One thing i would like to ensure we have lost in all that discussion
is the semantics of multi/uni/broadcast IDs with ID being
FEID:LFBTypeID:LFBInstanceID

I believe we are all in agreement on the need for that unless i am
mistaken.

cheers,
jamal

---

From: "Wang,Weiming" <[email-masked]>
Date: Thu, 11 Mar 2004 13:55:20 +0800

Hi Jamal,

To be hornest, we (GRMPs) have originally mainly considered the
unicast/broadcast implementation based on FEID:LFBTypeID:LFBInstanceID, which
can be shown as below:

Firstly, we define three sepcific IDs for broadcast: FEID=0xffff,
LFBTypeID=0xffff, LFBInstanceID=0xffff
Then,
. to address all FEs regarding the FE coarse layer manangement, just use
FEID=0xffff
. to address one LFB in one FE, use FEID:LFBTypeID:LFBInstanceID
. to address all LFBs with the same type in one FE, use FEID:LFBTypeID:0xffff or
just use FEID:LFBTypeID
. to address all LFBs with the same type in all FEs, use 0xffff:LFBTypeID:0xffff
or just use 0xffff:LFBTypeID
. to address all LFBs with all types in one FE, use FEID:0xffff:0xffff, or just
use FEID:0xffff
. to address all LFBs with all types in all FEs, use 0xffff:0xffff:0xffff, or
just use 0xffff:0xffff

Because the three broadcast IDs is explicitly defined in the protocol, and all
CEs and FEs with different vendors can understand it without any further
information change between CEs and FEs, the above broadcast scheme can be
implemented quite conviniently. Moreover, the above broadcast scheme has truly
powered the addressing mechanism greatly, and we think it has met most ForCES
requirements for fast and group addresssing.

On multicast, one possible approach is to define GroupFEID (as mentioned by
latest version of FACT), GroupLFBTypeID and GroupInstanceID. But generally,
these group IDs will not be explicitly defined in the protocol, therefore, an
exchange for such multicast IDs between CEs and FEs are required. For group FE
ID, a something like "hook" (we actually have mentioned this earlier in the
ForCES list) is needed to map the ID into transport layer multicast ID. When we
deeply consider these group IDs, we find that its really unwise to stretch the
multicast to LFBInstance layer, which may just burden us too much while the
reward is less. Therefore, the most possible multicast will happen at FE layer
and LFBType layer.

Anyway, I agree with Jamal that we need to discuss this in the addressing issue
instead in the issue 3.

BTW, Jamal, I'm supprised it seems you can work almost 24H a day, though I'v
been working more than 12H a day. :)

Yours,
Weiming

---

From: Jamal Hadi Salim <[email-masked]>
Date: 11 Mar 2004 06:28:08 -0500

Weiming,

> LFBTypeID=0xffff, LFBInstanceID=0xffff

In the general principle this is what netlink2 does as well.
Note i am trying to adjust my thoughts to the new scheme compared to
exactly what we did, so thanks for posting this.

> . to address all FEs regarding the FE coarse layer manangement, just use

Makes sense

> . to address one LFB in one FE, use FEID:LFBTypeID:LFBInstanceID

Unicast essentially

> . to address all LFBs with the same type in one FE, use FEID:LFBTypeID:0xffff or

could translate to update attribute X on all LFBinstances on this LFB
for this FEID.

> or just use 0xffff:LFBTypeID

Sensible.

> . to address all LFBs with all types in one FE, use FEID:0xffff:0xffff, or just

When would this be useful?

> . to address all LFBs with all types in all FEs, use 0xffff:0xffff:0xffff, or

When would you wanna do this?

> information change between CEs and FEs, 

Static definition of broadcast is well understood. 
Let me cut the email here and address the other issue in a separate
email.

cheers,
jamal

---

From: "Wang,Weiming" <[email-masked]>
Date: Thu, 11 Mar 2004 19:38:46 +0800

Jamal,

----- Original Message -----

> When would this be useful?

[Wang Re: For very simple instance, something likt to start or stop all LFBs]

> When would you wanna do this?

[Wang Re: as above]

> Let me cut the email here and address the other issue in a separate
[Wang Re: Agreed, we need to hurry up.]

Cheers,
Weiming

---

From: Jamal Hadi Salim <[email-masked]>
Date: 11 Mar 2004 07:02:45 -0500

Weiming,

On Thu, 2004-03-11 at 00:55, Wang,Weiming wrote:

> exchange for such multicast IDs between CEs and FEs are required. 

I dont see much difference from std multicast. The FEs and CEs
will need to "join" groups already predefined (although the groups could
be dynamically defined at the cost of adding some complexity).  

> For group FE
> ForCES list) is needed to map the ID into transport layer multicast ID. 

The application level multicast should NOT be dependent on transport
level multicast. i.e you should be able to use unicast transport with
multicast or broadcast at the app level.
Lets get to the transport, their mappings and semantics on issue 2.

> When we

Sounds sensible. Experience may change that view.

> been working more than 12H a day. :)

Some people have accused me of having a presence of 25 hours a 
day;->. Alex has infact insuniated i dont have work and on the other
extreme some customers have wondered if i was a department of people;->
But if you think i have clones (in case you are following some of my
Linux activities or have figured out that i have a new baby) wait until
you meet more interesting people like Alan Cox.

On a serious side, i am trying my best to make concessions whenever
sensible and speed up the process so we can move on. I have this list as
about the same priority as the one i use for our customers at the
moment.

cheers,
jamal

---

From: Alex Audu <[email-masked]>
Date: Thu, 11 Mar 2004 11:38:26 -0600

I agree, ..I don't see any need for GroupFEID, and other such group IDs.

Alex.