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. On Fri, Oct 18, 2013 at 9:47 PM, Lucy yong <[email protected]> wrote: > 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.
