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

From: Thomas Narten <[email-masked]>
Date: Fri, 14 Dec 2012 10:15:13 -0500

Getting back to this thread, since it popped up in  the active-active
thread...

Jon Hudson <[email-masked]> writes:

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

I like building blocks, but I do not like building blocks being
defined outside of a clearly scoped and understood problem. I've seen
too many so-called "building blocks" defined too early, without a
clear understanding of what the real problem being solved is (i.e.,
what the customer *really* wants, and what the *real* constraints are,
and what the *deployment* configuration will be, etc.).

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

Right. And what does this have to do with TRILL? :-) Seriously, we
need to separate out what part of the problem is a really a more
generic 802.1 problem vs. one that is really a TRILL problem to
solve. I don't have a good understanding of that in this case, based
on what is written in the document.

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

Seems to me that if the figure shows uplinks from one switch to N
upstream switches, and that is not what MLAG actually does in practice
today, then the figure is not showing a realistic
problem/configuration.

Thomas

---

From: Thomas Narten <[email-masked]>
Date: Fri, 14 Dec 2012 10:17:26 -0500

+1 to what Pat said.

Thomas

"Pat Thaler" <[email-masked]> writes:

> Jon and Donald

> I'm skeptical about a "building block" to use in future solutions in general and especially for link aggregation or teaming. It's a fairly difficult to generically make a group of bridges pretend to be a single bridge and one should start with an architecture for solution, IMO, rather than starting with pieces that you hope to pull into a future solution. 

> "A typical deployment scenario, depicted in Figure
>    1, which may have either End Stations and/or Legacy bridges attached
>    to the RBridges.  These Legacy devices typically are multi-homed to
>    several RBridges and treat all of the uplinks as a single Link
>    Aggregation (LAG) bundle [802.1AX]."
> End stations support many forms of teaming so they don't "typically" use any one  form. For instance, one is a bridge-independent form of active-active teaming where the end station load balances traffic to various links with different MAC addresses on each link. They generally can't treat links to separate bridges as a single 802.1AX LAG unless the bridges cooperate to support a proprietary multi-chassis LAG. 

> LAG is defined by 802.1AX and that term shouldn't be used for other mechanisms for using multiple links. It's better to use something else like "teaming" when one wants to include both 802.1AX and non-802.1AX mechanisms. The groupings identified as LAGs in Figure 1 will not be LAGs unless the bridges are presenting them as a single bridge to the end stations which isn't trivial to get right and is currently proprietary.

> DRNI (dual resilient network interconnect) - the capability being added in the 802.1AX-Rev project has a focused objective of defining a mechanism for using a LAG between two provider networks (that's why it's called a "network interconnect") where the links end in more than one bridge (probably two or three bridges) on each side of the aggregation.  End node attachment to a multi-bridge LAG host isn't an objective.

> Pat

> -----Original Message-----
> From: Jon Hudson [mailto:[email-masked]] 
> Sent: Monday, November 19, 2012 10:24 PM
> To: Donald Eastlake
> Cc: Thomas Narten; Tissa Senevirathne (tsenevir); [email-masked]
> Subject: Re: [trill] draft-ietf-trill-cmt

> 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 <[email-masked]> wrote:

> > Hi Thomas,
> > 
> > Let me describe what I think it going on.
> > 
> > On Mon, Nov 19, 2012 at 5:08 PM, Thomas Narten <[email-masked]> 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   +1-508-333-2270 (cell)
> > 155 Beaver Street, Milford, MA 01757 USA
> > [email-masked]
> > 
> >> Thomas
> > _______________________________________________
> > trill mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/trill

> _______________________________________________
> trill mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/trill