Re: Multiple aggregated links between devices impossible?

On Nov 6, 6:02 pm, Glen Herrmannsfeldt <g...@xxxxxxxxxxxxxxxx> wrote:

Perhaps you're arguing that many 802.3ad aggregations are permissible
between Cisco devices, but only one 802.3ad aggregation is possible if
the devices are from different vendors?

That the standard only requires one between different vendors.

Is that speculation based on the text I quoted, or is the standard
explicit on this point?

If it's the latter, the the question is settled (I'd appreciate a
citation though). I don't see any indication that Cisco is doing
anything beyond vanilla 802.3ad (they call it LACP, afterall), but
anything is possible. OTOH, why would they bother? They had a
proprietary aggregation mechanism before LACP.

That doesn't make much sense to me.  It seems to suggest that Cisco's
technique for bringing up multiple aggregations is NOT 802.3ad
compliant.  Afterall, if something is standards-complaint, then vendor-
interoperability should be a foregone conclusion.

Given that wording, maybe it should say "802.3ad compliant with
the extension of allowing..."   Vendors often supply extensions
to standards, where the standard specifies the minimum.

So non-compliance (to a degree anyway) *is* what you were getting at.

Thanks for your input.  The discussion is pretty much academic at this
point because Cisco has blessed the configuration, but I still hope to
clear up my misunderstanding.

In general when using an extension to the standard, you should be
sure to document it such that others who follow you will know
what you did.   Someone later might decide to replace one
Cisco device with one from another vendor, not knowing that
an extension is being used.

It's not completely clear to me that I am using something nonstandard,
but the point is well taken, and I appreciate your taking the time to
mention it.

It doesn't guarantee
that not following the standard will result in a system
that won't work.

Well that was a fun sentence!

Thanks again.

/chris
.

Relevant Pages

  • Re: New rc technology (was: Re: 1/2 scale pitts kills two at airshow)
    ... PCM gear doesn't interoperate, for example, and I ... some performing better than our current standard. ... Though Futaba (and probably other vendors as well) do make industrial ... R/C gear too, and some of this uses spread spectrum already. ...
    (rec.models.rc.air)
  • Re: CLRFI
    ... The scenario that you seem to be worrying about, that CLRFI will become a tyranny upon users and vendors alike, can't really happen without community support. ... argument is along the lines of: "But for the standard, ... to the market with new ideas. ... like Lisp just the way it is. ...
    (comp.lang.lisp)
  • Re: Vector themed issue: How to wear sheepskin
    ... features which is common ... APL2 language standard, although they each have a lot of proprietary ... The Scheme standard, IMHO, is created by the vendors almost as an ideal ... As for APL functions that are complementary in nature between two APL ...
    (comp.lang.apl)
  • Re: Vector themed issue: How to wear sheepskin
    ... features which is common ... to most of the modern APLs. ... APL2 language standard, although they each have a lot of proprietary ... The Scheme standard, IMHO, is created by the vendors almost as an ideal ...
    (comp.lang.apl)
  • Re: A petition to J3 apropos FORTRANs future
    ... Michael Metcalf wrote: ... >> At that time the standards committee was dominated by vendors, ... > threatened to take the standard out of the hands of X3J3 and publish it ... With their sudden support, ...
    (comp.lang.fortran)