[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! ]

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