[Xorp-hackers] vif indeces

[Bruce Simpson]

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