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
> >>
> >>
> >
>
