[Xorp-hackers] vif indeces

[pmv]

Thank you very much. This information is very helpful. Kudos on the
excellent high-level and devel documentation as well. All open source
projects should aim to be as developer-friendly (even though it is in C++).
:)

On Tue, May 12, 2009 at 2:49 PM, Bruce Simpson <bms at incunabulum.net> wrote:

> pmv wrote:
>
>> Good day.
>>
>>    At the moment, b) is probably the cleanest solution overall. If it
>>    is a simple matter of looking up the MFEA VIF index based on a VIF
>>    name, then please feel free to submit a patch which exposes
>>    ProtoNode<V>::vif_find_by_name() via an XRL.
>>
>>
>> Will do, thanks.
>>
>> Another thing. Does an IGMP XRL client need to register with finder as a
>> target, or would adding XrlStdRouter handlers for
>> 'mld6igmp_client/0.1/add_membership4' (and others) and calling
>> XrlMld6igmpV0p1Client::send_add_protocol4() be enough?
>>
>
> You need to do a bit more work in a XORP process to implement an XRL target
> instead of just sending XRLs. An XrlStdRouter instance is enough to send
> XRLs, but not to receive them. For an example, look at the OLSR code:
>
> http://cvsweb.xorp.org/cgi-bin/cvsweb.cgi/xorp/contrib/olsr/xorp_olsr.cc?rev=1.4
>
> ...here, in OLSR's main() function, the XrlStdRouter instance is created
> before the XrlOlsr4Target instance, because its constructor needs to see an
> XrlRouter instance. The XrlOlsr4Target class is a proxy which glues the
> implementation to the XRL layer. It is automatically generated from the
> xrl/targets/olsr4.tgt file.
>
>   Assuming you write a .tgt file for your process's XRL target, and add
> handlers for the mld6igmp_client XIF, as with any other XORP component, the
> Finder should be notified of the registration when your process starts. Feel
> free to use the contrib/olsr code as a reference.
>
>   One of the shortcomings of using the GNU Autotools build system is that
> you cannot implement new XRL targets without actually adding them to the top
> level xrl/ directory. I managed to overcome this limitation in Jam and
> Boost.Build when developing OLSR, but that is not officially supported, and
> it is likely the Jamfiles will go away in future. My understanding is that
> we plan to switch to a new Python-based build tool, SCons, which should
> eliminate this tedious and inconvenient step.
>
>   If you want to build your application using XORP 1.6, then you will need
> to add your .tgt and .xif files to the global xrl/ directory, together with
> the relevant entries in Makefile.am.  It is entirely likely that XRL may
> change greatly in future for this and other reasons.
>
>
>>    Some background information:
>>      The MFEA code is very tied to the BSD MROUTING kernel multicast
>>    forwarding code -- and the VIF indexes in the MFEA aren't directly
>>    related to the FEA's notion of a VIF; they aren't redundant, as
>>    such, they are different identifiers.
>>
>>
>> If that is the case, which should take precedence? Which should be
>> authority for vif indeces, or furthermore between vif names and indeces? Are
>> there specific situations in which this should be a consideration?
>>
>
> I would rely on the MFEA for this mapping.
>
> XORP client processes should never use interface indexes directly; MFEA VIF
> indexes are entirely separate from any other notion of interface names or
> indexes, only the MFEA knows about them.
>
> Unfortunately, in extending IGMP, you've found a weak spot in the API where
> the MFEA VIF index has to be exposed for the XRLs to be useful. Up until
> now, this hasn't been an issue, because normally only PIM and IGMP interact
> with the MFEA directly.
>
>
>>
>>      In MROUTING, a VIF index is what's found in the 'struct mfcctl2'
>>    structure used to configure multicast forwarding, and I believe
>>    this is what the MFEA is dealing with internally
>>
>>  ...
>
>>
>>    There are platforms (e.g. Windows) where the multicast forwarding
>>    plane is configured in a completely different way, and the MFEA
>>    wouldn't be suitable for driving it without significant code
>>    refactoring.
>>
>>
>> So portability might be an issue then? I mostly work on FreeBSD
>> exclusively.
>>
>
> I wouldn't worry about it for now, although it is a hairy issue for the
> future which needs to be carefully considered.
>
> It is something we would need to revisit if the MFEA is refactored to
> support multicast forwarding planes other than MROUTING, but it shouldn't
> impact ongoing work with XORP on FreeBSD, as Linux suffers from the same
> issue.
>
> You can regard the multicast forwarding plane on FreeBSD and Linux as
> working more or less identically. Even though the Linux code is not directly
> derived from the 4.4BSD implementation (it is a clean-room GPLv2
> re-implementation), it is functionally identical, and the kernel APIs are
> more or less identical.
>
> thanks,
> BMS
>



-- 
pmv
PGP keyID 0xEA5EB160
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20090512/974ae303/attachment-0001.html