Allowing contacts of contacts?
Evan from IMBA here. Sorry for replying in a new answer, I don't have the required 50 points of reputation to comment in reply specifically to Lizz Trudeau's answer. I just watched the video Jason (my predecessor) gave at CiviCon 2012, and it gives a really solid overview of how we've tackled this and for the most part we're still set up this way. We've made improvements and enhancements along the way as new features become available in Civi, but the bones of what we're doing are the same. There are loads of things to consider when deciding on a tiered implementation, and a couple of good ideas have been thrown out already. Here's my take on what we've done vs. other solutions presented:


CiviCRM Multi-Site: for us at the time, we didn't have the need or capacity as an organization to support this structure. In our revenue share model, all membership funds are processed and collected by the parent organization and then dispersed quarterly to the chapters. We could certainly set up the payment processors, etc. for each chapter but restricting access to change settings like this would have been an issue. This remains a viable option for us in the future, as our chapters grow in function and capacity. Particularly if we enable a Drupal multi-site structure where IMBA offers chapter website hosting as subdomains of the main site. It's on the table for consideration in 2016.
Relationship Permissions as ACLs has my attention. Our method of using a multi-select custom data field to track multiple contact-to-chapter relationships works pretty well, but can be a little cumbersome and finicky when importing large lists into Civi and a few other tasks. Using relationships as ACLs could be a better way of handling this, but might also trade one set of challenges for another. I think if we were starting from the ground up, this would be a solution we would strongly consider, right now making the change seems rather daunting. We would still need to use custom data fields to track the revenue share component of contributions, to the best of my knowledge.
Using Custom Data Fields to Create Groups and ACLs has worked pretty well for us over the years, has been scalable through multiple Civi updates starting with 3.x all the way to 4.6. We've built some custom code to support it here and there such as increasing efficiency in the back office during data entry, but as Jason said in the video it's largely out of the box functionality. What it doesn't give our chapter admins permission to do is use their own payment processors, access to CiviEvent, etc. There are some pain points but largely it works well. In some ways it's a similar approach to the Relationships, and I think each would have their own challenges and strengths. Co-branding with our chapters is super important, and using the custom fields allows us to pull that data in searches, reports, and other lists which are then sent to vendors for doing membership fulfillment, renewal messaging, and even some region- or chapter-based variable content in our quarterly print magazine for instance. We're also making some changes to these custom fields to (hopefully) enable us to place custom tokens into email messaging as well.


Challenges we face:


Better signup UI: Right now we still have just one user workflow on the /join page, and I'd like to revamp this so we send renewing members directly to a contribution page for their specific chapter, rather than sending them through the "join" workflow which requires them to select their local chapter each time. This should be possible using the custom data fields as tokens and contact hashes. We now have over 180 chapters, and having a giant dropdown select is not a good UI solution. We've got some ideas in the works with Fuzion that will address the signup process and provide a better experience for visitors, but still capture revenue share data as needed.
Living with your neighbor's dirty laundry: this remains a bit of an issue with certain features of Civi not easily quarantined via ACLs. That all users can see the entire "From" email address list is one of these things, although minor. A larger one is that our chapters would like us to support Event Registration for their local events, but enabling those users access to CiviEvent grants them access to all other events in the system, not just their own. This may have changed since last I looked, but it has been a sticking point of opening up this feature to our chapters.
Growing our chapter's contact lists: Each "CHAPTER All" ACL group is a smart group based on that chapter's name being in the multi-select custom field. Each chapter's territory is defined by postal code. When a chapter is integrated, we import their list of contacts and also search out any existing contacts in their zip code territory, and add this chapter to that custom field for all these contacts. So the only time we place existing contacts in a chapter's partition (share back contacts from the main IMBA DB) is when the chapter is integrated. As new contacts come to the main IMBA database, they're not being actively shared back the appropriate chapter's partition. This was a conscience decision made years ago, but one that has recently changed. We have an extension that updates a contact's region based on zip code, it will be more challenging to update the chapter affiliation of a contact as each contact can be visible to multiple chapters. (NOTE: a contact can be associated with a chapter outside of their zip code by opting in, attending a fundraiser and signing up for email newsletters is an example of this)
Accommodating members who wish to join multiple chapters: Pretty self-explanatory here. Some of our members want to belong to more than one chapter. Summer home, favorite vacation spots, etc. Our preference would be to NOT implement 180+ membership types, so we're still brainstorming ideas for a solution. And the reality is, right now this challenge lies in sorting out the business rules and requirements, not in database or CRM limitations. 


That's just an overview from our perspective, I'm sure I could ramble on and on about everything we've done that's worked and hasn't but I really should get back to testing some new functionality. Feel free to ping me with questions, I hope I helped.