| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
I’m starting this as a new thread so people can keep it clear on the discussion. Regarding the objectives, I think at least Arvind and I agree that we need some clarification. Support interoperability with Clause 147 & 188 multidrop PHYs: I think that in light of the 802.3 definition of PHY, rather than the “chip” definition of PHY (which can be different for any implementer) “Support interoperability with Clause 147
& 188 multidrop PHYs” is OK. PHY means the PCS & PMA in IEEE Std 802.3, and that’s the audience – the working group. However, in the other basic objectives, we have some work to do: Preserve PLCA method: I agree we need something better than “Preserve PLCA method” Objectives need to be clear as to what we mean. There are a variety of meanings I could take from this. Less is more
in objectives – we don’t want to write how the spec will come out, but looking at what you have, I think we mean:
I suspect that we agree that this means something like your Backward compatible with PLCA; but EPLCA latency predictability will not be guaranteed… because interoperability doesn’t
mean the benefits of the enhanced technique are maintained. Most understand that performance goes to the lowest level… DPLCA: I think we need to discuss D-PLCA. I would suggest:
Given that D-PLCA can have a set of statically assigned ID’s we ought to be able to set up a working performance regime which doesn’t completely fail when E-PLCA is enabled on some nodes and D-PLCA
nodes are on the mixing segment. Whether we can come up with a way to preserve E-PLCA benefits with D-PLCA active is an item for work. Not sure we need to decide that now, but we shouldn’t have the network crash if you have both, and an objective to “Preserve
interoperability” does that. Specify PLCA selection service client to be used by upper layer: I think we need a little wordsmithing here. I believe we specify a client interface (primitives) to communicate priorities. This way implementers, and specifications
like 802.1 can control the mechanisms of PLCA to do this. We haven’t defined what the client actually is, and the innards are probably out of scope for IEEE Std 802.3. We also can’t define who uses it – that is above the scope of 802.3 (we can give them
the tools, but we can’t make them use them). Hence, I’d suggest we focus on the interfaces to parts that are actually in 802.3:
When we know more about the PLCA priority service client we might be able to say more here. It might be best to wait a little on this objective. -george To unsubscribe from the STDS-802-3-EPLCA list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-EPLCA&A=1 |