RE: Hari and train-up sequences
So, the auto-negotiation that you're proposing would be to train the Hari
interface and exchange link configuration information (such as pause
capabilities). This would be comparable to 802.3z use of the
synchronization state machine (in Clause 36) to train the receive PMA
service interface while exchanging link configuration information via
auto-negotiation (in Clause 37). The concern that I have is that each
direction of the Hari interface (transmit and receive) needs to be trained,
which is different than what is done in 802.3z which only trains the receive
PMA service interface.
To me, the training of the Hari interface sounds like it will be a
requirement of that interface. I do wonder why we need the auto-negotiation
to exchange link configuration information. The only thing that I can
foresee that a local device would have to negotiate with a link partner is
the pause capabilities, and even those could be subject to debate. So, if
auto-negotiation is not required, then the only requirement is to train the
Hari interface. The use of a management interface connection into the PMD
device (as per Howard Frazier's proposal) would assist in determining the
Hari interface's training status.
Don't get me wrong, I'm not violently opposed to auto-negotiation. I wish
only for someone to present to the HSSG what auto-negotiation offers and the
benefits of adding it to our standards work. It's not one of our
objectives, so I'd like to know why we should spend time on it.
Thanks,
Brad