Subject: Re: AutoRP (was Re: RP announements from 192.42.36.1)

From: Tom Pusateri <[email-masked]>
Date: Fri, 26 Mar 1999 22:32:55 -0500

In message <[email-masked]> you write:
>> From: Tom Pusateri <[email-masked]>
>> 
>> >To clarify and summarize what I remember about this discussion:
>> >
>> >I suggested that Auto-RP ought to use relative scoped addresses
>> >and we walked through some scenarios.  The only issue was with
>> >making sure that AutoRP addresses weren't sparse-mode groups.
>> >Hence, you either need to hard code in a special case for the
>> >relative AutoRP addresses, or else you have to make sure you
>> >don't configure your RP with a range covering the AutoRP address.
>> 
>> I don't believe the limitation needs to be this strict.
>> 
>> I think the limitation is that if these groups are not
>> dense mode groups, then the RP for them should be statically
>> configured.
>
>
>This can be done, but is prone to errors, as it requires manual
>configuration for all scoped zones. Don't be surprised if people tend
>to change their scope zones very frequently (as some of them will).
>Configuring these addresses in the entire domain upon each
>reconfiguration defeats the purpose of automation. The current
>global address has restrictions, but is flexible enough to
>not require such global configurations.
>
>The mbone receipients may not be interested in getting into details
>in the Auto-RP design. Can we take this thread offline ? Or to
>the PIM working group list, which has a similar mechanism that
>might benefit from this discussion ?
>
>The only thing relevant to folks here is that a boundary for the two
>Auto-RP groups should always be set up on the border routers.
>
>-Liming

Actually, you may be able to use the auto-rp v1+ negative group
flag to distribute the dynamic relative scope addresses to be
flooded in dense mode but this may be subject to circular
dependencies. I'd have to think about the rules carefully.
That way, you would need just one relative scoped address to bootstrap
the others.

Tom