Subject: RE: automatic enterprise-scale rendezvous [Re: mboned: Interest in working on multicast address rendezvous?]

From: "Manfredi, Albert E" <[email-masked]>
Date: Wed, 9 Feb 2005 17:24:08 -0500

Beau Williamson wrote:

> At 2/9/2005 03:23 PM, Manfredi, Albert E wrote:
> >But I must be missing something.
> >
> >If you take this approach, then the multicast group won't be 
> >differentiated for these different applications.
> 
> Sure it will.  The Scope Relative address is ONLY used to 
> find the server 
> and REQUEST the information as to what multicast address has been 
> configured (by the network admin) for the application to use. 
>  Assuming the 
> network admin doesn't assign all applications the same 
> multicast address, 
> there isn't a problem.

So you want this well-known enterprise net multicast address only to access the server.

Is this better than a simple unicast session with such a server because the Class D address can become standard in all enterprise nets, where a unicast address would not be?

In IPv6, could an anycast address for such a server be the better (more correct) way to go?

Throughout this thread, I've been thinking that the simplest way to go by far would be for enterprise nets to simply provide a web site where app designers could go. But maybe that's too manual.

Bert

_______________________________________________________________
user interface: http://darkwing.uoregon.edu/~llynch/mboned.html
web archive:  http://darkwing.uoregon.edu/~llynch/mboned/

---

From: Beau Williamson <[email-masked]>
Date: Wed, 09 Feb 2005 16:37:21 -0600

>So you want this well-known enterprise net multicast address only to 

Scope Relative address.  Yes.

>Is this better than a simple unicast session with such a server because 
>the Class D address can become standard in all enterprise nets, where a 
>unicast address would not be?

You can't use unicast. You don't know the address of the server.

>In IPv6, could an anycast address for such a server be the better (more 

No.  This has nothing to do with anycast.

>Throughout this thread, I've been thinking that the simplest way to go by 
>far would be for enterprise nets to simply provide a web site where app 
>designers could go. But maybe that's too manual.

Once again you fail the first requirement: The application mustn't have to 
rely on any preexisting network server, infrastructure, etc.  It relies 
ONLY on the application software written in the client and server.

Beau

---

From: "Marshall Eubanks" <[email-masked]>
Date: Wed, 09 Feb 2005 18:30:45 -0500

On Wed, 9 Feb 2005 17:24:08 -0500
 "Manfredi, Albert E" <[email-masked]> wrote:
> Is this better than a simple unicast session with such a server because the Class D address can
> become standard in all enterprise nets, where a unicast address would not be?
> 
> Throughout this thread, I've been thinking that the simplest way to go by far would be for
> enterprise nets to simply provide a web site where app designers could go. But maybe that's too
> manual.

Well, on the application that I worked on the most, this wouldn't have solved a thing - how does the
application know where the web site is ? You've just popped the problem up (down?) to another layer.

If you want to use local DNS, then why not just provide the class D address using local DNS and
avoid the server entirely ?

Regards
Marshall