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. > It looks like the intent is to have a control plane that defines the TLVs that will be used, a required ordering, and the assumption that all TLVs are all the same size. If that is true then parsing TLVs can be turned into a parallel problem, e.g. that can be accomplished with 2^N entries in a TCAM the same as bit fields. But, now implies that explicit tunnels need to be established by the control plane before the data plane can be used, and to be practical probably means that a node will expect to receive pretty much the same set of TLVs with the same order from all communicating devices (or maybe the intent is to have a universal ordering of TLVs?).
It would be good to have a reference to other low layer protocols that include TLVs or the like, especially IPv4 and IPv6, and an explanation as to how TLVs in nvo3 will address all the issues of those protocols that have deterred deployment of TLVs. Tom > - 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). > > 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
