Osama, Yes I have read the draft. It is describing a solution to problem which does not exist in practice.
Ref: http://www.opencontrail.org/ The crux of the issue you are solving is here: Each NVE is a BGP speaker. Operator may configure single and unique VNID for each tenant network on all NVEs or configure NVEs to locally allocate VNID for each VRF on the NVEs, the VNID is called VNID-t. If you would not mess up RFC4364 with VNIDs and use vanilla MPLS label as a demux you would not require any additional mapping at the ASBRs hence your option B as well as option C would work seamlessly. All over plain IP CLOS fabric + any type of WAN. That is my point. Best, r. On Mon, Apr 13, 2015 at 3:13 PM, Osama Zia <[email protected]> wrote: > Robert, > > > > I am not sure if you have read the draft. The discussion here is not about > using RR. It is about looking at how option B is used in the context of > inter-as where both sides are not using MPLS. I would argue that in this > solution option-C provides no real benefit. For scaling purposes we are > already proposing a centralized solution. > > > > Thanks, > > Osama > > > > > > *From:* [email protected] [mailto:[email protected]] *On Behalf Of *Robert > Raszuk > *Sent:* Saturday, April 11, 2015 3:03 AM > > *To:* Osama Zia > *Cc:* [email protected] > *Subject:* Re: [bess] draft-hao-bess-inter-nvo3-vpn > > > > Osama, > > > > To the best of my knowledge RRs are pretty base elements in BGP :) > > > > If you have 1000 of endpoints within any data center please kindly observe > that it is not only ASBR option B information that they need (even if you > would establish 1000 IBGP vpnv4/6 sessions to such border router. > > > > Such endpoints also need to exchange information between themselves and > here again RRs come to the rescue (at least for the time being). > > > > So I recommend to look not at one particular function you are pushing, but > at entire picture then evaluate the need for RRs likely with RTC or not. > > > > Best, > > r. > > > > > > On Sat, Apr 11, 2015 at 4:15 AM, Osama Zia <[email protected]> wrote: > > I was talking about the base model. You are right that we may solve the > scalability problem by introducing RR. > > > > However, with the proposed solution we achieve the same thing without > using RR. > > > > Regards, > > Osama > > > > *From:* [email protected] [mailto:[email protected]] *On Behalf Of *Robert > Raszuk > *Sent:* Friday, April 10, 2015 3:42 PM > *To:* Osama Zia > *Cc:* [email protected] > *Subject:* Re: [bess] draft-hao-bess-inter-nvo3-vpn > > > > Hi Osama, > > > > > This would mean the other service provider will need to establish > > > EBGP sessions possibly in thousands which is not practical. > > > > That assertion is not correct. > > > > Option C for route distribution scaling uses route reflection in each > cluster therefor eliminating the need to establish more then one (or two > for redundancy) EBGP sessions between data centers or independent clusters. > > > > Cheers, > R. > > > > > > > > On Sat, Apr 11, 2015 at 12:32 AM, Osama Zia <[email protected]> wrote: > > Looking at the minutes, I think there wasn’t enough time left for the > draft-hao-bess-inter-nvo3-vpn that a discussion could take place. > > > > I will explain the answer to the question that was asked. > > > > In option C the ASBR-W will have to establish EBGP will each NVE in the > DC. NVE in some cases could be a ToR and in most cases will be a software > gateway in the hypervisor. In any case the number of NVEs can run in > thousands. This would mean the other service provider will need to > establish EBGP sessions possibly in thousands which is not practical. In > this scenario Option-B will provide the architecture to address the scaling > issue. > > > > I would like to request additional comments and call for adoption. > > > > > > Regards, > > Osama > > > > > > > > > > > > *From:* BESS [mailto:[email protected]] *On Behalf Of *Susan Hares > *Sent:* Wednesday, April 8, 2015 2:29 PM > *To:* [email protected] > *Subject:* [bess] Minutes for IETF 92 BESS meeting > > > > > > The BESS minutes for IETF 92 session are attached (html, pdf). Should you > want to make changes to the minutes, you may edit the etherpad location. > The minutes have been upload to the etherpad for BESS 92 which is at: > > > > > http://etherpad.tools.ietf.org:9000/p/notes-ietf-92-bess?useMonospaceFont=true > > > > Sue Hares > > > _______________________________________________ > BESS mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/bess > > > > >
_______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
