Subject: mboned: address discovery and allocation

From: Hans Kuhn <[email-masked]>
Date: Fri, 11 Nov 2005 09:00:14 -0800 (PST)

I was glad to see Beau present this draft for two reasons. 
First, MADP fills a real need for near-zero-conf address 
discovery. An assumption Beau made that was frequently 
overlooked during the floor discussion, is that you can't 
expect the presence of dhcp or dns in many cases.

Second, although Beau's proposal didn't deal with it, mboned 
should take on the address allocation issue because there 
still isn't a good solution for this. Dave Meyer has talked 
about this problem many times, but the problem continues to 
worsen. Joel is right that we need to start addressing the 
problems we have, not the ones that we thought we might have 
10 years ago.

-- 
Hans Kuhn 	Academic User Services	     office +1 (541) 346-1714
PGP Key fingerprint =  8D66 51A8 E120 B781 C298  2C38 031A BFB5 67FC ABE5
_______________________________________________________________
user interface: http://darkwing.uoregon.edu/~llynch/mboned.html
web archive:  http://darkwing.uoregon.edu/~llynch/mboned/

---

From: Marshall Eubanks <[email-masked]>
Date: Fri, 11 Nov 2005 13:27:06 -0500

I agree with Hans, and told Beau so after the session.

Regards
Marshall Eubanks

On Nov 11, 2005, at 12:00 PM, Hans Kuhn wrote:

> I was glad to see Beau present this draft for two reasons. First,  
> MADP fills a real need for near-zero-conf address discovery. An  
> assumption Beau made that was frequently overlooked during the  
> floor discussion, is that you can't expect the presence of dhcp or  
> dns in many cases.
>
> Second, although Beau's proposal didn't deal with it, mboned should  
> take on the address allocation issue because there still isn't a  
> good solution for this. Dave Meyer has talked about this problem  
> many times, but the problem continues to worsen. Joel is right that  
> we need to start addressing the problems we have, not the ones that  
> we thought we might have 10 years ago.
>
> --

---

From: Hugo Santos <[email-masked]>
Date: Fri, 11 Nov 2005 18:39:38 +0000

> >I was glad to see Beau present this draft for two reasons. First,  

Is this draft available anywhere? I googled for 'Multicast Address
Discovery' without any success. Any pointers would be appreciated.

Thanks,
Hugo

---

From: Marshall Eubanks <[email-masked]>
Date: Fri, 11 Nov 2005 13:41:34 -0500

The draft is in preparation. Beau simply  presented a proposal for  
feedback.

Regards
Marshall

---

From: Pekka Savola <[email-masked]>
Date: Fri, 11 Nov 2005 21:05:59 +0200 (EET)

On Fri, 11 Nov 2005, Hans Kuhn wrote:
> I was glad to see Beau present this draft for two reasons. First, MADP fills 
> a real need for near-zero-conf address discovery.

So, is there any work to be done?  It seems that SAP already fills 
this role (except maybe the scope-relative addresses).

I'd encourage folks to look at 
draft-ietf-mboned-addrdisc-problems-00.txt, section 3.2 and state if 
there is any difference on perception of the problems.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
_______________________________________________________________
user interface: http://darkwing.uoregon.edu/~llynch/mboned.html
web archive:  http://darkwing.uoregon.edu/~llynch/mboned/

---

From: Marshall Eubanks <[email-masked]>
Date: Fri, 11 Nov 2005 14:26:53 -0500

Dear Pekka;

It is hard to be sure just how much work there is to be done without  
seeing a draft.

What was not clear to me was whether this was

1 - a means of designating well known addresses for this purpose (in  
which case the actual discovery
protocol to be run using those addresses could be left up to the  
implementer, and  could well be SAP) or

2 - the above plus a protocol for doing the MAD (in which case some  
specific protocol must be specified,  SAP or not).

In the first, there seems little work to do, in the second case, a  
bit more.

In my experience, application developers are likely to want to do #  
1. They will have code to open sockets, listen on sockets, etc., and  
will know what they want to do, while getting them to install any  
extra code for any purpose will get push back. They tend to be very  
resource constrained.

Now that doesn't mean that you couldn't recommend a protocol to use.

All of this does imply that separate uses of the same multicast group  
for this purpose will have to tolerate
each other.

Regards
Marshall

On Nov 11, 2005, at 2:05 PM, Pekka Savola wrote:

>> MADP fills a real need for near-zero-conf address discovery.
>
> I'd encourage folks to look at draft-ietf-mboned-addrdisc- 
> problems-00.txt, section 3.2 and state if there is any difference  
> on perception of the problems.
>
> --

---

From: Beau Williamson <[email-masked]>
Date: Mon, 14 Nov 2005 10:16:51 -0600

At 11/11/2005 12:39 PM, Hugo Santos wrote:
>  Re mboned address discovery 
> a.ems<file://C:\DOCUME~1\bwilliam\MYDOCU~1\Email\Attach\Re mboned address 
> discovery a.ems <0880.0002>>
>*** PGP SIGNATURE VERIFICATION ***
>*** Status:   Unknown Signature
>*** Signer:   Unknown Key (0x2B5434AC)
>*** Signed:   11/11/2005 12:39:38 PM
>*** Verified: 11/14/2005 10:16:19 AM
>*** BEGIN PGP VERIFIED MESSAGE ***
>

No.  Stig Venas and I are going to start on it asap.

Beau Williamson

>Thanks,
>Hugo
>
>
>
>*** END PGP VERIFIED MESSAGE ***

---

From: Stig Venaas <[email-masked]>
Date: Mon, 21 Nov 2005 16:08:43 +0100

> Now that doesn't mean that you couldn't recommend a protocol to use.

Right, but I think we should make it as simple as possible wrt to
resources and implementation effort.

> for this purpose will have to tolerate

So the best would be for those using the same group to also speak a
well defined protocol. This might also make it easier for managers to
debug things by joining the group and inspecting the protocol traffic.

Stig

---

From: Stig Venaas <[email-masked]>
Date: Mon, 21 Nov 2005 16:04:24 +0100

On Fri, Nov 11, 2005 at 09:05:59PM +0200, Pekka Savola wrote:
> >I was glad to see Beau present this draft for two reasons. First, MADP 
> >fills a real need for near-zero-conf address discovery.
> 

In 3.2 you talk about SAP queries; there are no SAP queries. You could
maybe reuse SAP, but I think you need to be able to do queries rather
than just regularly sending announcements. I'm not so sure extending
SAP is a good idea though.

Stig

---

From: Marshall Eubanks <[email-masked]>
Date: Mon, 21 Nov 2005 10:34:29 -0500

Hello Stig;

So you basically vote for # 2 with a very simple protocol, perhaps as  
a SHOULD. Is SAP it ?
Or should it be something new ?

Marshall

---

From: Stig Venaas <[email-masked]>
Date: Mon, 21 Nov 2005 16:48:18 +0100

> Or should it be something new ?

I think SAP might be more complicated than necessary. For one thing,
you don't need SDP, but we could define a new payload type. But once
you add a way to query for announcements (and IMO skip regular
announcments), define a new payload and define a new group for the
announcements, very little remains of SAP...

Idea with #1 is that each vendor vendor can ask for different addresses
for their proprietary protocols?

I think it would be nice if most could use a standardized well known
open protocol. It requires only one group and makes it easier to
manage. Which is #2 as I see it.

So I'm voting for #2.

Stig

---

From: Marshall Eubanks <[email-masked]>
Date: Mon, 21 Nov 2005 12:13:42 -0500

Hello;

> for their proprietary protocols?

Well, I was trying to figure out  exactly what was proposed. I was  
actually assuming one address
and that collisions would be accepted. (After all, there will be  
collisions in any one well known
address proposal.)

HOWEVER, I think that monitoring etc. really makes one address  
compelling. This address will have to be reserved by IANA, and would  
presumably be in 224. (If you assign an address in 239 how do you  
know it isn't already in use somewhere ?)

Here is a specific straw-man idea based on discussions, and offered  
as a suitable  target for rotten fruit :

The more I think about this the more I think this should be like ARP,  
with a presumption that collisions are
unlikely, and there is no reason to direct responses to a new group  
address. This would mean basically two messages, a request and an  
announcement (and hosts SHOULD NOT perform regular announcements).  
The ARP type messages (in pseudo-English) might be a query and a  
response :

1.) Who Has Group Address X, I intend to use it with protocol Y ?

2.) I have Group Address X and am using it with protocol Y.

Then operations might be

- For a server, request an empty slot and use if no one complains. If  
someone does, switch to another
group address and repeat.

- For a host (or in a server-less zero config scenario), use the  
default group choice for your protocol, and
see if there is a server for it, or if a new group is needed.

- A protocol of all zero's could be reserved, and used to elicit a  
response from all parties, for monitoring.

Obviously, this raises the question as to whether or not protocol  
assignments are needed. They better not be. One choice might be to  
make the protocol 128 bits long, say that the first 2^16 are the same  
as the IP protocols assigned by IANA and these MUST be respected, and  
that otherwise protocol numbers MUST be chosen at random from the  
remainder of the space. The chances of a collision are thus ~ n^2 /  
2^128, where n  is the number of such protocols; this probability is  
a  very small number for any reasonable value of n. Or there could be  
a registry, and they could be  handed  out in order first come first  
serve. 32 bits might suffice in this case.

Obviously, as written this is not a very secure protocol (it would be  
easy to DOS on  the local network). I am
not sure if this is much of an issue, as offending parties could be  
dealt with like any other local DOS source.

Marshall

---

From: Stig Venaas <[email-masked]>
Date: Mon, 21 Nov 2005 18:25:12 +0100

On Mon, Nov 21, 2005 at 12:13:42PM -0500, Marshall Eubanks wrote:
[...]
> The ARP type messages (in pseudo-English) might be a query and a  

So far I agree

> 1.) Who Has Group Address X, I intend to use it with protocol Y ?

My thinking is that Y is some random string whatever that the vendor
can pick. A query would specify Y and you get X back in the reply.
So like ARP where X is the MAC address.

> 2.) I have Group Address X and am using it with protocol Y.

Yes

> group address and repeat.

This is the tricky part I think. With no infrastructure, I would assume
that X picks a more or less random address from some range (maybe we
should specify the range). You may then need to be able to do sort of
RARP, e.g. ask which protocol Y is using X.

Stig

---

From: Beau Williamson <[email-masked]>
Date: Mon, 21 Nov 2005 14:39:58 -0600

>know it isn't already in use somewhere ?)

No, the idea is to get IANA to assign a scope relative address for this. 
Thus you can issue a query in the Local Scope and the Org-Local scopes 
which are well-known.

Beau

---

From: Beau Williamson <[email-masked]>
Date: Mon, 21 Nov 2005 14:43:27 -0600

> > 2.) I have Group Address X and am using it with protocol Y.

Guys,

The above is not within the scope of what we want to do.  Some sort of 
configuration (MADCAP or manual) occurs at the server to set the 
address(es) to be used by the application.

The client issues a query on the well-known scope relative address asking:

   For application "foo", what addresses are we using?

Beau

---

From: Stig Venaas <[email-masked]>
Date: Mon, 21 Nov 2005 22:31:28 +0100

>   For application "foo", what addresses are we using?

I think that's what I'm trying to describe. Application "foo" asks
what address to use for Y = "foo", and gets back a multicast address X.

This solves the discovery part, and maybe should leave it at that.

I got a bit carried away with the RARP and zero-conf assignment. I'm
still worrying how the server will obtain it's address though. I'm
worrying that MADCAP or manual are not always viable options.

Note though, that if the protocol is simply "ARP", asking what the
address X is for application Y, then that could optionally be used
for assignment as well.

Stig