> 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
GUE is a different service than Geneve. They both have different ports, do they not? This was our premise with LISP. That if we needed to have a version 2, get a new UDP port number rather than carry a version number in every packet for really no good reason. People said you shouldn’t do that. That we can’t allocate ports willy nilly. Fast forward 8 years. We have new UDP port allocations for VXLAN, VXLAN-GPE, GUE, and Geneve. And you know there are more. So I would like to be a purist as the next guy, but this organization doesn’t exercise purity. > 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). Yep. But not version. Your port number is your version number. > 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 It never gets to 1000. Not in the data-plane. Let’s be practical and not over-estimate how fast vendors can adapt to new things. ;-) > with a large, varying set of fixed headers. It's hard to see the latter Yes, that each goes fast. You pay the cost later when you need the feature and it is more well defined. How long has it been since we created the IPv6 header, and vendors still do not know what to do with the flow field. We are using 28 bits in every packet for nothing. And now we have to build more compression algs to make IPv6 work better on RANs. > as a win, especially when what you can implement in hardware in 3 years > will be quite different. No, it really doesn’t change as often as you might think. Dino > > Joe _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
