headers
Beau Williamson | 1 Feb 2005 19:15
Picon
Favicon

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

At 1/30/2005 09:29 PM, John Kristoff wrote:
>On Fri, 28 Jan 2005 18:36:57 -0600
>Beau Williamson <bwilliam <at> cisco.com> 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.
(Continue reading)

Permalink | Reply | 44 comments |
headers
Beau Williamson | 1 Feb 2005 21:38
Picon
Favicon

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

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.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Leonard Giuliano | 1 Feb 2005 23:10
Favicon

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


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
(Continue reading)

Permalink | Reply | 41 comments |
headers
Marshall Eubanks | 2 Feb 2005 01:07

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

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)
 Leonard Giuliano <lenny <at> juniper.net> wrote:
> 
> 
> 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.
(Continue reading)

Permalink | Reply | 39 comments |
headers
John Kristoff | 2 Feb 2005 04:20
Favicon

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

On Tue, 01 Feb 2005 19:07:07 -0500
"Marshall Eubanks" <tme <at> multicasttech.com> wrote:

> 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

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
_______________________________________________________________
user interface: http://darkwing.uoregon.edu/~llynch/mboned.html
web archive:  http://darkwing.uoregon.edu/~llynch/mboned/
Permalink | Reply | 1 comment |
headers
Marshall Eubanks | 2 Feb 2005 05:05

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

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
 John Kristoff <jtk <at> northwestern.edu> wrote:
> On Tue, 01 Feb 2005 19:07:07 -0500
> "Marshall Eubanks" <tme <at> multicasttech.com> wrote:
> 
> > 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
> 
> 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
> _______________________________________________________________
> user interface: http://darkwing.uoregon.edu/~llynch/mboned.html
> web archive:  http://darkwing.uoregon.edu/~llynch/mboned/

_______________________________________________________________
(Continue reading)

Permalink | Reply | 0 comments |
headers
Beau Williamson | 2 Feb 2005 23:46
Picon
Favicon

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

At 2/1/2005 04:10 PM, Leonard Giuliano wrote:

>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.

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.

>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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Beau Williamson | 3 Feb 2005 00:22
Picon
Favicon

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

At 2/1/2005 06:07 PM, Marshall Eubanks wrote:
>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.

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

_______________________________________________________________
user interface: http://darkwing.uoregon.edu/~llynch/mboned.html
web archive:  http://darkwing.uoregon.edu/~llynch/mboned/
Permalink | Reply | 36 comments |
headers
Marshall Eubanks | 3 Feb 2005 02:47

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

On Wed, 02 Feb 2005 17:22:09 -0600
 Beau Williamson <bwilliam <at> cisco.com> wrote:
> At 2/1/2005 06:07 PM, Marshall Eubanks wrote:
> >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.
> 
> 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.
> 

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).
(Continue reading)

Permalink | Reply | 34 comments |
headers
Marshall Eubanks | 3 Feb 2005 02:51

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

On Wed, 02 Feb 2005 17:22:09 -0600
 Beau Williamson <bwilliam <at> cisco.com> wrote:
> At 2/1/2005 06:07 PM, Marshall Eubanks wrote:
> >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.
> 
> 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.
> 

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"
(Continue reading)

Permalink | Reply | 0 comments |

Gmane