Hi Jafar,
From: Jafar Al-Gharaibeh [mailto:[email protected]] Sent: Monday, December 21, 2015 12:49 PM To: Andrew Qu; Donald Sharp; Daniel Walton Cc: Quagga Devel Subject: Re: [quagga-dev 14302] Re: Multi-Topology Routing in OSPF On 12/21/2015 2:18 PM, Andrew Qu wrote: Hi Jafar, I didn’t mean to conclude anything yet. With a few years of effort in the past trying to bring MTR to customer but obviously failed to achieve what we wanted, hence if the effort is by anyway to be re-initiated, want to know If this time is different than last time from network use case, hence the asking to understand. I am not familiar with previous efforts to do MTR-OSPF in Quagga, and this is why I am bringing up the discussion here. When you refer to MTR and your failed attempt to achieve what you want, are you talking about the work I referenced in the original post, or something else? [Andrew] I didn’t mean MTR-OSPF effort in Quagga, I referred to the efforts we made jointed by a few BUs at Cisco. My confusion is that if we want to enable MTR hop by hop using IGP such as OSPF, then without the support in the network device, what is the use of doing it using IGP? What do you mean by hardware support? We want to populate different routing tables using different OSPF topologies and then use rout policies to pick an appropriate table - What am I missing here? [Andrew] I thought the routing tables will be eventually populated to forwarding engine which is mostly done by HW (NPU/FPGA/ASICs) in most networks. Then if you want to use MTR on just selected devices in the network that are capable of forwarding packets according to MTR, then I am not sure if it is right thing to do MTR in OSPF. Basically, my intention is to understand the requirements of MTR in OSPF. We have Linux/Quagga routers running OSPF, and as I mentioned above we want to be able to route different classes (protocols, ports, dscp) of traffic differently. This should happen on all routers in the network. This depends on the ability of OSPF to build different spf trees based on different metrics for each link. [Andrew] my question was not clear. developing MTR in OSPF as control plane is a partial solution to the end user, network forwarding engines in any form must forward the packet according the MTR table which is different than plain (vpn, ip/prefix) FIB table. my question is really that how the entire network is designed to carry out MTR forwarding when each router build up MTR tables. Thanks, Andrew --Jafar From: Jafar Al-Gharaibeh [mailto:[email protected]] Sent: Monday, December 21, 2015 9:39 AM To: Andrew Qu; Donald Sharp; Daniel Walton Cc: Quagga Devel Subject: Re: [quagga-dev 14302] Re: Multi-Topology Routing in OSPF On 12/20/2015 11:51 PM, Andrew Qu wrote: In order to support MTR, we worked hard as well to design our ASIC in catalyst 6500 family. ☺ That feature is very ASIC resource demanding and I think that was latest HW piece can do MTR forwarding. Without ASIC that can support MTR in the industry now, could Jafar share something with us why we need to develop MTR routing? I don't know if I fully understand the ASIC/lack-of-MTR-support comment and why that should stop Quagga from getting this support. We run Quagga on platforms that can do MTR if Quagga supports it. As of why do we need MTR - are you suggesting that it is not needed at all? or it doesn't bring anything to the table that we can't do using other techniques? Can you please elaborate? Thanks, Jafar My personal believe is that with the introduction of source based routing scheme recently ( such as segment routing), MTR may be easier to be supported in the network end-to-end that way. Thanks, Andrew From: Donald Sharp [mailto:[email protected]] Sent: Sunday, December 20, 2015 6:34 AM To: Daniel Walton Cc: Jafar Al-Gharaibeh; Quagga Devel Subject: [quagga-dev 14302] Re: Multi-Topology Routing in OSPF It shipped and then got shelved because it was available on one platform and no-one was using it. But yes I spent a large amount of time getting it to work under EIGRP :) donald On Sun, Dec 20, 2015 at 8:55 AM, Daniel Walton <[email protected]<mailto:[email protected]>> wrote: On Fri, Dec 18, 2015 at 7:24 PM, Jafar Al-Gharaibeh <[email protected]<mailto:[email protected]>> wrote: Hi Everyone, I have been looking into the ability to support multiple cost metrics per link for ospf, which is something that I brought up in our first Quagga monthly meeting. The "official" term for that is Multi-Topology (MT) Routing in OSPF which is described in RFC 4915 (https://tools.ietf.org/html/rfc4915). After some digging I found that this was actually brought up 6 years ago on this list: https://lists.quagga.net/pipermail/quagga-dev/2009-July/006789.html And It seems like there was a collective effort to get this up and running with progress on github here: https://github.com/tomhenderson/quagga-mtr/ I see names like Paul, Vincent, Joakim among others who had contributed to this effort. I haven't checked to see how far did this go but it seems nobody has touched it in 5 years. Multi routing table support was not very common at the time in Linux kernels, and the same can be said about VRF which are things that could have hindered the move at the time but I'm not sure. Can anyone tell me please about that project or any similar efforts? Somewhat related...didn't cisco eventually abandon MTR? I remember them dumping huge resources into this but if my memory is correct the whole project was cancelled (from googling it looks like it did ship though) Daniel _______________________________________________ Quagga-dev mailing list [email protected]<mailto:[email protected]> https://lists.quagga.net/mailman/listinfo/quagga-dev ************* Email Confidentiality Notice ******************** The information contained in this e-mail message (including any attachments) may be confidential, proprietary, privileged, or otherwise exempt from disclosure under applicable laws. It is intended to be conveyed only to the designated recipient(s). Any use, dissemination, distribution, printing, retaining or copying of this e-mail (including its attachments) by unintended recipient(s) is strictly prohibited and may be unlawful. If you are not an intended recipient of this e-mail, or believe that you have received this e-mail in error, please notify the sender immediately (by replying to this e-mail), delete any and all copies of this e-mail (including any attachments) from your system, and do not disclose the content of this e-mail to any other person. Thank you! ************* Email Confidentiality Notice ******************** The information contained in this e-mail message (including any attachments) may be confidential, proprietary, privileged, or otherwise exempt from disclosure under applicable laws. It is intended to be conveyed only to the designated recipient(s). Any use, dissemination, distribution, printing, retaining or copying of this e-mail (including its attachments) by unintended recipient(s) is strictly prohibited and may be unlawful. If you are not an intended recipient of this e-mail, or believe that you have received this e-mail in error, please notify the sender immediately (by replying to this e-mail), delete any and all copies of this e-mail (including any attachments) from your system, and do not disclose the content of this e-mail to any other person. Thank you!
_______________________________________________ Quagga-dev mailing list [email protected] https://lists.quagga.net/mailman/listinfo/quagga-dev
