[c-nsp] data MDT ACL mapping

[Jeff Bacon]

So there's these enhancements that allow you to "deterministically map MVPN groups to specific MDT groups". 

I gather the following, from playing with it:

- you still only get one "mdt data <net> <mask>", only now you get to say "list <acl>"
- otherwise it falls through to the default
- to the extent it's possible, you get a sequential-match, e.g. 

ip access-list standard my-groups
   permit 233.254.99.128 0.0.0.63
ip vrf BLAH
  mdt default 233.1.1.1 
  mdt data 233.88.88.64 0.0.0.63
you get 233.254.99.129 -> 233.88.88.65
        233.254.99.134 -> 233.88.88.70
        ad nauseum

Are there other feasible incantations? 

The reason I ask is because, well, I use a deterministic method for allocating the MDT groups, so I know that VRF BLAH -> default 225.1.1.A data 225.1.A.<x-y>, and a lot of the input groups are x.y.z.<0-255>, so it'd be damn handy in debug-panic to not have to continually do a "sho ip pim vrf BLAH mdt <err am I sending or receiving on this switch anyway?> <err so which group in this list is what?>"... 

Is there any really good reason to run a bunch of MDT data groups besides to allow breaking down the groups in the MVPN so as to allow multicast/SSM in global space to optimize what gets sent where? 

Is there a downside to letting MVPN "splay" all the groups out, other than possibly running out of TCAM at some N aggregate number of groups, noting that each MVPN group really takes up two slots in MFIB/<whatever-it's-called-on-non-sup2t>?  (Well, that and having "show ip mroute" scroll for a really long time, I suppose.) 

(I figure I'm running around 400 "real" groups input into the mesh at various points, ranging from 10pps to 50kpps per group. 6500s all, though ME3600s will probably enter the picture.)