OptA has lot of config overhad

OptB implmentation does not have label checking, security risk. And no customer
specific QoS etc.

OptC requires full trust, cannot be used for NNI. Also no customer specific QoS
etc.

OptD is closest to what I want, but it makes no attempt to explain how per VRF
QoS/ACL could be done in shared link, just states it should be per vrf. It also
makes no effort to guarantee antispoofing/leaking.

OptAB is like A, but just one BGP session, still overhead with addressing etc

Maybe we could have

ip vrf one
   rd 42:1
   route-target both 42:1
ip vrf two
   rd 42:2
   route-target both 42:2
ip vrf three
   rd 42:3
   route-target both 42:3
   optE 1.2.3.4
   !optE (optionally one or more ASBR)
!
int ten1/0
  encap mpls optE
  ip address 1.2.3.5/31
int ten1/0.2
  vrf definition one
  service-policy output myqos
iint ten1/0.3
  vrf definition two
  ip access-group foo in
!
router bgp 42
  address-family vpnv4
    neighbor 1.2.3.4 peer-group default
    neighbor 1.2.3.4 optE


BGP between ASBR advertised routes from eligible VRFs (eligibility definied
either in VRF definition or by having eligible logical interface)

All routes for one VRF are advertised with same label. This label is programmed
in eligible interfaces as valid incoming label. 

All received routes are ran against import policies of eligible VRFs (not
possible to import to uneligible VRF). When VRF decides to import route, FIB
will get mapping of interface+label, interface is either the physical or
logical if exists for this VRF.



When OptE interace receives labeled packet, it is verified to be single label
deep and label it verified to be valid for this interface.
Valid label is popped and directed to either physical or logical interface,
depending on labels values. ACL/QoS/PBR/accounting/netflow etc will be
processed normally and lookup performed and packet forwarded.



When VRF lookup has egress interface of optE encap (either logical for this
VRF, or just shared physical) any ACL, QoS, PBR, accounting, netflow, etc is
ran for the packet, the label is imposed and packet forwarded.



What slightly unexpected that can follow is, packets always arrives single
label -> single VRF. However if you imported route to multiple VRF, you may
egress traffic with single label via multiple logical interfaces (i.e.
different egress qos, acl etc policies) while they'd still be received by
far-end by single logical interface. (Usually you wouldn't do this, and only
import to single VRF, but there is no reason to have efforts to stop this for
occuring)


Interfaces would be implicitly unnumbered to the explicitly defined OptX
interface. If there is demand to have multiple OptX NNI in same router physical
port (e.g. multiplexed by downstream switch) this can be supported, by having
two or more explicit defined numbered optX interface with vlan tagging. Then
customer interfaces need to have explicit statement to bind them to given
numbered optX interface.
But direct router-router NNI is preferred, instead of via switch.