Place reflection tie-breakers in order

A shorter cluster history does not outrank every other path attribute.

• Base BGP has an ordered decision process. The guide’s two-candidate examples assume the earlier relevant conditions have been resolved as stated. A higher LOCAL_PREF example is settled before router-identifier or cluster-length comparisons; a shorter list cannot reverse that decision (RFC4271 §§5.1.5,9.1.2.2; RFC4456 §9).
• At the BGP-Identifier tie-breaking step, if a route has ORIGINATOR_ID, that value SHOULD be treated as the advertising speaker’s BGP Identifier. Without it, the advertising speaker’s own identifier is used. In the chosen tied example, originator .10 beats .20 even when their reflectors have identifiers .200 and .1 respectively (§9).
• After that identifier comparison and before the lowest-peer-address tie-breaker, a speaker SHOULD prefer the shorter CLUSTER_LIST. A route with no CLUSTER_LIST has length zero for this comparison. This is a late tie-breaker, not a universal shortest-reflection-path metric (§9). A missing attribute is not a received zero-length encoded attribute.
• An RR reflects its own best path, which need not be the path each client would select if it saw all alternatives. With other earlier conditions tied, chosen internal costs5 versus20 can make the RR select pathA, while a client’s costs30 versus2 would favor pathB. If onlyA is reflected, the client cannot compare the hiddenB route. These are chosen Interior Gateway Protocol (IGP) costs, not measured latencies (§11; RFC4271 §9.1.2.2e).
• The teaching helper implements only the late identifier/list-length/IPv4-peer-address comparison under an explicit earlier-tied assumption. It is not the whole BGP decision process, does not compare MEDs from arbitrary ASes and does not claim that an RR deployment always reproduces the full-mesh result (§11).