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 protected] [mailto:[email protected]] On Behalf Of Robert Raszuk
Sent: Friday, October 18, 2013 1:40 PM
To: Lucy yong
Cc: Ronald Bonica; [email protected]
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.
