Deploy the roles without changing their meaning

Reflection is a control-plane distribution design, not authentication or automatic configuration.

• BGP provides no way for a router to identify itself dynamically as a client of a reflector. Client roles are configured; a conventional BGP speaker can be a client. The diagram labels configuration, not a new client flag in a BGP packet (§§6,11).
• In one simple multi-cluster design, RRs treat one another as non-clients and maintain a full mesh among those RRs, while clients peer with their cluster’s RR. That is one topology, not a requirement that every possible RR hierarchy use the same roles. Additional RRs can remove the single-reflector failure point when correctly connected (§§6–7,11).
• When reflecting, an RR SHOULD NOT modify NEXT_HOP, AS_PATH, LOCAL_PREF or MED. These are path attributes for the next hop, AS history, internal preference and Multi-Exit Discriminator. The selected model preserves them while adding or preserving the reflection attributes (§10). NEXT_HOP is not automatically changed to the RR.
• MED comparisons and differing IGP costs can yield selections different from a full mesh. The reflection topology should be considered together with the network topology, and some deployments keep extra client sessions for path quality. The original publication describes configuration approaches, not a universally optimal topology or a guarantee that fewer sessions means identical choices (§11).
• RFC4456 does not change BGP’s underlying security issues. ORIGINATOR_ID and CLUSTER_LIST detect reflection loops; they are not signatures, encryption or proof that a route is authorized. This educational guide sends no real BGP traffic and changes no network configuration (§12).
• Official status is Draft Standard, April2006. It obsoletes1966 and2796, has no formal Updates targets or obsoleted-by entry, and is updated by7606. These are publication relationships, not versions of BGP or a claim that7606 replaces all reflection semantics.