| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Please see update in last row to clarify my intentions. Yair -------------- Hi Chad, Please see my response below. Yair From: Chad Jones (cmjones) [mailto:cmjones@xxxxxxxxx]
EXTERNAL EMAIL I thought we buried this when I sent you the email last week. Let me dig it out to remind you:
Yair, yet another beautiful side benefit of splitting 4P from Clause 33 – everything you had in Clause 33 will still be there. Yair: correct.
Link section served us fine there AND allowed your desired application.
Yair: If link section served us fine there, why we need to replace
“channel” with
“link section” in 802.3bt? there are more in that look at all
Geoff comments those marked as REF 204 and those marked TFTD, they are all related and raise questions that I believe we have to know the full and accurate answers before doing such changes.
When we get to 4P PSEs, this problem goes away.
Yair: Not sure. Please see my presentation darshan_14_0517.pdf and start to discuss your statement.
There is zero reason to have a 4P endspan and midspan on the same link SEGMENT as only the midspan link SECTION will be valid (with the midspan required to DC block the endspan from the PD). Yair: What if Type 3 class 4 Endspan and Type 3 class 4 Midspan are connected to the same PD. This is equivalent to Clasue 33 use case? Is this covered in
802.3bt link section definition and other definitions that are used in 802.3bt/ I am not sure. Please see examples in darshan_14_0517.pdf.
The only hole is now the 2P modes of Type 3 PSEs. Yair: Now you see one of the problems.. I agree. See above.
I am fine to leave this caveat in 33 and not carry it forward to 145 (in fact, I’d prefer it cause I view it as a bastardization of the standard that was SOLELY implemented to violate the clear intent of AT to deliver 25.5 and only
25.5W to a PD). Yair: Not clear if this argument is a fact or what? Let’s
discuss it further.
Mind you, this doesn’t stop you from doing exactly what you did with Clause 33 devices with Clause 145 devices. But there is no reason to overly complicate Clause 145 for this. Yair: Not clear what you complicate. I need just one example. I don’t
want to complicate spec as well.
Also, piling on with George’s comment. You can’t put active or powered into the definition of link section. What is it when it’s not powered? What do we probe to detect, CC and class? Yair: It was a suggested, better wording possible. There is already a text in 802.3bt that helps doing that. I on my way to the airport so I will sent this
later. Let me reiterate: THERE IS ZERO REASON TO HAVE A 4P ENDSPAN AND MIDSPAN ON THE SAME LINK SEGMENT. Yair: I fully agree. This is not my intent and I guess I need to clarify better what is the issue.
I will recuse myself as chair during this discussion and fight this text. It does not belong in 145. Yair: I promise to fight TOGETHER with you to get the best result….. The main objective is not to break existing equipment and the usage of existing equipment operating over Type 3 systems over 2-pairs. Chad Jones Tech Lead, Cisco Systems Chair, IEEE P802.3bt 4PPoE Task Force From:
Yair Darshan <YDarshan@xxxxxxxxxxxxx> Hi David, Regarding TFTD file:
1.
I made errors with my response to comment 204:
Error 1: My presentation that addresses the comment is darshan_14_0517.pdf and not darshan_13_0517.pdf
Error 2: In my first response after TFDT FS which says:
“Keep it TFTD. It can’t be REF204. It is bigger text change. I propose different text: Change to " Within Clause 145 and its annexes, the term link section refers to the point-to-point medium connection between two and only two
active Power Interfaces (PIs)."
2.
Comment #194 should not be referenced to comment REF 204 since it involves other issue. My response to this comment: “Does link section contains 4 connector channel behavior as we
used to assume in our P2P Runb analysis?”
Regards
Yair
Darshan Yair Chief R&D Engineer Analog Mixed Signal Group Microsemi Corporation 1 Hanagar St., P.O. Box 7220 Cell: +972-54-4893019
E-mail: <mailto:ydarshan@xxxxxxxxxxxxx>. |