Subject: RE: [Forces-protocol] Comments from chat with ADs

From: [email-masked]
Date: Fri, 5 Mar 2004 18:13:06 -0500

Hello Jamal,

FEM/CEM interface and message description is outside the scope of the ForCES framework. I'm not sure why we to deal now within our scope?

The initial configuration like FE and CE endpoint and other vital information are pre-configuration and is outside the scope
how we do it either thro' CLI or SNMP or ????. 

Regards
Ramg

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of ext Jamal 
> Hadi Salim
> Sent: Friday, March 05, 2004 4:39 PM
> To: [email-masked]
> Cc: Khosravi, Hormuzd M; Deleganes, Ellen M; [email-masked]
> Subject: Re: [Forces-protocol] Comments from chat with ADs
> 
> 
> Alex,
> 
> Lets just follow the discussion in order of issues, to make faster
> progress.
> One issue at a time. At the end if it is shown that multicast
> has all these problems you say it does, we should probably throw it
> out totaly. All the issues you address are listed below.
> I sent text on issue 0 yesterday. Hormuzd is sending something
> on at least 2. Maybe i should send on 1. 
> These three are the easisest to resolve.
> 
> Here are the issues again (with two new additions at the end):
> If you ahve any that are missing here, please make suggestions.
> 
> 0) ID on the header.
> 1) Encoding
> 2) Multiple channels/connections
> 3) Transport: unicast/multicast/broadcast 
> { TCP, UDP, SCTP, DCCP, Direct over L2 or proprietary 
> backplanes, TIPC} 
> 4) Congestion control
> 5) Reliability
> 6) Security
> 7) High availability
> 8) Capability exchange
> 9) The FEM/CEM interface
> 
> cheers,
> jamal
> 
> On Fri, 2004-03-05 at 16:26, Alex Audu wrote:
> > I still maintain that MULTICAST is best left at SHOULD implement
> > strength.  Why?
> > A lot of issues are still unresolved concerning multicast
> > reliabililty, security, etc., unless
> > we want to define an application-layer method to resolve 
> issues like 
> > synchronization,
> > packet-loss, ACK/NACK implosion, etc.  
> > 
> > Alex.
> > 
> 
> 
> 
> _______________________________________________
> Forces-protocol mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/forces-protocol
> 

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

---

From: Jamal Hadi Salim <[email-masked]>
Date: 05 Mar 2004 21:10:44 -0500

Ram,

WB.
David beat me to the answer. I added that because it seems
that some of the issues we are discussing belong there.
For example: It seems to me like it is easier to just select
via config if multicast or unicast should be supported.
And if it says "config" then it means FEM/CEM. That is not to
say that FEM or CEM has to be static; there could be a dynamic protocol
(we implemented something proprietary that works with SLP) - in
which case the selection/negotiation for multicast/unicast etc is done
more intellegentelly. Yes, this is outside the scope. By moving
it out of the protocol it makes it simpler imo.

In any case, since you are recharged from vacation, can we follow
through that list? My opinion is we can progress faster this way.
I put out some text issue 0 and issue 1.
We should probably beat one issue at a time. But we should be able to
attack several at a time. I feel it is easier to have each topic on a 
separate email thread.

cheers,
jamal