ietf
[Top] [All Lists]

Re: TSV ART IETF LC review of draft-ietf-opsawg-capwap-alt-tunnel

2016-09-26 16:37:45
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-art(_at_)ietf(_dot_)org <mailto:tsv-art(_at_)ietf(_dot_)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.

---

<Prev in Thread] Current Thread [Next in Thread>