[Xorp-hackers] vif indeces

[pmv]

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?


> 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?


>
>   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.
>   Linux largely follows MROUTING in its implementation, and there are
> weaknesses in this implementation; struct mfcctl2 contains a bitfield mask
> which is 32 bits wide. This means that multicast forwarding can't scale
> beyond 32 interfaces in either Linux or any of the BSDs.
>   MROUTING was a research implementation in the beginning, and one of the
> goals was to keep multicast forwarding separate from the unicast forwarding
> path. Whilst I've had discussions privately with Pavlin Radoslavov about how
> this limitation might be addressed, there hasn't been any demand from
> outside to fix it -- yet.
>
> 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.

Thanks for taking time to reply.

-- 
pmv
random hacker
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20090512/d1b2535d/attachment.html