I'd just move str2family into lib/... and call it a day. Acked-by: Donald Sharp <[email protected]>
On Tue, Nov 10, 2015 at 1:56 PM, Christian Franke < [email protected]> wrote: > 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
