sure. how's this. note, the etc section below is in no particular order :-)
enjoy,
for l3
/16 summarize lan/wan boundary on 10..x.y, with your lans /24'd on the x, where x is something useful
summarize your wan links 192.168..y, where y is /30'd as necessary
/24 your dmzs 172.z..y, where z@16-31 could be something useful
for l2
match your l2 vlan tag schema (or your dotq subif's) to l3 subnets on the octet, consistently where possible in the lan.
add matching +1000 if you vlan in the wan, add matching +2000 if you vlan in the dmz
keep matching +3000 for overflow, and 4000-4096 as reserved for special purposes (google for vlan 4095 as the defacto disabled vlan)
etc#0
start at location 10, and block out 240-254 for a rainy day. you'll be glad you did when someday you wish you'd otherwise had 1-9 & 240 upwards as a failsafe whoops reserve.
etc#1
beware rfc1930 if your edges are bgp, and factor in glop addressing if you run any multicast apps.
etc#2
don't mix your user-plane traffic with your control-plane traffic. pick an x that is consistent for loop0 (or me1 or m0/0, you get the idea...) and use that only for device id, ospf rids, bgp dlsw or stun peers, nms device identifier, etc.
etc#3
lock down your oob; use callback and/or a dial-out pool that passes CID
etc#4
put your nms servers as well as all of your network operators in a known dhcp-static topology location (including e.g. vpn for when they're not at their desks i.e. when ssh'ing in for after hours support, or for vendors, whatever). your vty and snmp acls, ip permits, can then be known source'd & dest'd on a simple 255.0.255.0 vs. acl 500 lines deep.
etc#5
this is 2008. if it can't ssh scp and snmpv3, throw it in the bloody trash bin already! :-)
$0.02
good luck!
