[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Re: ISP scenarios comments (multicast)
>On Thu, 19 Sep 2002 04:19:43 0300 (EEST) Pekka Savola <pekkas@netcore.fi>
wrote.
>On Wed, 18 Sep 2002, Brian Haberman wrote:
>> Pekka Savola wrote:
>> >
>> > On Wed, 18 Sep 2002, bkhabs wrote:
>> >
>> > > Pekka,
>> > >
>> > > >On Wed, 18 Sep 2002 18:25:58 0300 (EEST) Pekka Savola
<pekkas@netcore.fi>
>> > > wrote.
>> > > > * multicast issues
>> > > > - support is yet a bit .. raw or non-existant.
>> > >
>> > > Are you talking standards or implementations?
>> >
>> > Both.
>> >
>> > As for standards, there is the problem with MSDP. Another partially
>> > related one is related to site-local group scoping. There needs to be
>> > some feature like 'bsr-border' to site-local scopes to work properly
>> > inside only one PIM domain, I think.
>>
>> I brought up the issue of site-locals and PIM in a PIM for v6 draft a
>> few years ago. The PIM group came to consensus that in order to use
>> site-locals in certain PIM messages (e.g. C-RP or Bootstrap) then a
>> PIM domain border MUST be the same as the site-local border.
>>
>> That draft was eventually merged into the new pim draft.
>
>Ok; this is still a bit problematic with the one PIM domain requirement..
>:-/
I don't think it is problematic when you consider the overhead that
would have to occur in order to support PIM domain != site-local domain.
The major problem is that PIM messages are mostly sent hop-by-hop with
IP addresses in the payload. So, the Bootstrap message is transmitted
hop-by-hop using the All-PIM-Routers link-local multicast address. But
the BSR address is in the payload. That means that a site-local border
router would have to recognize the Bootstrap message, parse into the
PIM payload and check to see if the BSR-Address was a site-local.
In this case, I prefer simplicity. Let pim domain == site-domain.
>
>> > > > - should we focus on SSM only
>> > >
>> > > For the short term definitely.
>> >
>> > I believe most don't realize that's the only option at the moment.
>>
>> Agreed. The interesting thing is that, just like in v4, multicast
>> in v6 is lagging in development effort.
>
>Yes. This is sad as SSM video broadcasts could be one "killer"
>application for IPv6 (it would be available for v4 too.. :-)
>
>> Another possibility is whether or not RFC 3306 can be exploited to
>> help with the issue of RP location and such. Haven't had much time
>> to look into that though.
>
>This might be an interesting point to develop more. It's quite possible
>if we can hard-code assumptions about address assignment for the RP there.
>Possibly through an additional bit flag in the address. This would have to
>go to the PIM implementation then, though.
You can't encode the RP in the field. But, a new RP discovery mechanism
could utilize the prefix information to know where to look for the RP.
Brian