Round 2

[Ivan R. Judson]

Thanks,

I think the motivation I see is that we want venues to scale to uncountable
numbers and we need to have dynamic multicast address use because there is
not an infinite supply.  That points out that we're trying to build a system
that is responsible about its stewardship of resources (in this case IPv4
multicast addresses), so it only makes sense to design the system and
configure it by default to use the most scalable solution to the addressing
problem.

FYI, I'd like sign off on this email before it goes and I want it to go out
today.  Please review and either voice your concern or voice your approval.
If approval is conditional specify the condition.

--Ivan

> -----Original Message-----
> From: Terry Disz [mailto:disz at mcs.anl.gov] 
> Sent: Monday, February 10, 2003 3:44 PM
> To: judson at mcs.anl.gov; 'AG Dev'
> Subject: RE: Round 2
> 
> 
> 
> In the following comments, no motivation is supplied to the 
> community for the reasons behind the change to dynamic 
> address allocation and the ensuing issues. You might want to 
> supply some words of justification so it doesn't seem an 
> arbitrary change.
> 
> 
> >
> > The problem we have is the following:
> >
> > - AG 1.0 used statically assigned multicast addresses for the media 
> > (e.g. one address for video and one address for audio).
> >
> > - There has been some work at making sure this set of 
> addresses work, 
> > including various firewall, bridge, and tunneling solutions.
> >
> > - AG 2.0 uses dynamically assigned addresses for media by default, 
> > however static addressing is supported. The static address support 
> > should ensure events like SCGlobal can succeed.
> >
> > - We can't support infinite backwards compatibility , but want to 
> > backward compatibility enough for users to comfortably 
> transition (we 
> > don't want to abandon the community!)
> >
> > - We're moving to dynamic addressing, but before we can do entirely 
> > dynamic address allocation we need to ensure the basic services are 
> > fault tolerant and robust enough to handle the problems associated 
> > with network brokenness.
> >
>