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.
