Subject: Re: mboned: Interest in working on multicast address rendezvous?

From: Beau Williamson <[email-masked]>
Date: Tue, 01 Feb 2005 12:15:33 -0600

At 1/30/2005 09:29 PM, John Kristoff wrote:
>On Fri, 28 Jan 2005 18:36:57 -0600
>Beau Williamson <[email-masked]> wrote:
>
> > Yes, that has been proposed before and is a possibility in my
> > mind.  However, here's the problem:
>[...]
>
>It's just one problem, but only if multiple scopes must be defined and
>accompany this group addressing scheme.  I'm not really convinced this
>is either necessary or required, at least in this case.

Yes, it's only one problem but from my experience it is one of the biggest 
ones Enterprise networks have.

Admin scoping inside of an Enterprise network is more of a "When" than an 
"If" issue.  Initially, multicast tends to be deployed with a single 
Enterprise-wide scope or in limited self-contained pockets which are 
effectively multiple independent PIM-SM domains.  Thus there is, at least 
initially, no need for scopes.  However, what tends to happen is that these 
badly behaved applications are soon discovered running to all corners of 
the network which is not what is desired and then scoping begins to look 
attractive.  In other cases where the Enterprise network spans large 
geographic areas, they are beginning to start day one planning on using 
scoped zones.

>[...]
> > If we don't go with this sort of SADP approach, we are back to building
> > custom ACL's to cover the various addresses and the administration of
> > scopes and their ranges goes down the porcelain fixtures.
>
>We're doing that now, that is the problem.

Yep, hence the need to get the applications under control by offering them 
viable, simple alternatives to AE address assignment of global addresses 
and then hard coding them into the apps.  I think we could make something 
like SADP do the trick for them.

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

---

From: Beau Williamson <[email-masked]>
Date: Tue, 01 Feb 2005 14:38:05 -0600

Brian,

My problem with this approach is that it requires a MADCAP server for the 
application to come up in a zero-configuration mode.

What I'd like to see is a light-weight method that doesn't DEPEND on the 
existence of a MADCAP server.  Instead, there is a well-known SADP scope 
relative address.  Clients would transmit requests on this Relative address 
first in the Local Scope and then in the Enterprise-wide scope (the only 
two scopes you can possibly know exist based on the Admin Scoping draft).

The application "Servers" would respond to the clients SADP request.  Now, 
you give the server the option to manually configure the address under 
admin control AND/OR use MADCAP to automatically get the address.

Beau
At 2/1/2005 01:15 PM, Brian Haberman wrote:

>On Feb 1, 2005, at 13:59, Beau Williamson wrote:
>
>>At 2/1/2005 12:25 PM, Brian Haberman wrote:
>>>Sure Beau,
>>>
>>>On Feb 1, 2005, at 13:17, Beau Williamson wrote:
>>>
>>>>At 1/31/2005 10:43 AM, you wrote:
>>>>>I will just point out that RFCs 3306 & 3307 solve this problem for
>>>>>IPv6.  The application can request a specific group ID that is
>>>>>irrespective of the scope of deployment (which is controlled by
>>>>>the "scop" field in the IPv6 multicast address prefix.
>>>>
>>>>Would you mind refreshing my memory on this (briefly).
>>>
>>>
>>>3306 breaks the multicast address up into pieces (mcast prefix (8 bits),
>>>flags (4 bits), scope (4 bits), reserved (8 bits), prefix length (8 bits),
>>>unicast prefix (64 bits), and a group ID (32 bits).
>>>
>>>So, an application can request a specific group ID.  That group ID can
>>>be used in any multicast address supporting that app.  The scope is
>>>controlled by the scop field in the prefix.  With this approach, an app
>>>developer can use the guidelines in 3307 to request a specific group
>>>ID, not an entire address.  The network admins control the flow of
>>>the multicast streams by setting up scope boundaries based on the
>>>scope field in the address and not the entire address.
>>
>>OK, this part I knew.  I was thinking that there was something more that 
>>actually solved the problem.  I don't think the above does.
>>
>>The application might be able to request an address but to my knowledge 
>>the address sent to by the application "includes"  setting the scope 
>>bits.  The problem is that the application doesn't know what scope to use.
>
>The original intent was that a MADCAP (or MADCAP-like) server could
>delegate the prefix portion of the address based on some policy.  The
>app would construct the full address based on its IANA-assigned group
>ID and the prefix provided by the server.
>
>What I was referring to above is the ability for an app to just request the
>group ID, which would be well-known if assigned by IANA.  There is still
>an issue as to how the address is advertised as "in use".
>
>>
>>Also, to what/where does the application issue the request for a group 
>>address?  I don't
>
>MADCAP.  The benefit of 3306 is that none of the inter-domain mcast
>address allocation mechanisms are needed.
>
>>recall anything in IPv6 that is any different than IPv4 in this 
>>regard.  Also, how does this magical "thing" keep track of which address 
>>is assigned to which application?  What
>
>A request could come into the server with an option that says "I am
>application X and I am using group ID Y".  The server looks in a table
>to determine the appropriate prefix to return to the requester.
>
>>happens if this "magical" thing doesn't exist in the network?  How does 
>>the application work in a zero-config mode in this case??
>
>A portion of the group ID range is reserved for dynamic/transient use.
>In that case, the prefix would need to be determined.  That is an open
>issue.  One option would be to assume that transient multicast should
>default to a specific scop (e.g. site-local).  Or the network operator could
>put boundary filters that look at the T bit in the multicast prefix.
>
>Brian
>
>

---

From: Leonard Giuliano <[email-masked]>
Date: Tue, 1 Feb 2005 14:10:23 -0800 (PST)

On Tue, 1 Feb 2005, Beau Williamson wrote:

-) >We're doing that now, that is the problem.
-)
-) Yep, hence the need to get the applications under control by offering them
-) viable, simple alternatives to AE address assignment of global addresses
-) and then hard coding them into the apps.  I think we could make something
-) like SADP do the trick for them.
-)

I am having trouble understanding how this will solve the problem.  If I
understand the problem correctly, app developers, through
laziness/ignorance, are hardcoding their apps with global mcast addresses
pulled out of the air.  In the meantime, they could just as easily allow
the administrator the ability to configure the group address of the app
themselves, where viable static solutions like GLOP or 239/8 would do the
trick.  Please correct me if my understanding is wrong.

Now, if these app developers are not allowing administrators the ability
to statically configure the addresses themselves, how will yet another
dynamic address allocation protocol fix this?  Even if this magical new
protocol existed, what gives us the impression that it will be used, and
they won't still hardcode these apps?

What's wrong with existing dynamic protocols, like SAP or MADCAP?  If
these protocols aren't being used, why would a new protocol not suffer the
same fate?

Seems to me there are plenty of viable solutions, and they just aren't
being used.  I don't understand how another new one will solve the
problem.

---

From: "Marshall Eubanks" <[email-masked]>
Date: Tue, 01 Feb 2005 19:07:07 -0500

Hear, hear. This has nothing to do with source or address discovery. After all, the problem is that
these sources are too easy to find, not too hard...

I do not think that any of the mechanisms discussed on this thread will fix 
this problem, because there are ways that they could grab addresses now. (I don't see why they can't
use 239/8, but Glop does comes to mind, and even extended GLOP.) This is the result
of laziness (or ignorance), and the only way to fix THAT is to complain, a lot, and to the
right people. Fortunately, I bet that the sum of all of the people on this list can find out
who the complaints should go to.

In the sense of moving forward, what if we identified a set of extended GLOP space (or even donated
GLOP space) and made
it available to application writers first come, first serve ? In Minneapolis, we could identify
a set of egregious offenders and start going after them. 

Regards
Marshall

On Tue, 1 Feb 2005 14:10:23 -0800 (PST)

---

From: John Kristoff <[email-masked]>
Date: Tue, 1 Feb 2005 21:20:41 -0600

On Tue, 01 Feb 2005 19:07:07 -0500

> use 239/8, but Glop does comes to mind, and even extended GLOP.) This is the result

The last time I suggested 239/8 for some assigned space there were at
least a few people who complained that many organizations are already
using the entire /8 for their admin scope stuff (not technically proper,
but oh well) and would thus cause some potentially harmful collisions.

I still think that would be appropriate also, but I'm not one who's
been using 239/8 incorrectly so that's easy for me to say.  :-p

John

---

From: "Marshall Eubanks" <[email-masked]>
Date: Tue, 01 Feb 2005 23:05:57 -0500

Clearly, in hindsight, 239.255.255.0/28 or somesuch should have been reserved for application users.

This is why I would lean to extended Glop space - some block that can be easily filtered.

Marshall

On Tue, 1 Feb 2005 21:20:41 -0600

---

From: Beau Williamson <[email-masked]>
Date: Wed, 02 Feb 2005 16:46:56 -0600

>trick.  Please correct me if my understanding is wrong.

No, you are correct.  I just failed to sufficient point out the other key 
constraint: zero-configuration application.

The problem is that these applications require zero-configuration at least 
on the hundreds of client workstations that are deployed.  Certainly being 
able to configure each client with an assigned address is one solution and 
we should encourage this model when it doesn't impact the usability of the 
application.  However, some applications can't/don't want this burden when 
the number of clients grows quite large, which is understandable.

The goal is to minimize the configuration of the address to a single (or at 
least a few) application servers, from which the clients can learn the 
address that has been configured by the network administrator for the 
application based on desired scope and other address allocation factors 
within the Enterprise.

>they won't still hardcode these apps?

They won't if we make it either 1) hard to implement in their code or 2) 
require some network infrastructure to be in place in order to get make it 
work (ala MADCAP).

We want to define a SADP-like, light-weight protocol (which I'll just call 
SADP for now). This allows an app developer build (download free code??) a 
simple SADP server shim that can be added at the server to respond to 
client requests and also a simple client shim that will multicast SADP 
requests on a well-known, SADP Scope Relative address.  (Conceptually, it 
would do this on the Local scope first and then on the Org-Local (aka 
Enterprise-wide) scope.)

>these protocols aren't being used, why would a new protocol not suffer the

Because in the case of MADCAP, you have to FIRST have a MADCAP server in 
the network.  You could still use SAP-like encoding in the SADP messages.

Again, you want the app developer to build the necessary pieces so that no 
matter what environment they deploy their application, they are guaranteed 
that it will work.

>being used.  I don't understand how another new one will solve the

All the solutions require a third-party element that is not ubiquitous in 
every network environment.  Given that, the app develop can't be guaranteed 
his app will work.

Beau

---

From: Beau Williamson <[email-masked]>
Date: Wed, 02 Feb 2005 17:22:09 -0600

At 2/1/2005 06:07 PM, Marshall Eubanks wrote:
>this problem, because there are ways that they could grab addresses now. 
>(I don't see why they can't use 239/8, but Glop does comes to mind, and 
>even extended GLOP.) This is the result of laziness (or ignorance), and 
>the only way to fix THAT is to complain, a lot, and to the right people. 
>Fortunately, I bet that the sum of all of the people on this list can find 
>out who the complaints should go to.

It's only partly laziness.

They need zero-config ability to avoid having to configure all the client 
workstations that pop up on the network with the software installed.  If if 
they weren't lazy and provide a manual configuration capability, they won't 
go that route because a key part of their application is the zero-config 
aspect that they currently have now with hard coded addresses.

Beau

---

From: "Marshall Eubanks" <[email-masked]>
Date: Wed, 02 Feb 2005 20:47:54 -0500

On Wed, 02 Feb 2005 17:22:09 -0600
> aspect that they currently have now with hard coded addresses.

I understand their problems. It would be nice to have a sort of multicast DHCP (which
is how they would handle this in unicast in general I think - I don't see too many). 

However, I still think it is laziness or ignorance. If I was heading the team designing one
of these applications I would find a 
default that was either in 239/8 or in someones GLOP space or whatever.

However, I have thought about this, and I think it might be a good idea to have an
explicit "swamp" where people could just grab an address (in the best "best effort" 
tradition, don't complain if you collide with someone else).

I am really thinking more of a type of quarintine. If we gave up 224.251.254/23 (say) for this
purpose, it would be really easy to filter out.

Regards
Marshall

---

From: "Marshall Eubanks" <[email-masked]>
Date: Wed, 02 Feb 2005 20:51:34 -0500

I understand their problems. It would be nice to have a sort of multicast DHCP (which
is how they would handle this in unicast in general I think - I don't see too many 
globally routable unicast addresses hard coded in applications). 

However, I still think it is laziness or ignorance. If I was heading the team designing one
of these applications I would find a 
default that was either in 239/8 or in someone's GLOP space or whatever.

The more I think about this, the more I think it might be a good idea to have an
explicit "swamp" where people could just grab an address (in the best "best effort" 
tradition, don't complain if you collide with someone else).

I am really thinking more of a type of quarantine. If we gave up 224.251.254/23 (say) for this
purpose, it would be really easy to filter out.

Regards
Marshall

---

From: Beau Williamson <[email-masked]>
Date: Wed, 02 Feb 2005 21:28:10 -0600

At 2/2/2005 07:47 PM, Marshall Eubanks wrote:

>However, I have thought about this, and I think it might be a good idea to 
>have an explicit "swamp" where people could just grab an address (in the 
>best "best effort" tradition, don't complain if you collide with someone else).
>
>I am really thinking more of a type of quarintine. If we gave up 
>224.251.254/23 (say) for this purpose, it would be really easy to filter out.

Marshall,

I think you are missing one of the key points here.  It's not just the lazy 
app developers that we need to address.  The goal is two fold here:

1) Provide apps developers with a simple light-weight mechanism to provide 
near zero configuration mechanisms for their applications.

2) Provide the Enterprise network admins the ability to configure these 
applications to operate within the private 239/8 scope range of their 
choice so that they can easily "assign" these applications an address and 
scope that makes sense for their network.

These two requirements above can not be acccomplished with the current set 
of tools that we have.

Beau

---

From: Pekka Savola <[email-masked]>
Date: Mon, 7 Feb 2005 08:57:02 +0200 (EET)

Hi,

I re-read the message thread a couple of times, trying to sum up what 
has been discussed.  I'll focus on Beau's smaller problem. I've tried 
to write this in a form of a problem statement/requirements, see 
below.

Comments?

Smaller-than-global single-administration multicast 
address discovery
---------------------------------------------------

Many applications are written which leverage or could leverage multicast
routing infrastructures, in one or more of:
  1) link-local scope
  2) [geographical] site scope
  3) organization-local scope
  4) global scope, used between consenting enterprises
  5) truly global application

We focus on the first 3.  4) is a larger problem which should be discussed
separately.

Multicast-leveraging applications are often designed such that each
multicast group has a "server", "session creator" or some other node(s)
(or persons operating the nodes) which are in some way in control of
the application.

Both the "server" and "client end" of an application are currently
typically provisioned with the group address using static IANA assignment.
Only rarely these apps are manually configured e.g. with locally scoped
addresses, especially the ones with a large number of clients.

This is a problem for multiple reasons:
  - this messes up the multicast scoping plans which the site may have.  Each
application's global address must be individually scoped and filtered in all
the routers and in their access lists.  Scoping should be easier.
  - static IANA assignments are required for each application; a permanant
global assignment for each application which could use multicast depletes
the resource quickly.
  - this has issues with IPv6, because such IPv6 addresses can
not be scalably routed in inter-domain routing; in intra-domain,
this requires manual configuration or running BSR (for ff01::/16 or
ff02::/16 or the like?)
  - "Intended for local only use" applications typically leak through to the
IPv4 MSDP because there is no clear logic which ones should be global and
which ones are local.

Instead, it should be possible for the "server end" to be configured with an
appropriate local address, which it could advertise to be used by "client
ends".

The client ends should discover the smallest possible scope where the
application is supported.

...........

One could characterize a potential solution as an easily implementable 
MADCAP-like -server shim at "server end" listening to a set well-known 
locally-scoped multicast addresses, which would respond to queries by 
"client end" (including a simple MADCAP client shim).

(Maybe it is confusing to call this kind of functionality as 
"MADCAP-like", because the clients do not request to create a new 
session, but to learn the address of an existing one..)

Questions:
  - how can the servers demultiplex "queries" sent to these addresses? 
Are these messages in SAP format or something simpler?  The query must 
have an identifier which the server uses to know the client is 
interested in the server's multicast transmission.
  - how should the servers communicate back to the clients?  By 
replying with unicast (issues after bootup with lots of nodes) or do 
the clients also join the address (DoS potential, a very crowded group 
which all the servers at least need to subscribe to)?

...........

The requirements from the application/deployment perspective are:
  - not depending on any uncommon external infrastructure
    besides the application itself (e.g., a MADCAP server), so that the
    application can be deployed where MADCAP server is not present.

    I.e., this should be sufficiently lightweight to be coded in the
    application or be used by a simple application shim library.

  - The application should "just work" from perspective of "client end"
    without any configuration.  "Server end" can be configured with an
    address.

  - The presence of applications should be easily filterable at least at the
    edges of the network, and it should be easy to segment the use of
    application into the smallest possible scopes within the network, to avoid
    undue state and confusion in the network.

..........

Alternative slightly different problem statements are:
  - preventing global leakage, but not caring so much about the ease of local
scoping; achievable e.g., by assigning 238.1.0.0/16 for link-local, for
238.2.0.0/16 for site-local and 238.3.0.0/16 for org-local to be 
given by IANA on FCFS basis.
  - providing a means for disconnected but global scoping.

-- 
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: Beau Williamson <[email-masked]>
Date: Mon, 07 Feb 2005 09:24:18 -0600

Pekka,

I think you've summed things up pretty well.  From here, I'd like to see us 
begin work on the SADP-like protocol definition.

Beau
At 2/7/2005 12:57 AM, Pekka Savola wrote:
>Hi,
>
>I re-read the message thread a couple of times, trying to sum up what has 
>been discussed.  I'll focus on Beau's smaller problem. I've tried to write 
>this in a form of a problem statement/requirements, see below.
>
>Comments?
>
>
>Smaller-than-global single-administration multicast address discovery
>"MADCAP-like", because the clients do not request to create a new session, 
>but to learn the address of an existing one..)
>
>Questions:
>  - how can the servers demultiplex "queries" sent to these addresses? Are 
> these messages in SAP format or something simpler?  The query must have 
> an identifier which the server uses to know the client is interested in 
> the server's multicast transmission.
>  - how should the servers communicate back to the clients?  By replying 
> with unicast (issues after bootup with lots of nodes) or do the clients 
> also join the address (DoS potential, a very crowded group which all the 
> servers at least need to subscribe to)?
>
>...........
>
>238.2.0.0/16 for site-local and 238.3.0.0/16 for org-local to be given by 
>IANA on FCFS basis.

---

From: Dave Price <[email-masked]>
Date: Mon, 07 Feb 2005 17:39:57 +0000

Dear All,

	I've been watching these emails go by, and reading some, but
by no means all of the text.

	I want to raise one issue that I think has not yet been
addressed.

"Smaller-than-global single-administration multicast address discovery"

I want to question the term "single administration".

I have heard many folks question the current admin scoped
address arrangements precisely because they really all hang
on the term "administration" and it implying some single
well-defined entity.

I think the reality now of the way folks act and interact is that
it is now very hard to define what we mean by "an administration".

I think things are at best hierarchical and probably really more complex
than that.

Taking the UK as an example, I work for University of Wales, Aberystwyth.
Now, UWA is a legal entity and so one might consider it
the "administration".

However, I can easily postulate applications
that want to be able to run within some subarea of the area
of network controlled by UWA.  Going the other way, I can also see
a need for addresses that not only reach UWA, but also all the sites
within our serving MAN and indeed another level, being
"all UK academia" or "all europe academia".

	I can also perceive of applications that might want addresses
whose scope did not fit into this hierarchy.  For instance, "several UWA
departments", or perhaps "all of Wales academia" (which is largely served
by two MANs who only couple only by going outside Wales onto
the UK academic network.).

If work is going to be put into new ways to to
do multicast address discovery, would it not be better to consider
these more complex requirements rather than focussing
on some perhaps slightly simplistic interpretation of
the term "single administration" ??

Dave Price

---

From: Leonard Giuliano <[email-masked]>
Date: Mon, 7 Feb 2005 12:58:05 -0800 (PST)

WWUD- What Would Unicast Do?

How would you address these requirements in the unicast world?  However
you would solve this problem in the unicast world is probably the same way
you would want to approach it in the mcast world.

Creating complex mechanisms in the mcast world that wouldn't be seriously
considered in the uncast world will simply result in no implementation or
deployment.

-Lenny

On Mon, 7 Feb 2005, Dave Price wrote:

-) Dear All,
-)
-) 	I've been watching these emails go by, and reading some, but
-) by no means all of the text.
-)
-) 	I want to raise one issue that I think has not yet been
-) addressed.
-)
-) "Smaller-than-global single-administration multicast address discovery"
-)
-) I want to question the term "single administration".
-)
-) I have heard many folks question the current admin scoped
-) address arrangements precisely because they really all hang
-) on the term "administration" and it implying some single
-) well-defined entity.
-)
-) I think the reality now of the way folks act and interact is that
-) it is now very hard to define what we mean by "an administration".
-)
-) I think things are at best hierarchical and probably really more complex
-) than that.
-)
-) Taking the UK as an example, I work for University of Wales, Aberystwyth.
-) Now, UWA is a legal entity and so one might consider it
-) the "administration".
-)
-) However, I can easily postulate applications
-) that want to be able to run within some subarea of the area
-) of network controlled by UWA.  Going the other way, I can also see
-) a need for addresses that not only reach UWA, but also all the sites
-) within our serving MAN and indeed another level, being
-) "all UK academia" or "all europe academia".
-)
-) 	I can also perceive of applications that might want addresses
-) whose scope did not fit into this hierarchy.  For instance, "several UWA
-) departments", or perhaps "all of Wales academia" (which is largely served
-) by two MANs who only couple only by going outside Wales onto
-) the UK academic network.).
-)
-) If work is going to be put into new ways to to
-) do multicast address discovery, would it not be better to consider
-) these more complex requirements rather than focussing
-) on some perhaps slightly simplistic interpretation of
-) the term "single administration" ??
-)
-) Dave Price
-)
_______________________________________________________________
user interface: http://darkwing.uoregon.edu/~llynch/mboned.html
web archive:  http://darkwing.uoregon.edu/~llynch/mboned/

---

From: John Kristoff <[email-masked]>
Date: Mon, 7 Feb 2005 15:15:36 -0600

On Mon, 7 Feb 2005 12:58:05 -0800 (PST)

> considered in the uncast world will simply result in no implementation or

Here, here.  I have a feeling I'll back again in a year to complain
about this because the solution is getting too 'cute'.  It seems to
me anything more than a block of addresses assigned to vendor apps
as UDP/TCP ports might be assigned is too complex.

John

---

From: [email-masked]
Date: Mon, 7 Feb 2005 18:31:13 -0800 (PST)

> as UDP/TCP ports might be assigned is too complex.

Agreed. Perhaps a draft to redefine RFC2365 with a small block in 239 for 
embedded devices, and another to redifine RFC3171 to set the guidlines for 
IANA.

Greg

---

From: David Meyer <[email-masked]>
Date: Mon, 7 Feb 2005 16:06:59 -0800

>> embedded devices, and another to redifine RFC3171 to set the guidlines for 

	We could try that, but to be honest, I'm pretty sure it
	wouldn't help. People want nailed up globally unique
	addresses for these purposes because we haven't solved
	the "light-weight, embedded device/service discovery"
	problem. As I've been saying for some time now, my sense
	is that until we solve what I've called the
	"light-weight, embedded device discovery" problem, the
	discussion will be academic (as we don't have a method
	for these folks to solve their problem short of granting
	globally scoped, globally unique IP addresses, and as
	such the IANA will have no choice but to assign them; and
	this doesn't include all the other ancillary issues such
	as precedent and a plethora of other "administrative"
	issues). 

	Dave

---

From: "Marshall Eubanks" <[email-masked]>
Date: Mon, 07 Feb 2005 20:35:11 -0500

> WWUD- What Would Unicast Do?

Well, it seems to be that in unicast they use DHCP, DNS, and (in zeroconf) multicast (TTL = 1).

It's not at clear to me why the same mechanisms couldn't be used by multicast. For example, maybe a
special multicast domain could be set up just to supply applications
with multicast addresses - say <application>.multicast.arpa. Then local administrators could just
use dns redirects to convert a pesky application into or out of the 239 or 233 space. 

It would still have to be administered by someone like a RIR or IANA. If you were using your own
GLOP space it could be automatic, otherwise it could come with a /32 from a swamp.

Regards
Marshall

---

From: "Marshall Eubanks" <[email-masked]>
Date: Mon, 07 Feb 2005 20:42:13 -0500

On Mon, 7 Feb 2005 15:15:36 -0600
> as UDP/TCP ports might be assigned is too complex.

That was why I suggested a swamp - any "real" protocol will take 18+ months to get into
any deployment, and you _will_ be complaining about this in 2006.

Marshall

---

From: Beau Williamson <[email-masked]>
Date: Mon, 07 Feb 2005 19:50:07 -0600

At 2/7/2005 07:35 PM, Marshall Eubanks wrote:
>It's not at clear to me why the same mechanisms couldn't be used by 
>multicast. For example, maybe a special multicast domain could be set up 
>just to supply applications with multicast addresses - say 
><application>.multicast.arpa. Then local administrators could just use dns 
>redirects to convert a pesky application into or out of the 239 or 233 space.

Sorry, Marshall.  This is not the right answer to the problem.  It fails 
because it REQUIRES a preset infrastructure (dns records) to be in place 
before the application can work.

Again, we need the SADP-like protocol that runs SOLELY in the application 
(application client and server) and uses a single well-known Scope-Relative 
address so that the only infrastructure requirement is that multicast works 
at least at the link-local scope.  No other MADCAP server, DNS records, 
etc, etc are required to make the application work.  The application 
developer then only has to add a simple code shim in his client and server 
applications and it all works.

Beau

Beau

---

From: Beau Williamson <[email-masked]>
Date: Mon, 07 Feb 2005 23:29:36 -0600

At 2/7/2005 08:31 PM, [email-masked] wrote:
>embedded devices...

But this doesn't really solve the problem because the scope for a 
particular application can NOT be known ahead of time.  Sure, it helps 
prevent the application from leaking outside of the Enterprise network 
given standard ACL's and boundaries but inside the Enterprise network you 
still have the same problem:  hard-coded addresses in use for applications 
that don't match the scope desired by the network administrator.

The bottom line is that the addresses and scopes of these applications 
needs to be configurable by the network administrator.  This is in direct 
conflict with the needs of many applications that need zero-configuration 
deployments.

Beau

---

From: Pekka Savola <[email-masked]>
Date: Tue, 8 Feb 2005 09:27:46 +0200 (EET)

> 	as precedent and a plethora of other "administrative"

It is very true that until we have a "complete" solution, IANA will 
need to assign globally scoped addresses.

However, this does not say anything about those cases where people are 
requesting global IANA assignments for organizationally-scoped 
applications just because they have no other choice.

So, the approach would go as follows:
  1) IANA would continue to give globally scoped addresses, but we 
would make the process more time-consuming, so it would encourage 
those who have alternatives to use another method.
  2) we would create one FCFS block (e.g., under 239, or elsewhere) 
which we could call "organizational-scoped addresses".  Those 
applications which are to be used within an organisazation only could 
get the address from there with one simple email application, no 
questions asked.

I guess there are actually many apps which the app designers can say 
will only be used within an organizational scope -- but this is just a 
guess, and more analysis on the IANA assignments would be needed to 
learn whether this is worth the effort.

---

From: David Meyer <[email-masked]>
Date: Tue, 8 Feb 2005 07:21:47 -0800

Pekka,

>> applications just because they have no other choice.

	Its a corner case, I'm afraid. As least as far as what
	the IANA is seeing is concerned. Based on a quick review
	of my IANA inbox for the last 3 years, I don't see one
	contested application that this would have covered.

>> those who have alternatives to use another method.

	That has already failed, and isn't sound policy in any
	event. 

>> get the address from there with one simple email application, no 

	Will not address the problem the IANA is seeing (which I
	described in a previous email).

>> learn whether this is worth the effort.

	This is an incorrect guess.

	I'll just remind you that we've been trying at these
	approaches (and more) for *years*. 

	My suggestion is that we solve the root problem. 
	
	Dave

---

From: Pekka Savola <[email-masked]>
Date: Tue, 8 Feb 2005 17:40:57 +0200 (EET)

> 	My suggestion is that we solve the root problem.

OK, this is good to know.

Then the problem statement mail which I sent yesterday does not solve 
the root problem either, because the application developers will 
_still_ want to get the globally scoped addresses from IANA and glue 
it instead of implementing this "service discovery inside an 
organization" -shim.

So, we're back to the original larger problem, discovery across the 
organizational scoping boundaries.

---

From: David Meyer <[email-masked]>
Date: Tue, 8 Feb 2005 07:56:25 -0800

>> organizational scoping boundaries.

	Well said.  I would add the qualifer "lightweight" to
	"discovery". Many (if not most) of these applications
	(possibly with the notable exception of the large blocks
	allocated to the stock exchanges/trading houses) are
	really used by embedded devices for some type of service
	discovery. 

	I'll just point out one other thing here. Protocols like
	SLP (say RFC 2608) were really designed to solve a
	different problem. As such they are really not too useful
	here (at least in their current form).
	
	Dave

---

From: Beau Williamson <[email-masked]>
Date: Tue, 08 Feb 2005 10:41:05 -0600

At 2/8/2005 01:27 AM, Pekka Savola wrote:
>  2) we would create one FCFS block (e.g., under 239, or elsewhere) which 
> we could call "organizational-scoped addresses".  Those applications 
> which are to be used within an organisazation only could get the address 
> from there with one simple email application, no questions asked.

This doesn't help.  All it does is encourage more hard-coding of addresses 
into applications.  This is the fundamental problem here.  The primary 
reason that this is done is for (near) zero-configuration needs. (At least 
that is the argument of the app developers as to why they don't allow 
manual address configuration and it has validity.)

No matter what address block you use for this assignment, whether it's 
within 239/8 (NO, PLEASE!) or in some other block (I think Dave M. is 
against this), you still wind up with applications inside an organization 
whose addresses don't fit into the carefully planned scopes inside of the 
organization.

Remember, these organizations are subdividing the 239/8 space into multiple 
scopes that are larger than the Local Scope and smaller than the Org-Local 
Scope.  THEREFORE YOU CAN'T ASSIGN AN ADDRESS TO THESE APPLICATIONS.  THEY 
MUST BE CONFIGURED BY THE NETWORK ADMINISTRATOR.  It is only the Network 
Administrator that knows what range/scope that the application should 
operate in and thus it CANNOT be know ahead of time and therefore cannot be 
a hard-coded, assigned address.

Beau

---

From: Beau Williamson <[email-masked]>
Date: Tue, 08 Feb 2005 10:44:00 -0600

At 2/8/2005 09:40 AM, Pekka Savola wrote:
>Then the problem statement mail which I sent yesterday does not solve the 
>root problem either, because the application developers will _still_ want 
>to get the globally scoped addresses from IANA and glue it instead of 
>implementing this "service discovery inside an organization" -shim.

It certainly will if we don't at least define and standardize a simple, 
light-weight discovery scheme.  That's my fundamental goal in this 
discussion.

1) Define the protocol then

2) IANA refers all requests for hard-coded addresses to this protocol.

Beau

---

From: Beau Williamson <[email-masked]>
Date: Tue, 08 Feb 2005 10:46:59 -0600

>         here (at least in their current form).

Right.  IMHO, SADP is a closer match but it too will require some 
work.  The good news is that the draft has expired and thus it is not 
implemented yet.  Hopefully, we can start with the old drafts of SADP and 
rework it slightly to provide this service.

Beau

---

From: Pekka Savola <[email-masked]>
Date: Tue, 8 Feb 2005 18:47:30 +0200 (EET)

> 2) IANA refers all requests for hard-coded addresses to this protocol.

True.  But the requirements for this protocol are much more difficult 
than those which I sent out yesterday, because it will need to work 
across organizational boundaries as well.  If it doesn't, based on 
DaveM's data, almost no application will find it sufficient for their 
needs and go for IANA assignment in any case.

---

From: "Marshall Eubanks" <[email-masked]>
Date: Tue, 08 Feb 2005 11:54:27 -0500

On Tue, 8 Feb 2005 07:56:25 -0800
> 	really used by embedded devices for some type of service

The financial houses are different beasts - but IMHO what everyone else is
really trying to do is some sort of ZeroConf on the LAN or enterprise WAN.

The key to ZeroConf is that NO server or server like application is allowed.

From http://www.zeroconf.org/ I note

To achieve AppleTalk ease-of-use in IP, there are four main requirements:
	• 	Allocate addresses without a DHCP server (IPv4 Link-Local Addressing)
	• 	Translate between names and IP addresses without a DNS server (Multicast DNS)
	• 	Find services, like printers, without a directory server (DNS Service Discovery)
	• 	Allocate IP Multicast addresses without a MADCAP server (future work)

Hmm. I note the fourth bullet point - maybe this is really a zeroconf task.

If Dave Thaler is listening, maybe he could describe a little of the interactions
 between SADP and ZMAAP and what happened to both protocols, as he was a co-author on both.

I will ask Stuart Cheshire what he view of ZMAAP is.

Regards
Marshall

> 	here (at least in their current form).

 would agree - SIP could be used for source discovery, but it is not too
interesting / useful

---

From: John Kristoff <[email-masked]>
Date: Tue, 8 Feb 2005 10:58:49 -0600

On Tue, 08 Feb 2005 10:44:00 -0600

> 2) IANA refers all requests for hard-coded addresses to this protocol.

This has been an interesting discussion and I appreciate desire for
a protocol that solves the root problem.  I think no matter what is
decided, even if the solution is technically great, it may still not
help for a long, long time if ever.

As far as I can tell, many of the problems I encounter on live networks
come from vendor apps that have been hard coded with a group address
(or entire netblocks - i've seen a /8 in one case) without apparent
concern for allocation guidelines (whatever those may be).  I've tried
to contact at least one vendor in the past about their inappropriate
use of group addresses and never got anywhere.

Getting vendor apps to actually use any new scheme, whether simple
allocations or a dynamic protocol, may make this discussion purely
academic.

Meanwhile, the unusable multicast address swamp will grow.  :-/

John

---

From: Beau Williamson <[email-masked]>
Date: Tue, 08 Feb 2005 11:55:52 -0600

>allocations or a dynamic protocol, may make this discussion purely

True, but if we don't provide SOME sort of recommended, workable solution, 
then we have NO chance to get them to change their behavior.

Example conversation:

"Mister app developer, please stop hard-coding you applications like 
this.  It is a big evil."

"And what do you suggest I do to solve the problem?  I can't manually 
configure every client PC in the network."

"I don't know.  Can't you think of something?"

Bzzzzt.  Wrong answer.  Let's at least provide an answer and then put 
pressure on them to conform.

Beau

---

From: Beau Williamson <[email-masked]>
Date: Tue, 08 Feb 2005 15:47:50 -0600

At 2/8/2005 10:47 AM, Pekka Savola wrote:
>>>the root problem either, because the application developers will _still_ 
>>>want to get the globally scoped addresses from IANA and glue it instead 
>>>of implementing this "service discovery inside an organization" -shim.
>>
>>light-weight discovery scheme.  That's my fundamental goal in this discussion.
>>
>True.  But the requirements for this protocol are much more difficult than 
>those which I sent out yesterday, because it will need to work across 
>organizational boundaries as well.

As a long term goal that's fine, but we have a really serious problem now 
almost exclusively in the Enterprise network and very little of this is 
currently a problem beyond the Enterprise.  (Heck, we can't seem to get 
ubiquitous multicast services enabled throughout the Internet much less 
worry about dealing with scopes between the Enterprise and the total global 
Internet.)

If we can solve this problem both in the Enterprise and beyond, then that's 
great. But what I don't want to see is us delaying the development of 
something that solves the serious problem that we have right now inside the 
Enterprise.

I propose that we first rework the SADP spec to allow it to solve the 
problem here and "while we go about it" we look into how we might extend 
the model to cover the cases beyond the Enterprise.  (I think that it might 
be possible.)

>   If it doesn't, based on DaveM's data, almost no application will find 
> it sufficient for their needs and go for IANA assignment in any case.

I don't buy this.  I think you will find that most all popular commercial 
applications are currently operating at the Enterprise or smaller scope and 
very few are intended to go beyond the Enterprise scope.

Beau

---

From: Beau Williamson <[email-masked]>
Date: Wed, 09 Feb 2005 10:51:52 -0600

At 2/9/2005 08:10 AM, Stig Venaas wrote:
>On Mon, Feb 07, 2005 at 07:50:07PM -0600, Beau Williamson wrote:
>[...]
>I've finally read through this thread, and this sounds pretty much
>like what I have in mind. SADP is a good start, but doesn't quite
>do what I think is needed.

That's correct, the expired SADP draft is only a starting point.  It will 
need to be tweaked a bit for this.

>I believe it needs to work in a zero-conf environment. I think you then
>need some sort of enterprise-wide (site/organization scope?) multicast
>DAD. If we could have a standardized address range for this usage, apps
>might try some random address inside that range and perform DAD.

Actually, if you look closely at RFC 2365 you will find that we already 
have two standardized scopes (Local and Enterprise, aka Org-Local) that 
would provide an expanding search set of scopes to use via a well-known 
SADP Scope Relative address.  Clients would come up and first try the Local 
Scope and then the Enterprise Scope trying to locate a Server.

>If you have some specific application with a server and a set of
>clients, the server can either be configured with a multicast address
>or do the DAD above. The clients might then learn the address to use
>with say SADP.

Yep.

>Another difficulty I see, is that an application might consist of a
>number of identical devices. They must somehow negotiate an address
>between them. Maybe one of them needs to be elected as a "server" and
>select and announce an address. This election needs to work in a
>fully automated way and be performed between the application devices.

Correct.  In a non client/server model you must at least designate one host 
to perform the SADP Server function, configure it with the multicast 
address(es) to use and then let it communicate this to the other clients/peers.

>Both SADP and the DAD-mechanism would require well-known multicast
>addresses.

Again, all we need is to get a Scope Relative address (ala MADCAP and 
SDR/SAP) assigned to this new form of SADP.

>DAD could perhaps be added to SADP. You basically need a new type of
>SADP request where you ask for applications using a given address
>instead of which address an application uses.

I don't see why this would be necessary.

>Perhaps some sort of name-space is required to make sure each
>application has some unique identifier.

Maybe a simple hash mechanism on the application name is 
sufficient.  However, this is one of the details that we need to work out 
and extend the SADP draft to cover.

Beau

---

From: Beau Williamson <[email-masked]>
Date: Wed, 09 Feb 2005 11:11:10 -0600

Guys,

I think you are making this too hard.  We don't need DAD.  The allocation 
of the multicast address(es) to use is under the control of the network 
admin when he/she configures the application server for IT'S assigned 
addresses.  Therefore, there is no need for DAD.

In this case, ALL applications that use SADP to locate THEIR server send on 
the same Scope Relative address.  The clients multicast a packet that 
uniquely identifies their application. Only THEIR application server 
responds to this request.  All other application servers listening on the 
SADP Scope Relative address ignore requests not for their application.

Beau

---

From: Stig Venaas <[email-masked]>
Date: Wed, 9 Feb 2005 18:50:43 +0100

> SADP Scope Relative address ignore requests not for their application.

I already sent one response to this, I then forgot somethingh I wanted
to say, sorry.

I think the above is useful and in many cases will be sufficient. But
as I wrote in my other reply I think there also are cases where more
is needed. It appears to me though that we could try to solve the
problem above first.

If we do this right, we can later work on two additional problems if
needed.

They are:

1. DAD

   If there is no administrator, how does the applications figure out
   which addresses to use on their own. I think we then also should
   allocate a specific group range.

2. Automatical election of application server amongst identical devices

   In the administrated case the administrator performs the election.
   For zeroconf this needs to be automatic. Some simple mechanism
   similar to DR election might be fine.

Stig

---

From: Stig Venaas <[email-masked]>
Date: Wed, 9 Feb 2005 18:40:28 +0100

On Wed, Feb 09, 2005 at 10:37:53AM -0500, Marshall Eubanks wrote:
> On Wed, 9 Feb 2005 15:10:24 +0100
>  Stig Venaas <[email-masked]> wrote:
> Hello;
> I agree. Do you have a specific protocol in mind for Duplicate Address Detection, or is this
> TBD ?

TBD

> There are 3 private address blocks in RFC1918. Maybe multicast needs a private /20 or even /16 
> devoted to this in addition to 239/8. I would argue that collisions would be pretty unlikely in a
> /16, given the actual number of multicast applications we are likely to see. (If addresses are
> picked at random, collisions are likely starting with about 2 x the square root of the number of
> addresses, which is 128 for a /20 and 512 for a /16

Right, sounds good

> Any reason why this could be done just by picking the lowest IP address in the time honored fashion?

Yes. Some election mechanism is needed, but it could just be lowest
address. I can see some issues, but at least, there must be some way.
It might be better to have a standardized way rather than having each
application vendor solving this on their own.

> Do you mean that there would need to be a handful of well-known 224 type addresses,
> like, say, ALL-SADP-SERVERS ? Or something else ? If the former, a question to me
> is should they be local or globally routed ?

I'm thinking of a single well-known enterprise scoped (or similar) group
for SADP or (similar protocol). For DAD you may need another such
well-known group, or possibly the same...

> ZMAAP has this.
> I am not sure I parsed this. Do you mean that IP addresses might not be enough ? If not, why
> not ? Or are you worried about multiple applications on the same box ? Or are you arguing for a DNS
> type solution ?

What I'm saying is more like, vendor A has a couple of different
products (applications) say A1 and A2. Another vendor B has some
other applications B1, B2, B3.

If you deploy A1 products, you then want all the A1's to find
each other, agree on a multicast address etc. An A1 box might
go out and ask whether there are any A1s out there.

If vendor B happened to use "A1" as th identifier for their
product, you would have a problem.

Hard to explain this. But it's sort of like instead of requiring
different applications (products) to have different multicast
addresses today, you instead use a common multicast group, and
then you need these applications (products) to have some sort of
unique id on the application level instead.

Maybe this isn't a problem. The identifier might actually be
something like "Acme Inc, Lightsensor 678P". They can then find
eachother based on that name, and it's pretty well guaranteed
that no one else uses the same"...

Stig

---

From: Stig Venaas <[email-masked]>
Date: Wed, 9 Feb 2005 15:10:24 +0100

Stig

---

From: Stig Venaas <[email-masked]>
Date: Wed, 9 Feb 2005 18:25:51 +0100

> addresses.  Therefore, there is no need for DAD.

You may know this better than me, but I'm afraid there are lots of
vendors that want to have multicast applications that work without
any administrator configuring things.

1. There may be no administrator, no-one able to do it (home users?)

2. It should work without having some additional server deployed

3. Some devices may be very basic and for several reasons not have
   a usable interface for configuring which addresses to use. And
   in the "identical devices" case which one should decide the
   address.

IMO we need to satisfy these, else I'm not so sure it will solve
the problem. But I've never talked to such vendors, so these are
just my personal assumptions.

Stig

---

From: "Marshall Eubanks" <[email-masked]>
Date: Wed, 09 Feb 2005 10:37:53 -0500

Hello;

ZMAAP has this.

Regards
Marshall

---

From: Beau Williamson <[email-masked]>
Date: Wed, 09 Feb 2005 11:49:28 -0600

>just my personal assumptions.

Currently, the space of applications that fall into this category are not 
an issue since they are pretty much non-existent (at least at the moment).

I'm trying to focus on the bigger problem (problematically speaking) that 
we currently have and would prefer to not try to boil the ocean for all 
cases including those above.

If someone wants to tackle the above issues, fine but I'm not focusing on 
them at the moment.

Beau

---

From: Beau Williamson <[email-masked]>
Date: Wed, 09 Feb 2005 11:52:08 -0600

>that no one else uses the same"...

Right.  The goal is to keep it dirt simple.  I think unique names of 
sufficient length should be more than adequate.

Beau

---

From: Beau Williamson <[email-masked]>
Date: Wed, 09 Feb 2005 12:01:18 -0600

>is needed. It appears to me though that we could try to solve the

Right.

>    allocate a specific group range.

The idea is that there IS an administrator that sets up the application 
server and configures the addresses. That person is responsible to insure 
there are no duplicate address assignments.

Having said that, the model could ALSO support having the server "trying" 
to get addresses via MADCAP if the administrator doesn't want to do manual 
configuration.  I'd see this as a server configuration option like checking 
"Use DHCP/Manual IP address" options on workstations.

>    similar to DR election might be fine.

Yes, this could be an extension.  However, to keep things dirt simple and 
get things going quickly, I think we can live with "near"-zero 
configuration, i.e. you have to configure the server(s) but not the clients.

Beau