On 7/21/2016 3:37 PM, Dino Farinacci wrote: >> Thanks - I was trying to understand the basis of your objection. > No prob. > >> You appear to be against variable packet formats in an form (which is >> your choice, but I don't understand how we can develop protocols that >> aren't instantly ossified that way). > Back during the IPng directorate days we (router vendors) wanted variable > length addresses but fixed length packets. We wanted the destination address > to be in byte 0 of the network layer header. ;-) > > In this case of encapsulation protocols, like I said at the mic, if you are > going to put an option in a header and later add new functionality, you have > to make big changes to the new product that supports it. If you have to make > this change, you may as well just define a new header. So just get a new UDP > port number with a new protocol.
Port numbers are assigned for entire services, not for each component nor for each version of a protocol anymore (see the two docs of BCP 165). So at best you're just saying that the entire header is redefined for each version number in the header (which admittedly is just a two-step check - port and version - rather than a one-step of just port). > Rather than put in TLVs guessing what the future may hold while every packet > now has to parse these more complicated headers. > > Write a block in Verilog, and make the block fit when other logic designers > (like 100 of them) are doing the same. You merge the blocks, they don’t fit, > then you go back and take things out. What happens in the 2nd and subsequent > revs is SRAMs get smaller or features get dropped out. That seems like you're designing to only what you can fab efficiently right now and you expect to have a sequence of a thousand flowers in a row. Which means you've only replaced variable headers in one protocol with a large, varying set of fixed headers. It's hard to see the latter as a win, especially when what you can implement in hardware in 3 years will be quite different. Joe _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
