Lucy, > [Lucy] The proposed solution in above draft enables a BGP speaker to > express the interested route and creates a route target on fly as well as > the mapping.
The proposed draft does not create any RT "on the fly" It asks RR to color selected prefixes with the normal already pre-provisioned RT namely "RT-RED-FROM-HUB1". Here is the quote: "As it advertises those routes, it adds the CP-ORF Import Route Target to the list of route targets that they carry. The advertised routes may specify either V-hub1 or any other node as the NEXT-HOP. V-spoke1 subjects the advertised routes to its import policy and accepts them because they carry the route target RT-RED-FROM-HUB1." Best, R. On Mon, Oct 14, 2013 at 6:19 PM, Lucy yong <[email protected]> wrote: > Hi Robert, > > Thanks. Please see inline. > > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of Robert Raszuk > Sent: Monday, October 14, 2013 3:27 AM > To: Lucy yong > Cc: Ronald Bonica; [email protected] > Subject: Re: FW: New Version Notification for > draft-bonica-l3vpn-orf-covering-prefixes-00.txt > > Hi Lucy, > > "Pull" model is well described in RFC4684 and ORF brings zero advantage over > it as far as RT based trigger. > [Lucy] To me, this "pull" model is quite complex and properly only works in > static way. (I may be wrong) The mechanism requires pre-assigned all the > route targets by an administrator. There is no explicit mapping between route > target and route prefix. The mapping between route target and route are > implicitly done by the mapping between VPN site and route at the site via > operator configuration of export and import route target on each PE. Thus, > import Route Target mainly means to accept the route from some VPN sites. > There is no way for BGP speaker to express interested route to peers and a > peer only sends the route to the speaker. This is my understanding. > > 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. > [Lucy] The proposed solution in above draft enables a BGP speaker to express > the interested route and creates a route target on fly as well as the > mapping. The peer that has this route automatically exports this route target > when sending NRLI. IMO: it contains some capability that rfc4684 does not > have and the capability is important in supporting the endpoint mobility. I > may be wrong, like to hear your opinion. Note that I am not saying that this > solution is perfect, but it is a good start point. > > 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. > [Lucy] Agree. But it is the "push" model. Route path switching may have an > issue for some applications. > > 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. > [Lucy] The difference, I see, is "off-load" mechanism via BGP "pull model" > mechanism although it can apply to the same use case. > > Regards, > Lucy > > 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 >>>> >>>> >>>
