Re: [trill] Multidestination frames over parallel P2P links

[Donald Eastlake <[e-mail]>]

Hi Petr,

Sorry for my delay in responding. I was traveling.

On Wed, Oct 28, 2015 at 5:13 PM, Petr Hroudný <[e-mail]> wrote:
> Hi all,
>
> I'm looking for the WG opinion about forwarding of multidestination frames
> over parallel P2P links between TRILL switches.
>
> According to RFC6325, section 4.5.2, item 3 a), when multiple parallel P2P
> links exist between RB1 and RB2:
>
> "Most preferred are those established by P2P Hellos.Tiebreaking among those
> is based on preferring the one with the numerically highest Extended Circuit
> ID as associated with the adjacency by the RBridge with the highest System
> ID."

Of course, as stated in RFC 6325, the above only applies to
multi-destination TRILL Data frames. Known unicast TRILL Data frames
can be allocated among the parallel links however the implementation
wants.

> Does it mean that link cost should be completely ignored during the above
> tiebreaking?

The TRILL specification is primarily focused on correct operation, not
necessarily optimal performance when there is a peculiar
configuration. Parallel links would most commonly be of equal
bandwidth. If there is a truly extreme difference in bandwidth, say
100 to 1 or more, you might be probably better of to just treat the
comparatively very slow links as if they were down. Just how extreme
the difference would have to be is an implementation choice. But TRILL
will act "correctly", even if it might be slowly, in delivering data
even if you use all of set of links of extremely different speed.

I think a common thing to do would be to use 802.1AX Link aggregation
to aggregate these links so they will then appear to TRILL as a single
link. IEEE Std 802.1AX-2008 required that all the links be of equal
bandwidth. In IEEE Std 802.1AX-2014, that restriction is removed and
802.1AX says "Aggregation of links of different data rates is not
prohibited nor required by this standard. Determining how to
distribute traffic across links of different data rates is beyond the
scope of this standard." So you have the same thing there. Should you
aggregate a 10Gbps link with a 10Mbps link? I would say that if you
do, you should consider allocating 100% of the traffic to the faster
link (until it fails).

Another thing you could do in a TRILL implementation is allocate
Extended Circuit IDs so that higher bandwidth links had high IDs. This
would cause the faster link to be selected for multi-destination data.

> Suppose the following setup:
>
> link #1    cost: 1000      Extended Circuit ID: 11
> link #2    cost: 1000      Extended Circuit ID: 12
> link #3    cost: 10000    Extended Circuit ID: 13
> link #4    cost: 2^24-1   Extended Circuit ID: 14
>
> Should the switch really prefer link #4 because of the highest Extended
> Circuit ID, regardless of the fact that the link cost was set to maximum in
> order to take the link out of service?

Link cost 2^24-1 is special and such a link is only used for data
allocated to that link by traffic engineering. So you can forget about
link #4 with that cost, but it could be 2^24-2.

Note that Extended Circuit IDs are not symmetric and you have a
different ID in each direction, which is why RFC 6325 says to use the
ID from the end where the TRILL switch has the highest System ID.

Anyway, assuming link #4 was 2^24-2, the TRILL standard says to use it
for multi-destination traffic, but I think a good implementation would
just be ignoring that link.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   [phone] (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [e-mail]

>     Thanks, Petr
>