Re: [DNA] Ideas for ethernet section of draft-ietf-dna-link-information

[Greg Daley <greg.daley@eng.monash.edu.au>]

Hi Alper,

Alper Yegin wrote:
> Greg,
> 
> Going back to your 802.3 text....
> 
> Reading your text, my understanding is:
> 
> - The host MUST learn if the adjacent port is running STP or RSTP.
> - The additional delay is 0 if STP/RSTP is not detected. Delay is
> learned from the RSTP/STP signaling when present.

I guess that if the delay is 0 there's still a likelihood
that the event is wrong (it degrades the hint).
Since a lot of ports may default to a proprietary 'port fast'
environment like Cisco's it may be OK in many cases.

Since you don't know which port you're connected to, you can't know
at zero time whether or not the port is up for data forwarding.

If you were to get a subsequent hint:

"forwarding available at time+t (by the way, the last hint was broken)",
then there may actually be a case for retransmission (for DNA),
but damage could have already been done to upper-layer flows which
may need retransmission of data (the same issue exists when DNA
has not yet completed).

I'd guess that this is OK (re-hinting), so long as there's
information in the draft illustrating the issue.

> - The link up MUST be generated "delay" seconds after
> PMA_LINK.indicate(OK).

I don't think this is possible, unless there's an
immediate signal at zero time (which may constitute a
degraded indication),

> - The link down MUST be generated immediately after
> PMA_LINK.indicate(FAIL).

Immediately after fail sounds good.

> Is that right?
> 
> You text uses "may"s. If you agree, we shall update it with the "MUST"s
> as above.

There are some serious issues since there's no beacon for ethernet
before you connect to identify the peer.

I'll cogitate on this for a little while.
Comments welcome.

Greg