> 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. 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. > You also seem to think security is optional. It thought those days were > over as well. I did not say that. I said complicate functions (like doing crypto in hardware) is something YOU MUST do so there is no choice. Other than a working system, the next absolute requirement is a working system that can do security. Dino > > Fair enough. > > Joe > > On 7/21/2016 3:13 PM, Dino Farinacci wrote: >>> These are data plane functions for ingress/egress processing, which >>> already does things like IPsec tunnel mode, IP in IP, IP in UDP in IP, etc. >> All with fix length headers. These packet formats allow the hardware to do a >> few input checks in fixed places. >> >> Crypto is way different and a very complex but it is a "can't ship without >> it" feature. >> >>> I'm not sure about the others, but why is GUE so complex? It would still >> Jump, test type, decide if you support it, validate the value field, do the >> feature of the type (if you support it), then add length, go to next type, >> rinse and repeat. >> >> And that doesn't even consider if there are sequencing requirements among >> the TLVs. >> >>> allow data plane processing using existing IP forwarding, including DPI >>> access to port numbers. >> Not following and I think not relevant. >> >> Dino > _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
