Hi Sam and DT, Thanks for the work.
A few comments: >From section 6.6: "...if options are added over time and different subsets of options are likely to be implemented in different pieces of hardware, then it would be hard for the IETF to specify which options should get the early bit fields." - Many IETF protocols have flag fields. Please quantify why this is a particular issue for nvo3, or why getting a bit an flags field is particularly harder than getting an option number in something like IP or TCP. "But transit devices would have issues with future GUE bits being defined for future options as well." - I don't believe this is true (albeit "issues" is rather ambiguous). When a new option is added in GUE their flags can only be added at the tail of the flag bits. This will in no way impact the ability of transit devices to process the options it already knows about. "A benefit of TLVs from a HW perspective is that they are self describing i.e., all the information is in the TLV." - There seems to be a running theme in this draft about optimizing for HW implementation. The nvo3 protocol is not a hardware protocol, the requirement is that it is hardware friendly. Even if I were to believe that implementing TLVs in HW was easier than bit fields, which I don't, TLVs are still much harder and less efficient in when implemented in software. Please try to strike some balance between the descriptions of both HW and SW implementation. - IMO, this draft is unnecessarily speculative and for forward looking. There is already a lot of practical experience deploying protocols with things like TLVs and bit fields which is relevant since most this draft's content is not specific to network virtualization. I've already mentioned that the feasibility for using TLVs needs to be reconciled with the experiences for IP options and IPv6 EH, and mentioned previously on the list that GRE already provides a example of a deployed encapsulation protocol that supports bit fields which are commonly supported in HW for some time. It would be nice to have some reference draft-ietf-rtgwg-dt-encap-02. There is a lot of overlap between these drafts although the latter goes in to significantly more depth for some topics. Thanks, Tom On Thu, Feb 9, 2017 at 9:03 AM, Sam Aldrin <[email protected]> wrote: > Hello NVo3 WG, > > NVo3 Design Team for encap has put in quite a bit of effort to meet, discuss > and hashout various requirements and issues and coming up with a draft on > proposed encap. Thanks to all who have participated and made it possible. > > This document could be found at > URL: > https://www.ietf.org/internet-drafts/draft-dt-nvo3-encap-00.txt > Status: https://datatracker.ietf.org/doc/draft-dt-nvo3-encap/ > Htmlized: https://tools.ietf.org/html/draft-dt-nvo3-encap-00 > > Kindly go through the document and review thoroughly and provide your > comments. > This will enable DT to close any issues or pending gaps. > > cheers > Sam & Matthew > > _______________________________________________ > nvo3 mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/nvo3 > _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
