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

[Pekka Savola <pekkas@netcore.fi>]

On Thu, 10 Oct 2002, Mike O'Connor wrote:
> I wasn't sure how the four bit RPad field is used, but the thought of a
> single RP limitation occurred to me as well.  I don't think that even if
> the RPad allows for 16 RP's per group address it is large enough. There
> have already been Access Grid conferences that have had thirty sites
> join, each with their own RP. It's probably not a good idea to propose a
> number that's already too small:) If there were 16 RP's per PIM domain
> it might be enough.

Note that the proposed mechanism allows for _one_ RP per _group_, and 16
RP's per PIM domain.

Perhaps you misunderstood the reason of "RPad".


> -----Original Message-----
> From: Marshall Eubanks [mailto:tme@multicasttech.com] 
> Sent: Thursday, October 10, 2002 12:16 PM
> To: Mike O'Connor
> Cc: Pekka Savola; mboned@network-services.uoregon.edu;
> v6ops@ops.ietf.org; Brian Haberman; nesg@es.net
> Subject: Re: New draft on embedding the RP address in IPv6 multicast
> address
> 
> 
> 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
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>
> > 
> 
> 
> 

-- 
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