"The main issue is that cisco considers PC and PC traffic (by definition) something that network equipment can not control and can not trust then, on "best" Cisco Qos practices, QOS trust boundary should ends on the phone."
Oh, can you provide a reference to that information?
Usually, a trust boundary is at a demarcation where there's a change in administrative control. As edge ports, especially user end jacks, are not under my control, I consider that a trust boundary. Doesn't matter whether there's a VoIP phone or not. Again, especially on user edge ports, every one has a VoIP phone? No PCs are using a software VoIP phone? What precludes someone from connecting a different device to the wall plate jack? I don't recall VoIP phone usually controlling CoS/ToS to/from an end host, in fact, PCs are usually on a non-tagged VLAN, as might a VoIP phone (another reason L2 CoS is "iffy"). (BTW, yes, there are edge access control technologies, but I'm assuming cases where we don't have such.)
So, typically, a user edge port should be a trust boundary. (Also, connection to another AS network device, should also be a trust boundary.)
"A better solution (but maybe unfeasible) will be try to work w directory control policies to enforce QoS on PC/ server generated traffic and allow the network to follow QoS marked traffic for queuing and prioritization."
Certainly a possible and worthwhile approach, but I wouldn't depend on that alone. (Personally I'm paranoid. So "trust but verify" is always a good approach, as it catches "accidents" too.)
"Then, their best practices is not to trust whatever is connected to PC sends and rewrite traffic."
Again, trust but verify, I believe is a better approach. Whatever you receive from an edge port could be totally valid, and doesn't need to be remarked (actually from a different AS, marking might be totally valid but need to be remarked because you use different markings for same purposes), but even if that's the case, we now know it's valid markings on our side of the trust boundary. (Again, for simplicity, I've used critical markings, like DSCP EF, without validation, but controlled in such a way, it doesn't matter to my QoS goals.)
"On Switches if you trust DSCP (Layer 3 trust), then all traffic that comes from PC is trusted (Cisco solution does n want that) and if you trust Cos (layer 2 trust), all traffic send by PC that traverse phone gets remarked to zero and phone traffic gets unchanged."
Again, any Cisco references? (As that's not my understanding of Cisco recommendations, nor how Cisco devices' QoS work, by default. [NB: Cisco default QoS handling does vary, between their switches and routers, and with switches, between old and new - if you're unware of this, I can described their basic differences and also why I think they chose the defaults they did.])
"That's the reason they recommend using conditional L2 trusting."
Again, reference please. Possible you have in mind implicit trust of Cisco VoIP phones using CDP to place themselves on a voice VLAN. (Even that approach, I would not endorse an implicit trust, although it's convenient. Of course, I don't generally endorse Auto-QoS, which is also convenient.)
"The other solutions that Cisco suggest is to access list on the edge but, anyone that had manage a network, realized how complex this is,"
Well actually, my last job, before I retired, was in an environment of 5,000 Enterprise devices, with 100,000 plus users (my responsibility was about 1/10 of that), so yea, somewhat acquainted with interface configurations, but complexity wasn't the issue, just number of interfaces to configure. For edge QoS, often we had both ingress and egress policies, so mass QoS changes was a bit of a hassle (at that time, this was before some of the modern configuration packages [so we also wrote our own scripts for mass changes - new deployments not much of a problem - you learn to love the range option].)
BTW, when it comes to QoS, I'm a legend in my own mind (laugh). Consider me a QoS god (small case), or maybe a QoS demigod (laugh.) Seriously, though, for what was at the time, the 4th largest software development firm in the world, I spend about half my time, over 10 years, working on QoS. It's amazing how much it can contribute to a well working network, but unfortunately, 99% of "book" QoS recommendations will not get you a well working network. About the only thing basic "book" QoS does well is handle RT traffic like VoIP or video conferencing (since they dump such traffic into PQ or LLQ [but much often isn't said about what else should be considered for that traffic]).
If you're interested in QoS working well, let me know, and what your QoS goals are. Very possibly, I can help you have effective QoS beyond what you "read" in most QoS books. (BTW, I've also read many books and articles on QoS, started with them, in fact, and spend a good bit of time working out why they didn't work well in a real international network, and what to do instead.)
