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

[Jon Hudson <[e-mail]>]

Just to add to what Donald said...

This is a case where the draft came out of a need that kept appearing while discussing and trying to solve other challenges ( like a/a host based connections).

As apposed to a "draft if search of a problem" this is really a case of a draft providing a building block that by not existing would prevent other solutions from coming forward.

Now as to the terminology. There is much confusion in the market and with customers as to when something is or is not LAG.

One if of the limitations today of host based LAGs is that they have to go to the same physical switch unless the target switch is part if a proprietary MCT pair, and that the MCT group is itself only a pair.

What many customers want (and is provided today by other proprietary solutions) is N active links to N top of rack switches where the initial common two configs would be two links to two TOR switches from one host, or four active links from a host to four different TOR switches.

This maybe a cause of the confusion caused by the document saying N switches. And is part of the value since as you stated most MLAG solutions are only in a pair, and subpar as a result. 

J

On Nov 19, 2012, at 8:58 PM, Donald Eastlake <[e-mail]> wrote:

> 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
> _______________________________________________
> trill mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/trill