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

From: "Mike O'Connor" <[email-masked]>
Date: Thu, 10 Oct 2002 10:49:36 -0700

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

Pekka,

Yes, I was not clear on RPad, thanks for clearing that up.

-Mike

--
Mike O'Connor,                  E-mail: [email-masked]
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:[email-masked]] 
Sent: Thursday, October 10, 2002 1:47 PM
To: Mike O'Connor
Cc: Marshall Eubanks; [email-masked];
[email-masked]; Brian Haberman; [email-masked]
Subject: RE: New draft on embedding the RP address in IPv6 multicast
address

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:[email-masked]]
> Sent: Thursday, October 10, 2002 12:16 PM
> To: Mike O'Connor
> Cc: Pekka Savola; [email-masked];
> [email-masked]; Brian Haberman; [email-masked]
> 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: [email-masked]
> > 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:[email-masked]]
> > Sent: Thursday, October 10, 2002 8:20 AM
> > To: Marshall Eubanks
> > Cc: [email-masked]; [email-masked]; 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 <[email-masked]> 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 
> >>>[email-masked]. 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