Please see inline. -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Robert Raszuk Sent: Friday, October 18, 2013 11:33 AM To: Ronald Bonica Cc: [email protected] Subject: Re: FW: New Version Notification for draft-bonica-l3vpn-orf-covering-prefixes-00.txt
Hi Ron, Just to add provided the three points may be an issue there is possible alternative still without any requirement to upgrade any of the existing v-spokes or RRs. It is normal today for PEs to enable netflow statistics. It seems feasible to me to have additional logic in the controller associated with netflow collector to analyse traffic patterns for any VPN interface of v-spokes and based on such analysis trigger advertisement of more specific routes on v-hubs or their withdraw. Such trigger would be "out of band" as far as routing protocols namely BGP. [Lucy] why do you think that this mechanism is simpler than the one proposed in the draft? To me, it just shifts the request capability outside BGP. It makes BGP simple, but not necessary mean the solution simpler. Lucy There are various alternatives possible anywhere from snmp, cli, xml script or I2RS protocol to accomplish such triggers for this application. Note also that in this case and one extra RT per spoke pre-provisioned normally at spoke creation the potential desire for avoiding unnecessary state on those spokes (even transient) where it is not required can be easily accomplished. Best regards, R. On Fri, Oct 18, 2013 at 6:05 PM, Robert Raszuk <[email protected]> wrote: > Hello Ron, > > As you noted the first three tradeoffs characteristics of "V-hub > solution" are just factors in functionality vs complexity equation. > My objective was to provide an alternative to accomplish optimal paths > on demand in the environment where RFC7024 is used. > > I am not making here any judgments if those will be acceptable in all > cases or not. > > Now let me reply to your question ... > >> So, the RR has received three advertisements for RD-RED:10.1.1.0/24, >> all with next-hop of PE1. Only the RTs vary. >> >> How does RR know which one to install? Which to advertise to its clients? > > RR does not need to know which one to choose as best. Paths advertised > from hubs will have unique RD hence will not be subject to compete in > BGP best path selection with paths advertised from PEs for respective > vpnv4 or vpnv6 prefixes. > > As result v-spokes will get all necessary routes and will be able to > use optimal routing till those more specific routes are not withdrawn. > No changes on RRs or V-spokes are necessary (in fact no changes for > entire RFC7024 are necessary on those network elements vastly > simplifying it's deployment). > > Best regards, > R. > > > > On Fri, Oct 18, 2013 at 5:42 PM, Ronald Bonica <[email protected]> wrote: >> Robert, >> >> Thanks for your thoughtful review and comments! For the purposes of this >> message, we will call the solution that you propose below, the "V-Hub >> Solution". >> >> We considered the V-hub solution and agreed that it might fulfill some >> operators' requirements. However, in some deployment scenarios, the CP-ORF >> solution is required. Specifically, it is required when the following >> factors are significant: >> >> - Sometimes, the V-Spoke can determine when a more direct route is required, >> but the V-Hub cannot. For example, the operator may want to use more direct >> routes only when the V-Spoke's interface to the V-hub exceeds a specified >> utilization level. >> >> - The V-Hub is never well-positioned to determine when a more direct route >> is no longer required and should be withdrawn. This is because once the >> V-Spoke begins to use the more direct route, the V-Hub doesn't see the flow >> any more. So, as you suggest, the V-Hub could withdraw the route based upon >> timer expiration. However, if the timer is too long, the result is excessive >> state. If the timer is too short, the result is churn and packet reordering. >> >> - Sometimes, the operator wants a more direct route to be advertised to >> exactly one V-Spoke, not all V-Spokes associated with a V-Hub. >> >> >> Additionally, I am not sure that the V-Hub solution would work in the >> following scenario. Assume the following: >> >> - RR is a route reflector >> - PE1, V-Hub1, V-Hub2, V-Spoke1 and V-Spoke2 are clients of RR >> - V-Spoke1 is a spoke to V-Hub1 >> - V-Spoke2 is a spoke to V-Hub2 >> - PE1, V-Spoke1 and V-Spoke2 all serve RED-VPN sites >> - PE1 advertises the prefix RD-RED:10.1.1.0/24, carrying RT RED-VPN, >> to RR >> - V-Spoke1 sends a large flow through V-Hub1 to 10.1.1.1 (in the >> RED-VPN) >> - V-Spoke2 sends a large flow through V-Hub2 to 10.1.1.1 (in the >> RED-VPN) >> >> As I understand the V-Hub proposal, the following will occur: >> >> - V-Hub1 advertises the prefix RD-RED:10.1.1.0/24 to the RR. This >> advertisement has next-hop equal to PE1 and carries RT-RED-FROM-HUB1 >> - V-Hub2 advertises the prefix RD-RED:10.1.1.0/24 to the RR. This >> advertisement has next-hop equal to PE1 and carries RT-RED-FROM-HUB2 >> >> So, the RR has received three advertisements for RD-RED:10.1.1.0/24, all >> with next-hop of PE1. Only the RTs vary. >> >> How does RR know which one to install? Which to advertise to its clients? >> >> >> Ron >> >> >>> -----Original Message----- >>> From: [email protected] [mailto:[email protected]] On Behalf Of >>> Robert Raszuk >>> Sent: Friday, October 11, 2013 5: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 >>> >> >>> >> >>> > >>> >> >>
