Hi co-authors of the draft, I have read your draft (http://tools.ietf.org/id/draft-bonica-l3vpn-orf-covering-prefixes-00.txt) and feel the CP-ORF described in the draft may be applicable in Virtual Subnet (http://tools.ietf.org/html/draft-xu-l3vpn-virtual-subnet-01), a special BGP/MPLS IP VPN [RFC4364] application environment as well, to realize the on-demand RIB installation (a.k.a., on-demand host route pull) purpose (see section 3.6.3. PE Router RIB Reduction at http://tools.ietf.org/html/draft-xu-l3vpn-virtual-subnet-01#page-12).
However, to use the CP-ORF in the Virtual Subnet environment, there is a practical issue which needs to be considered. To illustrate the issue clearly, I would use the Figure 6: RIB Reduction Example described in the Virtual Subnet draft as an example. Since the V-spokes (i.e., PE-1 and PE-2 in Figure 6) have already installed a directly connected route (i.e., 1.1.1.0/24), the VPN IP default route which is expected to be originated by the V-hub (i.e., the RR in Figure 6) would not be applicable anymore. For example, when PE-1 receives a packet destined for CE host B (i.e., 1.1.1.3) from its local CE host (e.g., host A), PE-1 would not be able to forward that packet to the RR (i.e., the V-hub) since the longest match route for that packet is 1.1.1.0/24, rather than the default route. Therefore, it would be desirable to allow the V-hub to advertise two more specific routes (e.g., 1.1.1.0/25 and 1.1.1.128/25) rather than a default route in this case. Of course, this behavior may conflict with the original concept of the Virtual Hub-and-Spoke VPN [I-D.ietf-l3vpn-virtual-hub] where the V-hub is required to originate a VPN IP default route. I wonder whether it would be better to relax that constrain, e.g., the V-hub is only required to originate a default route or one or more generic routes which cover the more specific routes to be suppressed. In this way, the case where V-spokes has default routes (see Figure 2 to 4 in the Virtual Subnet draft) can be easily addressed without using the complex tricks described in Section 5 of Virtual Hub-and-Spoke VPN draft (see http://tools.ietf.org/html/draft-ietf-l3vpn-virtual-hub-08#page-10). In other word, the default route could be originated by the V-spokes as normal and that route would be installed by all the other V-spokes and even the V-hub. In this way, the inter-subnet traffic which uses the default route would be forwarded along the optimal path. To achieve the above goal, the following rule stated in the CP-ORF draft as " the route is more specific than a /64 (i.e., the route more specific than an IP VPN default route) should be replace with "the prefix length of the route is larger than or equal to the value of "Min-Prefix-Length" field in the CP-ORF". In other word, a "Min-Prefix-Length" field should be added to the existing CP-ORF Type-specific Encoding. Best regards, Xiaohu
