RE: [EFM-Copper] discovery and adding pairs...
Matt,
I wrote the response to #302. It was not my intent to say that adding a
pair was not possible. I guess we need to clarify things a bit more.
On the new loop, one can read the remote_discovery_register, and
determine which, if any, group it is bound to. The
remote_discovery_register contains the value that was written to it when
the first loop was brought up. There should be no reason to access the
register through loops that are already operational.
Perhaps I'm missing something else, but I think it's OK.
--Barry
-----Original Message-----
From: Matt Squire [mailto:MSquire@HatterasNetworks.com]
Sent: Monday, November 10, 2003 7:24 AM
To: peter.schelbert@schmid-telecom.ch; jrt@lucent.com;
stds-802-3-efm-copper@ieee.org
Cc: O'Mahony, Barry; hbarrass@cisco.com; michael.beck@alcatel.be
Subject: Re: [EFM-Copper] discovery and adding pairs...
I want to offer a little bit more clarification on my concern.
There are two different problems people are talking about. First is
what I call the discovery problem where when a loop/pmd comes up, the
system must determine the MAC to which that loop should be bound. The
second is the add/delete of a loop/pmd to an aggregate. In this
problem, the discovery is already complete
There is no problem (I think) with the second one. Pairs can be
added/deleted from an aggregate dynamically as long as one knows the
aggregate to which they belong (by manual config or something else).
The problem lies in the discovery phase. If used, it kills the ability
to add/delete dynamically because it requires the system to read/write
to every pmd using G994.q handhaking.
In my opinion this makes the discovery process unusable.
I just wanted to get that clarification out there before the concern
gets misinterpreted.
Thanks.
- Matt
-----Original Message-----
From: Schelbert, Peter <peter.schelbert@schmid-telecom.ch>
To: 'Towne, Jeffrey R (Jeff)' <jrt@lucent.com>; Matt Squire
<MSquire@HatterasNetworks.com>; stds-802-3-efm-copper@ieee.org
<stds-802-3-efm-copper@ieee.org>
CC: Barry O'Mahony (E-mail) <barry.omahony@intel.com>; Hugh Barrass
(E-mail) <hbarrass@cisco.com>; Michael Beck (E-mail)
<michael.beck@alcatel.be>
Sent: Mon Nov 10 09:16:31 2003
Subject: RE: [EFM-Copper] discovery and adding pairs...
I agree as well
1) If n-pairs (say 4) are configured to build one link, and some of
these
pairs drop (one pair fo example), at least the member-pairs of the link
MUST
be allowed to join without restart.
2) I see no reason why it should not be possible to dynamically add or
drop
pairs from a link. The PAF should be able to handle this easily.
For practical reasons, it is a pain, if a service provider has to cut
the
service to upgrade to a higher speed (adding pairs). This is what we had
with leased lines. We must build now a better solution and at least as
good
as IMA or MLPPP was.
I stongly suggest to add the missing parts.
Best regards
Peter Schelbert
-----Original Message-----
From: Towne, Jeffrey R (Jeff) [mailto:jrt@lucent.com]
Sent: Monday, November 10, 2003 2:46 PM
To: 'Matt Squire'; stds-802-3-efm-copper@ieee.org
Cc: Barry O'Mahony (E-mail); Hugh Barrass (E-mail); Michael Beck
(E-mail)
Subject: RE: [EFM-Copper] discovery and adding pairs...
I agree.
Most "inverse multiplex" schemes can accomodate adding
and/or removing members without restarting the aggregate link. Why
invent a
new one that does not have this capability?
Jeff Towne
-----Original Message-----
From: Matt Squire [mailto:MSquire@hatterasnetworks.com]
Sent: Sunday, November 09, 2003 9:53 PM
To: stds-802-3-efm-copper@ieee.org
Cc: Barry O'Mahony (E-mail); Hugh Barrass (E-mail); Michael Beck
(E-mail)
Subject: [EFM-Copper] discovery and adding pairs...
One of my TR comments against D2.1 (#302) asked for a
clarification about how the discovery process can add loops
to an up and running EFM copper interface (10PASS/2BASE). I
thought I just misunderstood the discovery process because
it did not seem possible to add a loop to 10PASS/2BASE port
that is already operational. The response to the comment is
that I was correct and that its not possible.
Does anyone else find it unacceptable to have to take down
all pairs to "re-discover" which pairs can be included in an
aggregate? IMHO, this is a bizarre and unobtainable
restriction. Pairs, in general, don't come up at the same
time. They can go away and come back. The discovery process
we have in place does not take that into account.
Am I out in left field? Do we think this idea of having all
ports initializing at the same time is at all feasible?
- Matt