Re: [trill] draft-ietf-trill-cmt

[Thomas Narten <[e-mail]>]

Hi.

I've got a fairly basic question about this document.

What exact customer/deployment scenario is it trying to address?

It says:

>    This document specifies a concept of Affinity sub-TLV to solve
>    associated RPF issues at the active-active edge. Specific methods in
>    this document for making use of the Affinity sub-TLV are applicable
>    where multiple RBridges are connected to an edge device through link
>    aggregation or to a multiport server or some similar arrangement
>    where the RBridges cannot see each other's Hellos.

I view Link Aggregation Groups (LAGs) as an L2 construct that would be
hidden from TRILL. I.e., in Ethernet, LAG is used to "hide" the
presence of multiple links between a pair of switches from STP, so STP
only sees one link (the LAG) rather than the individual links. Thus, I
would expect RBs to want to only know of a single link (i.e., the LAG)
and not have any understanding that the link may actually be a LAG.

Moreover, Figure 1 is not describing LAG, but multi-chassis LAG
(MLAG). MLAG is not standardized (all implementations are proprietary
and there is no interoperability between vendors). Moreover, MLAG
implementations are pretty restricted -- last I checked, MLAG products
were limited to only 2 switches. So the figure in the document showing
MLAG involving an arbitrary number of "N" switches seems a stretch.

Do I have the right understanding of what is meant by "LAG" in the
draft?

The idea that RBs would be aware of individual links within a LAG
kind of defeats the purpose of having LAGs. Is that really what is
being proposed?

Thomas