Subject: [MBONED] draft-williamson-mboned-madp-00.txt

From: Beau Williamson <[email-masked]>
Date: Thu, 15 Nov 2007 15:27:36 -0600

Fellow Mboned WG members,

Please take a look at this new draft and make comments.  We hope to 
discuss this at the Mboned WG meeting in Vancouver.

Beau Williamson

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title		: Light-weight Multicast Address Discovery Protocol
	Author(s)	: B. Williamson, et al.
	Filename	: draft-williamson-mboned-madp-00.txt
	Pages		: 15
	Date		: 2007-11-13
	
    Light-weight, multicast address discovery mechanisms that can be used
    by large scale client-server application deployments have been
    virtually non-existent in the past.  This has resulted in many
    multicast client-server applications being deployed with "hard-coded"
    multicast addresses within the client workstations in order to
    provide "zero-configuration" operation of the application.
    Unfortunately, many of these hard-coded multicast addresses are often
    picked at random by the application developers resulting in multicast
    address collisions with other protocols/applications or conflicts
    with the multicast scoping plans of a network administrator.  This
    document describes a "light-weight" multicast address discovery
    protocol that can be used by application clients to locate their
    nearest application server using well-known scope relative multicast
    addresses.  Once located, the server can then communicate the
    multicast address(es) that have been configured on the server by the
    network administrator for use by the application.  This permits
    applications be written to operate in a flexible "near-zero"
    configuration mode without having to use "hard-coded" addresses or
    rely on any other network service other than multicast and the
    existence of a nearby application server.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-williamson-mboned-madp-00.txt

To remove yourself from the I-D Announcement list, send a message to
[email-masked] with the word unsubscribe in the body of
the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the
username "anonymous" and a password of your e-mail address. After
logging in, type "cd internet-drafts" and then
"get draft-williamson-mboned-madp-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-williamson-mboned-madp-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

Content-Type: text/plain
Content-ID: <[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-williamson-mboned-madp-00.txt

<ftp://ftp.ietf.org/internet-drafts/draft-williamson-mboned-madp-00.txt>
_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/i-d-announce

_______________________________________________
MBONED mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mboned

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Thu, 15 Nov 2007 17:19:17 -0500

> -----Original Message-----
> From: Beau Williamson [mailto:[email-masked]] 
> 

I was expecting to see a request with a variable length, opaque field,
to be used similar to the Client Identifier option of DHCP. And the
potential for several IP multicast addresses provided as a response to
such a request.

If you had such an option, wouldn't some of the other types you list be
collapsed into that same request format? The client would multicast a
request such as "Camera 1 video," and the smallest-scope reply would
incorporate the IP multicast group, and potentially also the source IP,
of the video source it needs to see.

Of course, these opaque names would have to be made available to
clients, out of band, just as in the DHCP example.

Bert

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Thu, 15 Nov 2007 17:19:17 -0500

Bert

---

From: Dave Thaler <[email-masked]>
Date: Thu, 15 Nov 2007 15:18:37 -0800

I haven't read the draft yet, but what is the relationship to SAP?
Is this basically a more efficient version of SAP?

-Dave

> Sent: Thursday, November 15, 2007 1:28 PM
> To: [email-masked]
> Cc: Stig Venaas
> Subject: [MBONED] draft-williamson-mboned-madp-00.txt
>

---

From: Dave Thaler <[email-masked]>
Date: Thu, 15 Nov 2007 15:18:37 -0800

-Dave

---

From: Beau Williamson <[email-masked]>
Date: Fri, 16 Nov 2007 10:34:22 -0600

>clients, out of band, just as in the DHCP example.

Bert,

That is certainly one way we could have done it.  However, I'm not 
sure I see an advantage to doing it your way over the way we have 
specified.  It is assumed that the client and the companion 
application server already KNOWS what information needs to be 
exchanged (i.e. how many multicast addresses are in use by the 
application and for what).  Our way, you have the clients sending 
very short Request messages to:

   1) Find the nearest companion application server and

   2) Obtain the multicast addresses that have been configured for 
use by the application (vs hard-coding them).

Keep in mind we wanted to provide the absolutely simplest, 
light-weight solution that would allow application developers to 
avoid hard-coding addresses into their code.

Beau

---

From: Beau Williamson <[email-masked]>
Date: Fri, 16 Nov 2007 10:34:22 -0600

Bert,

Beau

---

From: Beau Williamson <[email-masked]>
Date: Fri, 16 Nov 2007 10:45:19 -0600

>I haven't read the draft yet, but what is the relationship to SAP?

There really isn't one.

>Is this basically a more efficient version of SAP?

You might say that.  However, we weren't trying to reinvent SAP (or 
DHCP or anything else, for that matter).

Instead we wanted to be able to point application developers to a 
dirt simple solution that accomplishes (near)zero-configuration 
deployment of their client-server applications WITHOUT them resorting 
to hard-coding addresses.

Could they have used:
    * SAP
    * SLP
    * DNS
    * MADCAP
    * Other solutions
Absolutely.  Did they?  No.  Primarily because most of these 
solutions DEPENDED on some other service already being deployed and 
properly configured by a third-party to make their application 
deployable. Also, most of these solutions required more work than 
they wanted to do.  ("Hey Bob, let's just hard-code the address into 
our application and get it out the door.")

My goal is to take away excuses for hard-coding addresses into their 
application.  To do that, it has to be SUPER simple.  Also, we are 
hoping that someone will offer some simple code libraries with API's 
that the application developers can just compile into their code and use.

On the other hand, if by making this into an RFC we bring attention 
to the problem and application developers choose other methods to 
accomplish the same thing, then I'm perfectly happy with that.

Beau

---

From: Beau Williamson <[email-masked]>
Date: Fri, 16 Nov 2007 10:45:19 -0600

There really isn't one.

Could they have used:
    * SAP
    * SLP
    * DNS
    * MADCAP
    * Other solutions

Beau

---

From: Leonard Giuliano <[email-masked]>
Date: Mon, 19 Nov 2007 12:24:56 -0800 (PST)

On Fri, 16 Nov 2007, Beau Williamson wrote:

-) Absolutely.  Did they?  No.  Primarily because most of these solutions
-) DEPENDED on some other service already being deployed and properly configured
-) by a third-party to make their application deployable. Also, most of these
-) solutions required more work than they wanted to do.  ("Hey Bob, let's just
-) hard-code the address into our application and get it out the door.")
-) 

This seems very similiar functionally to SAP, and I was unaware the
"heaviness" of SAP was preventing it's use by app developers.

I'm not sure I agree that complexity of available solutions was the
biggest reason for hardcoding- I believe it was more an issue of laziness
and ignorance on the part of Bob and his fellow app developers.  After   
all, one near-zero way of doing this is to just let the user plug in the 
static mcast address (or fqdn) in their app.

Accordingly, I see this as just another dynamic mcast mechanism that Bob
is just going to ignore as he hardcodes another address into the next app.

-) My goal is to take away excuses for hard-coding addresses into their
-) application.  To do that, it has to be SUPER simple.  Also, we are hoping
-) that someone will offer some simple code libraries with API's that the
-) application developers can just compile into their code and use.
-) 
-) On the other hand, if by making this into an RFC we bring attention to the
-) problem and application developers choose other methods to accomplish the
-) same thing, then I'm perfectly happy with that.

We can take their excuses away, but that probably won't stop them from   
continuing down the path of least resistance.  Plenty of drafts and RFCs
have been written directing them to what is right and wrong when it comes
to mcast addressing.  If they ignored all of those, they'll probably
ignore this one as well.
   
If I'm an operator, I say let them hardcode- I just won't let this stuff 
into/out of my network.  A simple whitelist of filters that only allows 
packets and joins for 224.1/16, 224.2/16, 232/8 and 233/8 and kills 
everything else should eliminate the vast majority of hardcoded traffic 
(which you still should do with or without this proposal).

-Lenny

---

From: Leonard Giuliano <[email-masked]>
Date: Mon, 19 Nov 2007 12:24:56 -0800 (PST)

-Lenny