On 11/10/2015 07:40 PM, Donald Sharp wrote: > Any way to combine the lsp_build_ext_reach_ipv4 and v6 functions? I > noticed in the ipv4 version of the function we set some METRICS_UNSUPPORTED > values, but not in the v6, shouldn't we as well?
The TLV format between ipv4 and ipv6 is somewhat different. For ipv4, there are two different TLV types, depending on whether old-style or new-style (narrow vs wide metric) TLVs are used. The old-style TLVs have fields for delay/loss/cost based metrics which are defined in ISO 10589:1998 and have never seen much use for IP networks. For this reason, they have not been included when IS-IS for IPv6 routing was standardized, so there is no need to set any fields to METRICS_UNSUPPORTED there. Also, there is only one IPv6 TLV that has space for wide metrics, so for IPv6, the equivalent of IPv4 new-style is always used. Given these differences, I think that it would be hard to write a function that handles both IPV4 and IPv6 in a readable fashion. This is also because of IPv4 and IPv6 using different structs for their representation, so a lot of the code could actually not be shared between IPv4 and IPv6 because it is similar code but references different types. (Unless one considers a macro, but I'm not sure that it would be appropriate for this case) (Also, the pending IS-IS dest-src routing code makes the IPv4 and IPv6 path even more different) If you can write a readable function that treats both families, I wouldn't object to it. I just tried it initially and gave up on it, since I ended up with a function that was almost the sum of the current two functions in length. > Should str2family be abstracted into lib/ somewhere? lots of protocols > have code to handle ipv4/v6 but they handle it slightly different. > Probably wouldn't be a bad idea to go down the path of abstracting this as > much as possible. I tend to agree. I can move it to lib/ and I can grep for obvious cases where it might be useful, but I am not sure that I have the time to thorougly go through the whole codebase to find every location where it might be useful. -Christian _______________________________________________ Quagga-dev mailing list [email protected] https://lists.quagga.net/mailman/listinfo/quagga-dev
