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

[Donald Eastlake <[e-mail]>]

Hi Thomas,

Let me describe what I think it going on.

On Mon, Nov 19, 2012 at 5:08 PM, Thomas Narten <[e-mail]> wrote:
> Hi.
>
> I've got a fairly basic question about this document.
>
> What exact customer/deployment scenario is it trying to address?

Scenarios in which customer wants active-active end station connectivity.

TRILL can provide ECMP and multi-pathing and rapid fail-over in the
links between RBridges. This draft is aimed at specifying a building
block (the Affinity sub-TLV) and giving an example of use of that
building block towards getting the same capabilities for end station
connectivity to the campus..

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

There are various references in various TRILL documents that agree
with you that the classic two end-point LAG appears to TRILL as a
single link with a single port at each end. This draft gives, as
examples of the use of the Affinity sub-TLV, multi-port servers which
do not forward frames between those ports, and what is usually called
multi-chassis LAG (MC-LAG) where you have one device (such as a
bridge) on one end and multiple devices on the other end that conspire
to act like one device. (MC-LAG is commonly supported but using
proprietary methods. There is a project in IEEE 802.1, 802.1AX-REV,
that is seeking to extend LAG to allow more than one device on each
side.)

draft-hu-trill-pseudonode-nickname is an example of another use of the
Affinity sub-TLV not related to LAG. If I recall correctly, at the
Atlanta meeting I repeatedly paired the trill-pseudonode-nickname
draft with the trill-cmt draft and suggested people consider them
together.

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

I'm not sure the number of RBridges in the edge group matters so much
or that you know about all MC-LAG implementations. In any case, a
multi-port server could have more than two ports.

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

I think so -- that is, you correctly understood that in this draft it
actually means MC-LAG.

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

The draft is intended to specify the Affinity sub-TLV and to provide
an example where an edge group of RBridges cannot see each other's
Hellos. For the sub-part of the example using MC-LAG, rather than a
multi-port server, I would say the MC-LAG is doing exactly what the
purpose of MC-LAG is.

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

> Thomas