Robert,
If I read you correctly, V-Hub1 receives an advertisement for
RT-RED:10.1.1.0/24 and originates an advertisement for
RT-RED-FROM-V-HUB1:10.1.1.0/24. Somehow, V-Hub1 has to tie the two
advertisements together, because if PE1 withdraws RT-RED:10.1.1.0/24, V-Hub1
must withdraw RT-RED-FROM-V-HUB1:10.1.1.0/24.
Am I reading this correctly?
Ron
> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On Behalf Of Robert
> Raszuk
> Sent: Friday, October 18, 2013 12:05 PM
> To: Ronald Bonica
> Cc: [email protected]
> Subject: Re: FW: New Version Notification for draft-bonica-l3vpn-orf-
> covering-prefixes-00.txt
>
> 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
> >> >>
> >> >>
> >> >
> >>
> >
> >
>
