[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