Subject: Re: FW: New Version Notification for draft-bonica-l3vpn-orf-covering-prefixes-00.txt

From: Robert Raszuk <[email-masked]>
Date: Fri, 11 Oct 2013 23:18:08 +0200

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-masked]> wrote:
>
> Please review this draft and provide comments.
>
>                                Ron
>
>
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]]
>> 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
>>
>>
>

---

From: Lucy yong <[email-masked]>
Date: Mon, 14 Oct 2013 01:51:28 +0000

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-masked] [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Friday, October 11, 2013 4:18 PM
To: Ronald Bonica
Cc: [email-masked]
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-masked]> wrote:
>> Subject: New Version Notification for 
>> draft-bonica-l3vpn-orf-covering- prefixes-00.txt
>>
>>

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 14 Oct 2013 10:27:29 +0200

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.

---

From: Lucy yong <[email-masked]>
Date: Mon, 14 Oct 2013 16:19:34 +0000

Hi Robert,

Thanks. Please see inline.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Monday, October 14, 2013 3:27 AM
To: Lucy yong
Cc: Ronald Bonica; [email-masked]
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-masked]> wrote:
> Subject: Re: FW: New Version Notification for 
> draft-bonica-l3vpn-orf-covering-prefixes-00.txt
>
> Hi Ron,
>
>>> 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.
>>>

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 14 Oct 2013 18:30:37 +0200

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.

---

From: Lucy yong <[email-masked]>
Date: Mon, 14 Oct 2013 16:49:53 +0000

Robert,

As I said, the proposed solution is a start point, not perfect yet.

Whether V-spoke1 can create a route target automatically or operator configured is local action. The mechanism allows both. I don't see the following statement excludes that.

Lucy

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Monday, October 14, 2013 11:31 AM
To: Lucy yong
Cc: Ronald Bonica; [email-masked]
Subject: Re: FW: New Version Notification for draft-bonica-l3vpn-orf-covering-prefixes-00.txt

Lucy,

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

---

From: Ronald Bonica <[email-masked]>
Date: Fri, 18 Oct 2013 15:42:10 +0000

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

> Sent: Friday, October 11, 2013 5:18 PM
> To: Ronald Bonica
> Cc: [email-masked]
> of clarification would be nice as in general 4684 is preferred over ORF
> in VPN context.
> 
> 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.
> 
> V-spokes when the flow terminates ... while there is number of possible
> solutions in this space - simplest seems to be time driven.
> IETF

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 18 Oct 2013 18:05:03 +0200

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

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.

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 18 Oct 2013 18:32:44 +0200

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.

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.

---

From: Lucy yong <[email-masked]>
Date: Fri, 18 Oct 2013 17:03:53 +0000

Please see inline.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Friday, October 18, 2013 11:33 AM
To: Ronald Bonica
Cc: [email-masked]
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-masked]> wrote:
>> - 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
>>
>>> draft-bonica-l3vpn-orf- covering-prefixes-00.txt
>>>
>>> Hi Ron,
>>>
>>> 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.
>>>
>>> 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 
>>> 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.
>>>
>>> >>    Hub-and-Spoke VPN.  It may also be applicable in other 
>>> >> BGP/MPLS
>>> VPN
>>> >>    environments.
>>> >>
>>> >>
>>> >>
>>> >>
>>> >>

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 18 Oct 2013 20:39:30 +0200

Lucy,

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

The main point is not about using BGP or not. Here if anything
industry and in particular this WG has been converging to use RT
Constrain for controlling VPN route distribution. This draft however
now proposed ORF which runs over Route Refresh. That means that at
least one benefit of RTC is lost - incremental updates.

In fact I would say this is a grey area how to run RTC and ORF
together for the same set of VRFs.

My focus was not to debate about using BGP rather the focus is to use
right tool for the task.

Imagine I have deployed another L3VPN WG document namely:
draft-ietf-l3vpn-end-system-01

In such architecture I have decoupled for a number of good reasons
data plane and control plane to completely different physical boxes.
Note also that in such design I already have on the complete system a
stats collector where it is really trivial to trigger a message to
v-hub in order to inject more specifics.

Contrary if I am to use proposed solution I need to modify XMPP as
well as number of other system wide components to achieve the goal.

Best regards,
R.

---

From: Ronald Bonica <[email-masked]>
Date: Fri, 18 Oct 2013 18:48:54 +0000

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

> Sent: Friday, October 18, 2013 12:05 PM
> To: Ronald Bonica
> Cc: [email-masked]
> > 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:
> >
> >> Subject: Re: FW: New Version Notification for draft-bonica-l3vpn-
> orf-
> >> covering-prefixes-00.txt
> >>
> >> Hi Ron,
> >>
> digesting
> >> 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.
> >>
> 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
> deployable
> >> could be a single upgraded PE or new box in the network. Moreover
> >> this procedure does not require any protocol extension nor
> additional
> >> >> Title:                 Covering Prefixes Outbound Route Filter
> for
> >> BGP-4

---

From: Lucy yong <[email-masked]>
Date: Fri, 18 Oct 2013 19:47:54 +0000

Hi Robert,

If we have applications that need "pull" capability, we can develop a BGP "out-of-band" mechanism and/or BGP based mechanism. I agree that the use of Route Refresh to convey this request is not very good approach. How about this approach?

We can define a new extended community, say route-request. A BGP speaker can distribute NLRI with a requested address/prefix and this extended community that encodes the route target associated to this route. When a peer places the route into the Adj-RIB-Out, it applies the following rules:

   o  all BGP attributes except for Route Targets are unchanged

   o  The Route Target specified by the CP-ORF Import Route Target is
      added to the list or Route Targets that the route already carries

Of course, this extended community MUST mutual exclusive with Route Target extended community, i.e. separate "pull" and "push" action in NLRI.

Regards,
Lucy

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Friday, October 18, 2013 1:40 PM
To: Lucy yong
Cc: Ronald Bonica; [email-masked]
Subject: Re: FW: New Version Notification for draft-bonica-l3vpn-orf-covering-prefixes-00.txt

Lucy,

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

The main point is not about using BGP or not. Here if anything industry and in particular this WG has been converging to use RT Constrain for controlling VPN route distribution. This draft however now proposed ORF which runs over Route Refresh. That means that at least one benefit of RTC is lost - incremental updates.

In fact I would say this is a grey area how to run RTC and ORF together for the same set of VRFs.

My focus was not to debate about using BGP rather the focus is to use right tool for the task.

In such architecture I have decoupled for a number of good reasons data plane and control plane to completely different physical boxes.
Note also that in such design I already have on the complete system a stats collector where it is really trivial to trigger a message to v-hub in order to inject more specifics.

Contrary if I am to use proposed solution I need to modify XMPP as well as number of other system wide components to achieve the goal.

Best regards,
R.

---

From: Lucy yong <[email-masked]>
Date: Fri, 18 Oct 2013 19:50:29 +0000

Sorry for the rush. The second ballot should be:

o  The Route Target specified in the new extended community is
      added to the list or Route Targets that the route already carries

Lucy

-----Original Message-----
From: Lucy yong 
Sent: Friday, October 18, 2013 2:48 PM
To: 'Robert Raszuk'
Cc: Ronald Bonica; [email-masked]
Subject: RE: FW: New Version Notification for draft-bonica-l3vpn-orf-covering-prefixes-00.txt

Hi Robert,

Regards,
Lucy

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Friday, October 18, 2013 1:40 PM
To: Lucy yong
Cc: Ronald Bonica; [email-masked]
Subject: Re: FW: New Version Notification for draft-bonica-l3vpn-orf-covering-prefixes-00.txt

Lucy,

Best regards,
R.

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 18 Oct 2013 21:57:47 +0200

Extended community will not cut it.

My original reaction was why not to define the new BGP attribute and
use it within RTC SAFI ? But before I suggested that I wanted to
better understand the genesis of extending ORF.

That could also be encoded in BGP Wide Communities which we are (I
hope) close to re-publish soon.

Many thx,
R.

---

From: Lucy yong <[email-masked]>
Date: Fri, 18 Oct 2013 20:04:06 +0000

My original reaction was why not to define the new BGP attribute and use it within RTC SAFI ?
[Lucy] Extended community is a new attribute, isn't it? I don't get the second part.

Thanks,
Lucy

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 18 Oct 2013 22:17:30 +0200

No :) New extended community is not a new attribute.

r.