On 16/03/14 22:24, Tom Herbert wrote: > On Sun, Mar 16, 2014 at 2:22 PM, Thomas D Nadeau > <[email protected]> wrote: >> that's kind of what you and russ were saying (and I agreeing): iteration, >> evolution and refinement have often proven better than revolution. >> > Iteration, evolution, and refinement are key and in fact this is > precisely a core rationale in GUE and geneve. We need the ability to > scale and adapt the data center to changing needs and threats, this is > the requirement. This translates into a requirement for extensible > protocols that we can modify and evolve as needed and in short > turnaround time.
I am sorry to disappoint you, network protocols are not sold in Walmart in the "disposables" isle. Standard network protocol's lifetime is > 10 years. Even if we discard hardware out of the equation, it is a standard it is still > 5 years. This is a result of economic realities - depreciation periods on equipment, RFI, RFQs, costs of training staff, developing debugging, benchmarking and analysis tools. People adopt standards so that they do not need to reinvest into these every 6 months. This is why it is called a "standard" and this is what IETF does as an organization. > > The example that I give in security: what if next week the latest > Snowden revelations expose some security hole in our data center-- if > this hole can be addressed by adding a token to my packets, then I > want to guarantee I retain the capability to do this. It's not > acceptable that I'd have to go back to standards to change this, and > neither is swapping out new hardware just because I extended a > protocol. It is a bit difficult to take seriously an example that extends RFC 3514 from one to 128 evil bit as a security measure. Especially against the class of adversaries you are referring to. > > I agree that modifying existing protocols would be the best direction > but that is going to require a real proposal which we can measure > against (no one has suggested a reasonable alternative). In lieu of > modifying an existing protocol, developing a a new one based on known > techniques and mechanisms is prudent. That is fine. Provided that you do requirements first. I have yet to see requirements. Sorry - "This extra 128 RFC 3514 bits will defend us against the [insert agency name]" is not a requirement (unless it is the first of April of course). When I see something that has a decent statement of requirements that does not read like marchitecture we can have a proper engineering conversation including how many standard engineering input units (espressos) does it take to implement it. A. > > Tom > > _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
