CC'ing tsv-art...
On 9/26/2016 2:34 PM, Joe Touch wrote: > > Hi, all, > > I've reviewed this document as part of the Transport Area Review > Team's (TSVART) ongoing effort to review key IETF documents. These > comments were written primarily for the transport area directors, but > are copied to the document's authors for their information and to > allow them to address any issues raised. When done at the time of IETF > Last Call, the authors should consider this review together with any > other last-call comments they receive. Please always CC > tsv-...@ietf.org <mailto:tsv-...@ietf.org> if you reply to or forward > this review. > > Please resolve these comments along with any other Last Call comments > you may receive. Please wait for direction from your document shepherd > or AD before posting a new version of the draft. > > Document: draft-ietf-opsawg-capwap-alt-tunnel > Title: Alternate Tunnel Encapsulation for Data Frames in CAPWAP > Reviewer: J. Touch > Review Date: Sept 26, 2016 > IETF Last Call Date: Sept 16, 2016 > > Summary: This doc refers to existing tunneling specifications, many of > which are inconsistent or incorrect. In particular, there are > potential complicatinos with MTU support and signalling that could > affect transport protocols. > > Major issues: > > As already noted in draft-intarea-tunnels, many existing tunnel > mechanisms are inconsistent or incorrect in their support for IPv6 MTU > requirements, both as transits for IP packets and as IP endpoints. > Although this document cites existing standards, the inconsistency and > incorrectness of these standards should be addressed. It might be > sufficient to indicate that any tunneling mechanism selected MUST > support the minimum IPv6 MTU requirements independent of this > signalling mechanism (i.e, the signalling mechanism doesn't address or > correct any errors or inconsistencies in the tunnel mechanism selected). > > Regarding IP endpoint requirements, it might be useful to consider > whether this protocol could be extended to indicate the receiver > payload reassembly limit when indicating support for each tunnel type, > to assist the source in determining whether the resulting tunnel will > be IPv6 compliant (rather than becoming a black hole for valid packet > sizes). > > Additionally, for the transport protocol-based tunnels, it would be > useful to consider whether the protocol could indicate not only the > endpoint IP address but the port number as well. > > Minor issues: > > It might be useful to consider IPsec TLS, and DTLS tunnels as well as > those already listed. > > ---
_______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
