Re: [pim] MRIB and multiple RP's
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [pim] MRIB and multiple RP's




On Nov 11, 2006, at 6:48 PM, Bandar Al-Turaif wrote:

I know that the RP at it current state does not know any details about DR’s. My question is, is it possible to modify PIM-SM and make it learn.

Our research is about relocating the RP depending on the shared tree cost, so it is very important for us to know the total cost of tree (link cost metric, or delay metric).

 

With my best regards.

 

Bandar Al-Turaif

2 cents:

Of course it is possible.  However you should consider that a bidir RP does not require a physical
system to be used, its just any arbitrary point in the network.  This is both good and bad for what you
want.  Good, because it makes RP relocation simple: there's no need to physically reconfigure a router.
Bad because there's no central place to collect the information you are interested in.

Of course, you are really interested in just Sparse-mode and not bidir.  IMHO what you want is
a "two-stage" effort.  The source and/or receiver DR registers with a "RP-allocation server" (ie something that
does the calculation to determine the best location of the RP) and then a redistribution of RP
information for the specific multicast group.  (ie a /32)

FWIW, the bootstrap router protocol could quickly redistribute the /32 RP map within an enterprise.
However, doing this across PIM domains would be problematic.

So, you have a potentially good idea, but it depends on the continued deployment of sparse-mode
(ie some, like me, feel sparse-mode is no longer useful and should be replaced by SSM procedures)
and you need to define a protocol that is going to be rather complex, especially if it is used interdomain.

At this point, I do not feel you'll get any vendor to implement it.  Just an opinion.
_______________________________________________
pim mailing list
pim at ietf.org
https://www1.ietf.org/mailman/listinfo/pim

Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.