Subject: Re: Re: ISP scenarios comments (multicast)

From: bkhabs <[email-masked]>
Date: Thu, 19 Sep 2002 04:58:36 -0700 (PDT)

>On Thu, 19 Sep 2002 04:19:43  0300 (EEST) Pekka Savola <[email-masked]>
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
<[email-masked]>
>> > > 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

---

From: Pekka Savola <[email-masked]>
Date: Thu, 19 Sep 2002 23:08:38 +0300 (EEST)

> In this case, I prefer simplicity.  Let pim domain == site-domain.

I agree with the simplicity -- but the problem I was referring to was due 
to the fact that for all practical purposes, currently there can only be 
one PIM domain.  That limits the applicability of multicast quite a bit.

For one perspective, look at one PIM-domain at:

http://sem2.renater.fr/m6bone/

Multicast works -- kinda.

> You can't encode the RP in the field.  

Which field?  Destination address could include the address of the RP,
with some rather strict assumptions.

> But, a new RP discovery mechanism

That too.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

---

From: Brian Haberman <[email-masked]>
Date: Thu, 19 Sep 2002 17:57:17 -0400

Pekka,

> one PIM domain.  That limits the applicability of multicast quite a bit.

Well, actually you can have more if the PIM domains are completely
contained within a site-local domain.  Using site-locals for multicast
is limiting the applicability anyway.

> Multicast works -- kinda.

Yes, I have looked at their network before.  Interesting.  I am
assuming that they are not using site-locals.

> with some rather strict assumptions.

I was talking about the prefix field in the multicast address.  There
are not enough bits to represent an RP unless you did some interesting
address assignments for RPs and can encode the entire address in 64
bits.

Brian

---

From: Pekka Savola <[email-masked]>
Date: Fri, 20 Sep 2002 01:22:06 +0300 (EEST)

> assuming that they are not using site-locals.

Yes, they're not using site-locals, but some parties would like to use 
site-locals in addition to globals -- and that's impossible at the moment 
with current implementations.

We use unicast prefix-based addresses there btw.

> address assignments for RPs and can encode the entire address in 64

Both are doable.  One idea I've been toying with is specifying some
default suffix values (for example), and including a 16-bit(?) hash of the
RP's full address to be able for the recipients to verify the guess.