Portfast trunk, as its name implies, enable portfast on trunks. We had to introduce the "trunk" keyword because portfast would only be effective on access ports (i.e. non-trunks) and there are some cases where you want portfast on trunks (on a trunk that connects to a router for instance).
Portfast is to be configured on edge ports (that's the IEEE terminology btw). An edge port basically leads to hosts that operate above layer 2 (routers, servers, etc...). Because an edge port cannot introduce a bridging loop in the network, there is no need to wait before putting the port to forwarding. Configuring portfast on your trunk will just simply put it to designated forwarding as soon as it comes up. The feature in fact only has an effect at link up. Well, there is a secondary side effect of portfast: a portfast port does not generates TC.
Since MST and RSTP, portfast has now an operational and a configured value. Basically, as soon as a port receives a BPDU, it loses its portfast status because it is obvioulsy connected to a bridge. That's probably why you are saying that the show commands display portfast as disabled: it is configured, but operationally disabled.
This will not prevent the port from going to forwarding. Portfast does not disable STP, it's just again modifying the behavior at link up.
In theory, if there is no redundancy in the network (ie no physical loop), you could enable portfast everywhere. Actually, you could completely disable STP;-)
However, in your lord of the ring scenario, it is not appropriate and you could end up with transient bridging loops. I guess that the engineer who configured this on the trunk was desperately trying to speed up the convergence of the ring.
Regards,
Francois
