No :) New extended community is not a new attribute. r.
On Fri, Oct 18, 2013 at 10:04 PM, Lucy yong <[email protected]> wrote: > > 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 > > > > > 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.
