Hi Ron, I have reviewed the proposed draft. I think it is very well written document. Maybe this is just my own observation, but during digesting it I have struggled to understand why authors have decided to extend ORF rather then update RFC4684. Maybe if the draft will progress a bit of clarification would be nice as in general 4684 is preferred over ORF in VPN context.
But this is sort of minor detail. Much more important is to observe that major advantage of RFC7024 is that by default it works with currently deployed PEs and RRs. This draft however requires upgrade of both spoke PEs as well as RRs serving such spoke PEs. Such upgrade may or may not be always feasible. It appears however that there is possibility of addressing the problem with alternative approach fully controlled by the V-hub. Such V-hub alone is capable of observing the flow patterns among it's V-spokes and based on the set threshold locally injecting into any VPN optimal route for heavy flows with RT-RED-FROM-HUB extended community. That as such will allow for optimal data flows within given VPN bypassing the V-hub. The question arises how would we remove such more specific routes from V-spokes when the flow terminates ... while there is number of possible solutions in this space - simplest seems to be time driven. V-hub could start timer of x minutes (configurable) after injecting more specific and upon expiration withdraw such more specific routes. At most if the flow still continues customer VPN would experience transient sub-optimality - no drops and no significant impact as V-hub would re-advertise the active more specifics again. The major advantage of such proposal is that it is readily deployable into any of the today's L3VPN network by only activating V-hub which could be a single upgraded PE or new box in the network. Moreover this procedure does not require any protocol extension nor additional features like new RT insertion on the VPNv4/v6 route reflectors which your draft requires. I hope authors of draft-bonica-l3vpn-orf-covering-prefixes will evaluate such alternative. Best regards, R. On Mon, Sep 16, 2013 at 4:33 PM, Ronald Bonica <[email protected]> wrote: > > Please review this draft and provide comments. > > Ron > > >> -----Original Message----- >> From: [email protected] [mailto:[email protected]] >> Sent: Monday, September 16, 2013 10:15 AM >> To: Ronald Bonica; Yakov Rekhter; Huajin Jeng >> Subject: New Version Notification for draft-bonica-l3vpn-orf-covering- >> prefixes-00.txt >> >> >> A new version of I-D, draft-bonica-l3vpn-orf-covering-prefixes-00.txt >> has been successfully submitted by Huajin Jeng and posted to the IETF >> repository. >> >> Filename: draft-bonica-l3vpn-orf-covering-prefixes >> Revision: 00 >> Title: Covering Prefixes Outbound Route Filter for BGP-4 >> Creation date: 2013-09-15 >> Group: Individual Submission >> Number of pages: 10 >> URL: http://www.ietf.org/internet-drafts/draft-bonica- >> l3vpn-orf-covering-prefixes-00.txt >> Status: http://datatracker.ietf.org/doc/draft-bonica-l3vpn- >> orf-covering-prefixes >> Htmlized: http://tools.ietf.org/html/draft-bonica-l3vpn-orf- >> covering-prefixes-00 >> >> >> Abstract: >> This document defines a new ORF-type, called the "Covering Prefixes >> ORF (CP-ORF)". The CP-ORF is applicable in the context of a Virtual >> Hub-and-Spoke VPN. It may also be applicable in other BGP/MPLS VPN >> environments. >> >> >> >> >> >> Please note that it may take a couple of minutes from the time of >> submission until the htmlized version and diff are available at >> tools.ietf.org. >> >> The IETF Secretariat >> >> >
