Hello Madu
Without route reflectors, we have the iBGP split horizon rule which states:
“When a BGP speaker receives an UPDATE message from an internal peer, the receiving BGP speaker shall not re-distribute the routing information contained in that UPDATE message to other internal peers. This is split horizon rule use within AS to prevent loops”
Now this rule was introduced because of the fact that in iBGP sessions, the AS path attribute is not modified when propagating an advertisement to another iBGP peer. This is done for obvious reasons, because an iBGP is in the same AS, so this does not change. This behaviour however has the potential for loops in the propagation of the advertisement that can travel among several iBGP peers and could be sent back to the original node that injected the route into the AS in the first place.
The problem can really be seen if the originator node (correctly) withdraws the BGP advertisement. The node may be fooled by a copy of an advertisement received by another node and re-advertised to the originator that just withdrew it, causing a loop.
Now when we use route reflectors, the split horizon rule is violated, which means the above loop scenario is possible. So another mechanism must be introduced which involves the originator ID. When an iBGP router receives a route with its own originator ID, it will not accept the route, and thus avoid receiving advertisements that it originally sent out that were re-advertised back to the originating node, and thus avoiding creating a loop. (whew, that was a mouthful…) 
I hope this has been helpful!
Laz