[Xorp-hackers] Getting Mrt and Mfc information from PIM

[Bruce Simpson]

Chintan Shah wrote:
> Hello,
>
> We are implementing a separate process in xorp for multicast fast repair.
> For this process, I need the Mrt and Mfc information exactly as it is 
> in the
> PIM process.   I also needed the Mrib information but that was much 
> easier to get
> because of the route redistribution mechanism in the RIB process.
> From what I see, there are about 55 events that can change the
> state of the Mrt table.  This would be very difficult to track in a 
> separate process without
> any redistribution  mechanism.

OK, so you know the MRIB is actually not the multicast routing table, 
but rather the unicast routes used by PIM's uRPF checks. So far, so good.

> I wanted to ask if there is any centralized mechanism in the
> PIM process to make the changes in the Mrt table that I could follow 
> and use to inform
> my process whenever there is a change in the table entry. Or if there 
> can be some other
> alternative.

It's a difficult one.

    At the moment, the MRT library holds the state for the Multicast 
Forwarding Cache (MFC) as used by PIM. Both PIM and the FEA process link 
against this library, although the FEA mostly just uses static 
definitions and include files from libmrt, without actually using the 
abstractions from the library.

    I think you've run into a barrier which other contributors have 
also, and that is that a lot of the intelligence about the MFC is 
actually centralized in the PIM-SM process.

    There is currently no observer idiom in the mfea_client.xif for the 
MFC *itself* and you would probably need to modify the pim.xif XRL 
interface to supply some of the coupling you need to PIM. What hooks 
exist there at XRL are mostly for implementing the management interface 
for the PIM-SM process.

    In practice this isn't really an issue, unless you actually need to 
modify multicast routing behaviour beyond PIM-SM v2 as implemented in 
XORP at the moment.

    I did play with the idea of adding a more generic event mechanism to 
XRL last year to support SNMP traps, but there wasn't interest in it. 
XRL itself is utterly tied to C++.

    AMQP could offer an alternative to XRL, however, some of the more 
popular implementations depend on having an Erlang bytecode interpreter 
to provide the broker service -- and XRL came into being to solve 
certain bootstrapping problems to do with the situation where you 
implement an IP router with the IPC using IP itself.

thanks,
BMS