Hi Seth,
I don't know if I'm tackling your point but if you are asking why the loopback addresses aren't used in the "neighbor" commands all the time, consider these facts.
In iBGP, inside an autonomous system, the BGP speakers are not expected all to be directly connected. Thus, you can configure an iBGP neighbor by specifying any of his existing IP addresses that is reachable. However, when you - as a router - decide which interface will your BGP packet go out to reach that neighbor, that interface will be put into the packet's source IP address field. Now consider the fact that your interfaces may go up or down or the routing protocol information may change so during an iBGP session, it may happen that you start sending your BGP packets to a particular peer from another outgoing interface than you originally used to establish the BGP session. This would create peering problems, as the peering is bound to IP addresses of the neighbors, and if they change, the peering session will have to be reestablished from the scratch. The loopbacks here are helping you here to maintain a stable pair of communicating IP addresses that do not depend on the state of actual physical interfaces or existing routes through an internetwork. Of course, the loopbacks must be reachable, i.e., the path to them must actually exist.
However, the BGP cannot know if you actually wish to peer your iBGP neighbor with a loopback address or just with the address of your physical interface that is used to reach that neighbor. Your network topology may be so simple that you have only one interface that goes towards your iBGP neighbor so in that case, requiring you to configure and advertise a loopback would simply be a formal and useless burden.
Moreover, for eBGP peers between two different autonomous systems, the Cisco implementation requires that the peers are directly connected, otherwise the peering won't come up. Note that even if two directly connected eBGP peers mutually knew their loopback addresses, these loopbacks are not on common network segment (they're not "directly connected" one to the other) and the eBGP peering would not be created.
So all this reasoning brings us to the idea that you should be able to use a loopback address as your IP source address when talking to a peer if you so wish but you absolutely should not be forced to use it. This freedom of choice necessarily brings the special "neighbor update-source" command.
Note that the "neighbor update-source" has a profound impact on the NEXT_HOP BGP attribute, as it will be the very content of the NEXT_HOP when a network is introduced into BGP or advertised from another AS. So it's not just playing with source and destination in IP packet header that carries the BGP session, it is also influencing the NEXT_HOP attribute value.
Best regards,
Peter
