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

[Lucy yong <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] On Behalf Of Robert Raszuk
Sent: Friday, October 18, 2013 1:40 PM
To: Lucy yong
Cc: Ronald Bonica; [e-mail]
Subject: Re: FW: New Version Notification for draft-bonica-l3vpn-orf-covering-prefixes-00.txt

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.