Subject: Re: ForCES transport requirements WAS (Re: Support for multicast in the ForCES protocol

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Mon, 24 Nov 2003 12:35:13 -0800

Hi Tal

There is already a ForCES Requirements draft which has been approved for
RFC.
Pls see...
http://www.ietf.org/internet-drafts/draft-ietf-forces-requirements-10.tx
t
This has a section on protocol requirements.

regards
Hormuzd
-----Original Message-----
From: Forwarding and Control Element Separation
[mailto:[email-masked]] On Behalf Of Tal Anker
Sent: Sunday, November 23, 2003 11:03 PM
To: [email-masked]
Subject: Re: [FORCES] ForCES transport requirements WAS (Re: Support for
multicast in the ForCES protocol

All,
I do believe that this thread should converge to _some_ result...
I think I remember someone saying he is writing a draft to capture all
the issues with multicast and forces...I believe this is a good
direction (maybe the draft can also indicate requirements of the forces
protocol so that it can later work over [reliable ?] multicast
transport...). Why don't we wait for the draft to be available (or is
there a time issue here that I am not aware of... - assuming the draft
would not take too long ...).
 
- Tal

        -----Original Message----- 
        From: Jamal Hadi Salim [mailto:[email-masked]] 
        Sent: Mon 11/24/2003 6:13 AM 
        To: [email-masked] 
        Cc: 
        Subject: Re: ForCES transport requirements WAS (Re: Support for
multicast in the ForCES protocol

        On Sun, 2003-11-23 at 22:37, Khosravi, Hormuzd M wrote:
        > I don't see why this has to be a religious debate.
	
        It is when you discuss for a long time and reach the same
        conclusion you both had when you started.
	
        > No body is saying "unicast is good, multicast is evil"
        > This should not be the approach for making technical
decisions.
        > Unicast and multicast both have their merits and drawbacks
        > and we have to select one that best meets our needs.
	
        Do you think TCP satisfies all the requirements?
        Please read my email on this topic before responding. It will be
        that religious discussion i am talking about if you dont read
the
        emails.
        BTW, When did we say we have to choose one over the other?
        Could they both be supported maybe?
        This is a config issue. Noone has ever ruled out unicast. I dont
        understand why you are so adamant on ruling out multicast. Let
me guess:
        could it be because FACT doesnt support it?
	
        > Unicast has been working well for a long time in
client/server,
        > Master/slave type of environment. Multicast fits well for
        > Peer-to-peer environment. ForCES is clearly a master/slave
        > environment, where the CE is the master or controller and
        > the FE is the slave or the element being controlled.
Hopefully,
        > there should be no disagreement on this basic idea. In
addition,
	
        Multicast typically has a sender (the CE in this case mostly)
and one
        or more receivers (the FE in the case of ForCES). The FE could
send an
        unsolicited event. Whatever terminology you end up calling such
        a setup is unimportant.
        I am just curious why you are bringing this topic?
	
        > we have certain reliability and security requirements that
need
        > to be fulfilled.
	
        And they are being met.
	
        > On the issue of scalability let me try to give an example
which
        > will bring to light the importance of congestion control. OSPF
has
        > been stated as one of the main examples of a protocol which
uses
        > multicast as one of its transports in multicast enabled
networks.
        > One of the current OSPF WG drafts...
        >
http://www.ietf.org/internet-drafts/draft-ietf-ospf-scalability-06.txt
        > Talks about recommendations for improving OSPF scalability in
large
        > networks. It specifically recommends prioritization and
congestion
        > avoidance procedures to help improve the scalability. This
draft is
        > not just based on implementation, but also deployment
experience by a
        > large operator (AT&T).
	
        Good, we can learn from it. How exactly does this say multicast
is bad?
        I did search for the word multicast on that draft and it is not
        mentioend once. But you are probably refering to it because OSPF
uses
        multicast - I would say it is a good proof there is something
good about
        multicast.
	
        cheers,
        jamal

---

From: Steven Blake <[email-masked]>
Date: Mon, 24 Nov 2003 21:19:49 -0500

> This has a section on protocol requirements.

The problem with this draft (IMHO) is that it specifies a very broad
range of requirements, and it is not clear that they can all be
satisfied simultaneously using the same protocol techniques (which is
not to say that they cannot be satisfied using the same protocol, it
will however have to be very flexible).

Another problem is that there is no prioritization applied to the
requirements.  Therefore, different individuals prioritize them
independently based on their own priorities and product requirements.

I personally prioritize scalability and timeliness, and really have no
use for the security requirement, because I don't envision having to
deploy CE-FE communications over an open network.  Other opinions may
differ.

Regards,

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Steven L. Blake               <[email-masked]>
Ericsson IP Infrastructure                +1 919-472-9913