On Wed, Jul 20, 2016 at 5:06 PM, Paul Quinn (paulq) <pa...@cisco.com> wrote: > >> On Jul 14, 2016, at 11:39 AM, Jesse Gross <je...@kernel.org> wrote: >> >> On Wed, Jul 13, 2016 at 10:44 PM, Elzur, Uri <uri.el...@intel.com> wrote: >>> +1 on starting w MD Type = 1 >>> >>> Not sure I understand the concern expressed with " implementations that >>> don't implement TLVs will become deployed and then when there is a use for >>> them it's no longer possible." - why will it not be possible to add MD >>> Type=2 later? >> >> As I said, it's a classic problem with IP options. Classic enough that >> people frequently content that TLVs are not usable at all because they >> don't get implemented which then becomes a self fulfilling prophesy. >> > > Jesse, the issue with IPv4 options has nothing do the actual option(s) but > rather the "cost" associated with the handling, particularly in hardware, of > variable length packets.
This is a cost vs. benefit tradeoff. I'm fairly certain that had options been an integral part of handling IP from the start, router vendors would have decided to handle them rather than not processing IP. However, since there was little benefit at that time, it was generally decided that it wasn't worth it and certainly nobody is going to bother doing it today because everybody knows that options are unusable since no one implements them. I think in general it is a pretty well known property that extensibility is a use it or lose it type of thing. TCP has options as well that directly resemble IP and they are available and implemented today because they are necessary for common functionality. I am aware that TCP is primarily implemented at the software layer and not hardware but as I think we can see from the discussion in this thread, trying to limit implementations to the minimum functionality that seems necessary at the time is not only applicable to silicon. >> I think I've been extremely clear on this matter. I also think that >> I've been extremely consistent - I think I've said the same thing on >> every review of this patch series, so it should not exactly be a >> surprise. However, the bottom line is I want to see a complete >> implementation of the protocol and not a half measure that will catch >> people by surprise or limit future usage. That seems 100% reasonable >> to me. > > The adopted NSH draft clearly states that type-1 support in mandatory, and > that type-2 support is optional. As such the OVS patches are compliant. > Having said that, the current code also supports skipping the type-2 based on > the length of NSH conveyed in the first word of the header. This, I believe, > constitutes support: type-2 NSH packets, if used, are supported: the type-2 > info is skipped and OVS functions as expected. > > It appears that your definition of support differs from that, can you expand > on it please? As I have said, I would like to see real support for MD type 2 so that it is useable in the future. I don't think that this patch set fulfills that criteria. At this point, I have not heard a technical argument as to why MD type 2 support shouldn't be implemented now. I have given my reason why it is important to do it and the only objection seems to be that the authors don't wish to take the time. Considering that the discussion of how to do it has continued in another thread (thank you Jan for helping to move things forward), it seems more productive to focus on that rather that continue this debate. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
