Hi, I think this suggestion is ill-considered. We don't want two alternative solutions.
Yours Irrespectively, John From: BESS [mailto:[email protected]] On Behalf Of Haoweiguo Sent: Tuesday, November 25, 2014 8:02 AM To: Henderickx, Wim (Wim); [email protected]; [email protected] Subject: Re: [bess] A comment and question for the draft "draft-ietf-bess-evpn-inter-subnet-forwarding-00" Hi Wim, Yes, the design has flexibility. But for most scenarios, we don't need this flexibility, we want to more compact encoding method. If all MAC routes advertised from a egress NVE share same NVE MAC and tunnel type, the two BGP Extended Communities carried with each MAC route is redundant, egress NVE only needs advertise its NVE MAC and tunnel type only once. I think we had better provide two alternative solutions, one is for flexibility, another one is for compactness. Depending on different scenarios, the vendors can choose one for implementation. Thanks weiguo ________________________________ From: Henderickx, Wim (Wim) [[email protected]] Sent: Tuesday, November 25, 2014 19:02 To: Haoweiguo; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Subject: Re: [bess] A comment and question for the draft "draft-ietf-bess-evpn-inter-subnet-forwarding-00" The reason we did this is providing the most flexibility because depending on the use case you need one and not the other. Hence we optimised for flexibility. From: Haoweiguo <[email protected]<mailto:[email protected]>> Date: Tuesday 25 November 2014 10:21 To: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, sajassi <[email protected]<mailto:[email protected]>> Subject: [bess] A comment and question for the draft "draft-ietf-bess-evpn-inter-subnet-forwarding-00" Hi Ali and other Co-authors, In the EVPN IRB draft, Route Type-2 is used to advertise TS's MAC and IP. Two BGP Extended Communities are carried with each RT-2 route. The first community carries tunnel type, the second community carries NVE MAC. In normal case, all RT-2 routes from a remote NVE share same NVE MAC, so in this case the Route information encoding isn't compact. So a new compact encoding method is introduced as follows: 1. Add tunnel type field in Route Type-2. 2. Introduce a new Route Type to exclusively advertise tunnel type,NVE MAC and L3 VN ID. 3. Ingress NVEs correlate the new Type Route and RT-2 routes advertised from egress NVE to get the NVO3 encapsulation information for inter-subnet IP traffic forwarding. Maybe there are other more compact methods. I would like to hear your co-authors opinion on this point. Thanks weiguo
_______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
