[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: New draft on embedding the RP address in IPv6 multicast address
[ 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: 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 1:47 PM
To: Mike O'Connor
Cc: Marshall Eubanks; 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
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