Re: New draft on embedding the RP address in IPv6 multicast address

[Marshall Eubanks <tme@multicasttech.com>]

[ post by non-subscriber.  with the massive amount of spam, it is easy to
 miss and therefore delete mis-posts.  so fix subscription addresses! ]

Yes, I think so, this requires interdomain flooding, just like 
interdomain MSDP in IPv4.

However, you might be able to make ASM "SSM like" in that, if you
find the group address by some means out of band, you can join to the RP 
and either send or receive.

It is also not clear to me how this would work in, say, a 
teleconference. Doesn't it limit the group to only _one_ RP? What 
functionality does it give that either SSM or MSDP doesn't ?

Marshall

Mike O'Connor wrote:
> If all source active advertisements are carried in PIM packets won't we
> need to flood and prune our local source PIM packets to all or our
> interdomain neighbors? Would this draft accommodate PIM sparse mode?
>
> -Mike
>
> --
> Mike O'Connor,                  E-mail: moc@es.net
> Network Engineer                Energy Sciences Network (ESnet)
> East coast: +1 631 344-7410     West coast: +1 510 486-7421
> Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
>
>
>
>
> -----Original Message-----
> From: Pekka Savola [mailto:pekkas@netcore.fi] 
> Sent: Thursday, October 10, 2002 8:20 AM
> To: Marshall Eubanks
> Cc: mboned@network-services.uoregon.edu; v6ops@ops.ietf.org; Brian
> Haberman
> Subject: Re: New draft on embedding the RP address in IPv6 multicast
> address
>
>
> On Thu, 10 Oct 2002, Marshall Eubanks wrote:
>
> > On Thu, 10 Oct 2002 14:21:44 +0300 (EEST)
> > Pekka Savola <pekkas@netcore.fi> wrote:
> >
> > > Hello,
> > Dear Pekka;
> >
> >   A quick question about Section 4 :
> >
> >  o "plen" MUST NOT be 0 (ie. not SSM)
> >
> >     o "plen" MUST NOT be greater than 96
> >
> >   The address of the RP can be obtained from a multicast address by
> >   taking the following steps:
> >
> >      1. take the last 96 bits of the multicast address
> >
> >      2. zero the last 128-"plen" bits, and
> >
> >      3. replace the last 4 bits with the contents of "RPad".
> >
> >
> > If "plen" is = 1 (say), which seems to be allowed, then how do I zero 
> > the last 127 bits of a 96 bit slice of a multicast address ?
> >
> > I am pretty sure this is not what you mean, but this is what I read it
>
> > to say.
>
> The first bullet makes it implicit that those 96 bits are placed at the 
> beginning of a 128-bit address struct (which is assumed to have been 
> initialized to zero).
>
> But that should be clarified so there will be no misunderstandings, 
> thanks.
>
>  
> > Regards
> > Marshall Eubanks
> >
> >
> >
> > > Me and Brian Haberman have submitted a new draft to 
> > > internet-drafts@ietf.org. In the interim, it's available at:
> > >
> > > http://www.netcore.fi/pekkas/ietf/draft-savola-mboned-mcast-rpaddr-0
> > > 0.txt
> > >
> > >         "Embedding the Address of RP in IPv6 Multicast Address"
> > >
> > > Abstract                                               
> > >   As has been noticed, there is exists a huge deployment problem
> with
>
> > >   global, interdomain IPv6 multicast: PIM RPs have no way of
> > >   communicating the information about multicast sources to other
> > >   multicast domains, as there is no MSDP, and the whole interdomain
> Any
>
> > >   Source Multicast model is rendered unusable; SSM avoids these
> > >   problems.  This memo outlines a way to embed the address of the
> RP in
>
> > >   the multicast address, solving the interdomain multicast problem.
> The
>
> > >   problem is three-fold: specify an address format, adjust the
> > >   operational procedures and configuration if necessary, and modify
> > >   receiver-side PIM implementations.  In consequence, there would
> be no
>
> > >   need for interdomain MSDP.             
> > > It's 9 pages.
> > >
> > > Comments are welcome, either directly or to the list(s) if 
> > > appropriate.
> > >
> > > --
> > > 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

--
                                 Regards
                                 Marshall Eubanks

This e-mail may contain confidential and proprietary information of
Multicast Technologies, Inc, subject to Non-Disclosure Agreements


T.M. Eubanks
Multicast Technologies, Inc
10301 Democracy Lane, Suite 410
Fairfax, Virginia 22030
Phone : 703-293-9624       Fax     : 703-293-9609
e-mail : tme@multicasttech.com
http://www.multicasttech.com

Test your network for multicast :
http://www.multicasttech.com/mt/
 Status of Multicast on the Web  :
 http://www.multicasttech.com/status/index.html