On Thu, Feb 9, 2017 at 10:46 AM, Joe Touch <[email protected]> wrote: > Hi, all, > > I found this document to have useful context for discussion for the most > part. > > Some notes below: > > - it would be useful to provide a summary of the unique requirements of NVO3 > that necessitate a new encapsulation protocol > > - there are many encapsulation issues not addressed, e.g., MTUs, > frag/reassembly and fragment ID size, etc. > > - the discussion of TLV vs. bitfields needs a bit more expansion. E.g., TLV > necessarily requires serial processing, whereas bitfields can be processed > in parallel. > > - A "jump over" option is trivially possible in any TLV system, but begs the > question of why the internal packet flow information needs to be examined > (vs using the flow info in the outermost header). Why is this an NVO3 > requirement? > > - TLV == bitfield for the first TLV field; i.e., TLV is a trivial way to > extend bitfield to multiple bitfields if needed. That might be worth > considering. > > - It might be useful to note that bitfields are much more difficult to > handle optionally (e.g., it would require multiple bits, one for the value > and several to tag the capability as "drop if not supported", "ignore if not > supported", etc.). > > - I disagree with MUST support a minimum of 64 bytes of options; making that > requirement effectively limits everyone to using only 64. IMO, that number > is both too small and sets the protocol up to have "dead wood" (i.e., larger > option space is specified but can't be relied upon so might never gain > traction). > Having both a minimum and a different maximum value is superfluous. The minimum value is the maximum value in practice. Consider that we deploy a solution using various vendors each of which support a different number of bytes in options. As long as we configure something less than the minimum number of option bytes then everyone is happy. The second we try to use more than the minimum number things start to break. Even though the vendors can claim compliance with the protocol we have lost interoperability.
Tom > Joe > > > On 2/9/2017 9:03 AM, Sam Aldrin 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 > _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
