Subject: Re: Support for multicast in the ForCES protocol

From: Tal Anker <[email-masked]>
Date: Thu, 20 Nov 2003 01:52:33 +0200

Alan,
Are you suggesting that a network element would not support the regular hot-insertion that is common feature in either chasis or stackable products? 
I don't think that learning dynamically on new FE's would make the overall solution too complex.
 
As for performance (one of the previous mails, I think it was Joel's)... We should assume that some NEs would need to support big IP routing tables (or for that matter, big layer2 forwarding table in the case of a router/switch NE). The number of elements (routes, L2 fwd entry, etc) that can be installed on many FE's per socond would definitely call for multicast, as many point-2-point "connections" would be a bit problematic...
 
One last issue... the semantics needed from the transport layer should be carefully defined, as regular multicast is not reliable, and I expect the protocol to rely on some reliable transport in order to know the CE-FE transaction is commited... the RMT WG had defined tools for reliable multicast that can be deployed here...
 
- Tal

	-----Original Message----- 
	From: Alan DeKok [mailto:[email-masked]] 
	Sent: Wed 11/19/2003 11:58 PM 
	To: [email-masked] 
	Cc: 
	Subject: Re: Support for multicast in the ForCES protocol

	Sandy Pavel wrote:
	>
	> Static multicast group membership sounds to me as being acceptable and
	> therefore there is no need to have a group membership management
	> protocol.
	
	  Multicast issues can be addressed via administrative issues above
	ForCES.
	
	  That is, assuming that there *is* a multicast-capable transport under
	ForCES, a "multicast" update can simple appear to ForCES to be another
	FE.  The system administrator would be responsible for maintenance of
	multicast group membership.
	
	  This approach can avoid a lot of the issues surrounding multicast in
	ForCES, but may not avoid all of them.
	
	> Functionally the multicast/broadcast is not necessary; it is merely a
	> mechanism that allows for efficient use of the transport technology and
	> _scalable_ router architectures.
	>
	> This is especially valid in core router space but less important in
	> enterprise.
	
	  It's also important for latency, which may be an issue.
	
	  Alan DeKok.

---

From: Steven Blake <[email-masked]>
Date: Wed, 19 Nov 2003 19:03:58 -0500

On Wed, 2003-11-19 at 18:52, Tal Anker wrote:

> One last issue... the semantics needed from the transport layer should be
> carefully defined, as regular multicast is not reliable, and I expect the
> protocol to rely on some reliable transport in order to know the CE-FE
> transaction is commited... the RMT WG had defined tools for reliable multicast
> that can be deployed here...

This is actually orthogonal to multicast transport (reliable or
otherwise).  The fact that a reliable transport delivered a command
message from a CE to a FE is insufficient to indicate to the CE that the
command can and has been executed successfully by the FE.  So the ForCES
protocol will need to support application-layer acknowledgements of some
variety.

Regards,

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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 19 Nov 2003 23:29:52 -0500

This is one of the complexities.  While there is a lot of useful
experimental work on reliable and secured multicast transport, I do not
believe that there is any engineering grade work that address both those
requirements.  And we are obliged to meet both of those needs.
And compared with TCP / SCTP, there are not wide spread, easily available,
well wrung out implementations of those protocols.
Hence, putting a dependency on such work into ForCES introduces significant
risk and complexity.

Yours,
Joel M. Halpern

At 01:52 AM 11/20/2003 +0200, you wrote:
>transaction is commited... the RMT WG had defined tools for reliable
>multicast that can be deployed here...
>
>- Tal

---

From: Robert Haas <[email-masked]>
Date: Thu, 20 Nov 2003 12:05:27 +0100

> Hence, putting a dependency on such work into ForCES introduces 

I don't think we are talking about putting a dependency on RMT here. 
Rather we are ensuring that the necessary hooks are in the ForCES 
protocol so it can make use of some form of multicast transport.

And to do this, we need to have some form of group addressing at the 
ForCES protocol level. Having spent some cycles on this, I can say it 
requires a bit more than "rearranging the FE ID bits to have some 
group-like meaning after the ForCES protocol has already been designed" 
(I think I heard sth along these lines on the list).

Cheers,
-Robert

-- 
Robert Haas
IBM Zurich Research Laboratory
Säumerstrasse 4
CH-8803 Rüschlikon/Switzerland
phone +41-1-724-8698  fax +41-1-724-8578  http://www.zurich.ibm.com/~rha

---

From: Alistair Munro <[email-masked]>
Date: Thu, 20 Nov 2003 11:49:02 -0000

Hi Robert,

> And to [ensure that the necessary hooks are in the ForCES protocol so it
> can make use of some form of multicast transport], we need to have some
> form of group addressing at the

I certainly think it would be good to be able to multicast/broadcast to
LFBs via the ForCES protocol at application level. I don't see what this
has to do with multicast *transport*. Could you explain how you would make
the application layer FE LFB hooks visible at transport level?

Regards,

Alistair

--
Alistair Munro,
Principal Engineer, U4EA Technologies Ltd.
City Point, Temple Gate, Bristol, BS1 6PL, U.K.
E-mail: [email-masked]
Tel: (work) +44-117-373-6765, (home) +44-1275-462707, (mobile)
+44-7974-922-442;
Fax: +44-117-373-6751
Web: http://www.u4eagroup.com

---

From: Robert Haas <[email-masked]>
Date: Thu, 20 Nov 2003 13:56:26 +0100

Hi Alistair,

Alistair Munro wrote:

> has to do with multicast *transport*.

Nothing and you are absolutely right. I only say that if one has group 
addressing capability at ForCES level, then one can consider making use 
of multicast transport. The multicast transport stops at the FE door (IP 
endpoint if running over IP), any other "multicast" further into FE LFBs 
must be handled by ForCES itself.

> Could you explain how you would make

Nobodoy wants to assign an IP address to each LFB, and it is good so. 
Therefore, grouping of LFBs is only visible at the ForCES-level 
addressing. The underlying mutlicast transport is merely a way to get 
closer to the LFBs up to the FE door, potentially saving substantial CPU 
and bandwidth resources.

Regards,

---

From: Jon Maloy <[email-masked]>
Date: Thu, 20 Nov 2003 10:34:13 -0500

You are right,
multicast as seen from user level does not necessarily
have anything to do with multicast at the transport level.
What the user wants is "application level" multicast to conveniently
send a message to a number  of  LFB's, irrespectively of
where they are located. He does not care about how this is
implemented by the base protocol.

Transport level multicast is a completely different thing, and only
serves the purpose of speeding up the transfer process while using
the system resources as efficiently as possible.
However, true transport level multicast/broadcast can only be used if
application level multicast is supported by the API.

Hence, as I see it, user level multicast must be a mandatory service
provided by the base protocol, while transport level multicast may
remain an option, useful, but not strictly necessary in small NE:s.

In general I think that the benefits of transport level multicast/broadcast
is overestimated, given modern CPU speeds and transport bandwidth.
Up  to a few dozen FE:s  a 'replicast'  implementation would be
adequate, but
the requirements are talking about _hundreds_ of FE:s, so, yes, transport
level multicast/broadcast is probably needed at longer term.

/Jon

---

From: Alan DeKok <[email-masked]>
Date: Thu, 20 Nov 2003 12:20:52 -0500

> Are you suggesting that a network element would not support the regular hot-insertion that is common feature in either chasis or stackable products?

  Not at all.  I'm just saying that complex configurations are more
easily managed by system administrators, than by the CE.

  Alan DeKok.

---

From: Weiming Wang <[email-masked]>
Date: Sat, 22 Nov 2003 12:38:46 +0800

Hi Rob,

I remember we'v  had a short discussion on the broadcast/multicast issue in Minn.
I agree that it's not just as simple as to arrange FE IDs, but I still think that the left
is in the encapsulation scope.  Maybe we need a specific definition document for this
 scope. 

 I also argue that the hooks in ForCES protocol for the multicast encapsulation
should be limited to FE IDs instead of LFB types, leaving later as hooks only inside one FE. 
For I'm still not sure how an LFB type can be used directly as hooks for the multicast, it seems
a little case specific. Maybe I miss something. 
Thank you.

Weiming

----- Original Message ----- 
From: "Robert Haas" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, November 20, 2003 7:05 PM
Subject: Re: Support for multicast in the ForCES protocol

Cheers,
-Robert

---

From: Weiming Wang <[email-masked]>
Date: Sat, 22 Nov 2003 12:58:28 +0800

Hi,

The following is an updated version of GRMP:

http://www.ietf.org/internet-drafts/draft-wang-forces-grmp-01.txt

The main modification in the update is that the LFB topology representation part is excluded from the
document, and  will be moved to the draft "Topology representation for FE model" that
will be updated soon. The purpose for this modification is that the author(s) think it more reasonalbe to 
to have all discussions related to LFB topology representaion in the FE model scope instead of in 
ForCES protocol scope, so that the later ForCES discussion can be more concentrating.

Best regards,

Weiming

---

From: Robert Haas <[email-masked]>
Date: Mon, 24 Nov 2003 16:51:28 +0100

Hi Weiming,

>is in the encapsulation scope.  Maybe we need a specific definition document for this
Could you elaborate what encapsulation scope means ?

>a little case specific. Maybe I miss something. 
I was considering the basic scenario of a distributed router for which a 
forwarding table must be replicated and maintained over many FEs. 
Imagine a CE can produce a message such as "send this forwarding 
table/updates to all LFBs that peform IPv4 forwarding (optional: in a 
particular virtual network)".  This is why I consider this "addressing 
by type" a basic functionality that the ForCES protocol should suppport, 
as it greatly simplifies how to use the protocol. Indeed, there is no 
need for the application to first figure out the specific LFB IDs that 
have been assigned to the IPv4 LFB, nor the particular FE IDs.

Regards,
-Robert

---

From: Weiming Wang <[email-masked]>
Date: Tue, 25 Nov 2003 22:51:32 +0800

Hi Rob,

Pls see inline reply.

----- Original Message ----- 
From: "Robert Haas" <[email-masked]>
To: <[email-masked]>
Sent: Monday, November 24, 2003 11:51 PM
Subject: Re: Support for multicast in the ForCES protocol

Hi Weiming,

[RE] I'v just posted a mail on this. Pls refer there.

[RE]I think we'v come to the same question as Jamal and David are discussing. I'l read your document more
to understand it.  

Regards,
-Robert