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

[Thomas Narten <[e-mail]>]

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

Jon Hudson <[e-mail]> 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