1) Why do you need to remove synchronization? First ask, "what is synchronization?"
Imagine the following network topology: You are an Internet service provider. RouterA is your upstream Internet provider, and RouterB is your border with them. RouterD is a multihomed customer of yours, and RouterC is your border with them. You own RouterB, RouterC, and everything inbetween. There are several routers and switches and such between RouterB and RouterC that do not run BGP, but they run an IGP.
RouterA <-> RouterB <--- large internal network/IGP ---> RouterC <-> Router D
RouterA and RouterB are directly connected and speak EBGP with each other, and RouterC and RouterD are likewise directly connected and speak EBGP with each other. RouterB and RouterC speak IBGP with each other, and this passes through many IP hops.
Since all routers between your BGP borders aren't running BGP, it is required that you distribute your BGP routes into your IGP, so that all the routers inbetween know how to get to the BGP-routed destinations.
Suppose you have an important network, say 10.150.11.0/24, hosting a very important website, www.example.com. You receive a new announcement from RouterA for 10.150.11.0/24. RouterB receives this and redistributes it into IGP and sends it directly via BGP to RouterC at the same time. RouterC then relays this announcement to your customer, RouterD.
This is where things get ugly. If your network and your IGP are large and complex, the route for 10.150.11.0/24 takes a relatively long time to be distributed across your network. Meanwhile, you have told your customer's router that you can reach www.example.com. The customer may send traffic destined for www.example.com to you. RouterC receives this and passes it along to what it sees as the shortest path to RouterA (or RouterB, depending on whether or not you have set next-hop-self). An internal router in your network five or six hops away from RouterB hasn't learned about the 10.150.11.0/24 prefix yet, has no idea what to do with it, and discards the traffic. This continues until your IGP has fully converged. This is very bad, since your customer may have had a perfectly valid and working path to 10.150.11.0/24 that you said you had a better path for, but in fact are blackholing the traffic.
Synchronization prevents this from happening by stopping RouterC from announcing that prefix to RouterD until RouterC can reach that route via your IGP. In this way you have some measure of confidence that you can actually pass traffic for networks that you announce. If you have BGP running on all the routers between RouterB and RouterC and you are not distributing BGP into IGP, synchronization has no value and must be disabled.
It is important to note that this is a contrived example and a service provider network would never be set up this way in the real world. Synchronization doesn't have much use in modern networks, mostly because distributing full BGP routes into your IGP is considered insane and will melt your network.
To get back to your question, RTB will not consider 203.250.13.0/24 and 203.250.14.0/24 for insertion in its routing table and propogation to its peers because it's waiting for those routes to arrive via OSPF. The same applies for 203.250.15.0/30 on RTA. Until that happens, "synchronization" has not occured. This is a scenario like above, where the network is structured such that you are expected to distribute your BGP routes into your IGP.
2) What difference does the netmask make?
Quoting from the scenario: "Let's also turn off synchronization on RTA in order for it to advertise 203.250.15.0, because it won't sync up with OSPF due to the difference in masks. We'll keep sync off on RTB in order for it to advertise 203.250.13.0 for the same reason."
RTB is configured to announce 203.250.15.0/24, however the only route it has IGP or otherwise is for 203.250.15.0/30. The route in IGP needs to match exactly in order for synchronization to enable that route. In the scenario, instead of making an IGP route for 203.250.15.0/24, they simply disable synchronization.
3) Why don't all routes show all potential paths?
BGP is a distance-vector protocol on which Cisco implements split horizon. Taking the route 200.200.10.0 in RTB for an example - RTB learns the route for 200.200.10.0 from RTD and from RTA. RTA only has one route for 200.200.10.0, via RTC. Why doesn't RTA show RTB as another path for that network? Since RTB has learned of 200.200.10.0 from RTA, it does not tell RTA that it has a route for 200.200.10.0 - this could create a routing loop.
I understand some router vendors (Juniper) do not implement this, as it may not be strictly necessary or desirable for BGP. Search CCO or Google for an explanation of split horizon.
