Hi Lucy, "Pull" model is well described in RFC4684 and ORF brings zero advantage over it as far as RT based trigger.
The approach the above draft took requires more then just RT based "pull" hence the dillema - to extend RFC4684 or run over ORF. Authors took the latter while one may argue for the former. The solution I proposed however (and now reading my l3vpn backlog I see that also Xuxiaohu mentioned however without discussing state removal) has major advantage that it works fine without any protocol extension and upgrade of existing boxes. It is much simpler one. The practical difference of my proposal vs draft-bonica-l3vpn-orf-covering-prefixes is that in my scheme prefixes of significant flows will be distributed to all v-spokes vs only those which indicate the need for them like described in the draft. That to me seems as acceptable tradeoff avoiding added complexity and deployment obstacles. Best regards, R. On Mon, Oct 14, 2013 at 3:51 AM, Lucy yong <[email protected]> wrote: > Hi Robert, > > I am not a co-author of the draft but am interested in the problem. In fact, > the problem was discussed year ago in nvo3 mailing list. > > BGP RTs are used for controlling route distribution and BGP route > distribution specified in rfc4364 is the pure "push" mechanism. This draft > intention is to implement a "pull" capability in BGP/VPN. The solution you > proposed can solve the v-spoke/v-hub use case described in the draft but, > IMHO, it still uses "push" mode, i.e. under v-hub solo control. So it may not > apply to other "pull" scenarios. > > I am not sure yet that implementing "pull" capability by BGP RT and rfc4684 > is the right way and like to hear your opinion on it. IMO: ORF has the native > "pull" characteristic. > > Regards, > Lucy > > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > Robert Raszuk > Sent: Friday, October 11, 2013 4:18 PM > To: Ronald Bonica > Cc: [email protected] > Subject: Re: FW: New Version Notification for > draft-bonica-l3vpn-orf-covering-prefixes-00.txt > > 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 >>> >>> >>
