[rbridge] TRILL MIB rbridgeUniFibTable

[Mahesh Akula]

How about adding "Hop count" which may vary for each ECMP path from ingress
rbridge to egress rbridge?

Also for the indices how about adding nexthop rbridge nickname, instead of
nexthop Mac?

Regards,
Mahesh

On Tue, Nov 8, 2011 at 11:36 AM, Anil Rijhsinghani <anil at charter.net> wrote:

> Either there will need to be an accessible "dummy" object per row
> (can you think of anything useful instead?) or, one of those index objects
> could be made read-only but I'll need to check if that's allowed.
>
> Regards,
> Anil
>
> -----
>  On Tue, Nov 8, 2011 at 1:35 PM, Mahesh Akula wrote:
>
>  Hi Anil,
>
> I'm curious, if all the three objects in the table has MAX-ACCESS set to
> not-accessible, (as it will be the case if all 3 objects are part of the
> index),  how can any operations be performed on the table?
>
> Regards,
> Mahesh
>
>
> On Tue, Nov 8, 2011 at 10:18 AM, Anil Rijhsinghani < *anil at charter.net*>
> wrote:
> Mahesh,
>
> I did not consider ECMP being used this way, however in discussing
> further with Donald Eastlake – his comment is attached below – he
> indicates it could happen, whether intentionally or not.
>
> To accommodate this, I'll add rbridgeFibMacAddress to the index to make
> it unique. (I considered taking out rbridgeFibPort from the index, but
> that could make it non-unique if the same next-hop were attached to an
> RBridge via more than one port.)
>
> Regards,
> Anil
>
> -----
> On Nov 7, 2011, at 7:50 PM, Donald Eastlake wrote:
>
> It seems to me that this is possible.
>
> It will not usually happen as there will be a pseudo-node and there
> will be only one path out the port to the pseudo-node... However, the
> DRB can suppress the pseudo-node. The standard says that it SHOULD do
> this if there is only one adjacency, which is obviously no problem.
> But if there are 2 or more adjacencies out the port and the DRB
> suppresses the pseudo-node, then it seems to me that there can indeed
> be more than one ECMP path out a port to a particular destination.
> This will work fine as the frames will be unicast to the intended next
> hop...
>
> If the link is an Ethernet bridged LAN, this could cause more traffic
> on the port than on some other port which also has an ECMP path to the
> destination, but only one such path, perhaps causing some congestion.
> On the other hand, if the link is something exotic like a switching
> fabric link, there might be little interference between the unicast
> traffic out the port to different ECMP adjacencies on the link...
>
> Thanks,
> Donald
>
> -----
> On Nov 7, 2011, at 5:00 PM, Mahesh Akula wrote:
>
> Dear Authors,
>
> As per the draft-ietf-trill-rbridge-mib-04, indices for the
> rbridgeUniFibTable has been defined as combination of rbridgeFibNickname
> and rbridgeFibPort.
>
> In an ECMP scenario, on a Shared LAN link, there can be reachability to
> the Egress Rbridge over two different nexthop Rbridges connected to the
> same rbridge port right?  In this case, there will be more than one entry
> with the same rbridgeFibNickname and rbridgeFibPort but with different
> nexthop Rbridge nickname.
>
> Don't we need to include the nexthop rbridge name also part of the indices
> for this table? Or Am I missing something here?
>
> Regards,
> Mahesh
> _______________________________________________
> rbridge mailing list
> *rbridge at postel.org*
> *http://mailman.postel.org/mailman/listinfo/rbridge*<http://mailman.postel.org/mailman/listinfo/rbridge>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/rbridge/attachments/20111108/4a50c0b3/attachment-0001.html