Re: [Int-area] SEAL - draft-templin-intearea-seal-05.txt
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Int-area] SEAL - draft-templin-intearea-seal-05.txt



Ralph,

Here are a few comments.  This document deserves more time than I've
given it.

Summary

This protocol specification provides a new and different tunneling
mechanism (actually, really two - one over UDP and one within in a new
protocol).  It provides back-signaling in an attempt to cause tunnel
ingresses to reduce their MTU.

Comments

To start with, this document could do with a heavy dose of editing for
brevity and clarity.  Substantial time is spent on the case for SEAL.  I
think we can all accept that there are MTU problems on the network.  We
needn't revisit each and every one of them.  Or if we must, let's do so
in a different document.  So for starters, start the doc at §1.2.

Second, while I realize that some might have grown attached to the name,
and that this is picky, the term "subnetwork" is so overloaded that it
is confusing to the casual reader such as myself.

There are a number of imprecise terms, such as "reasonable reliability"
that should be better qualified.  There are also some sentences that
just don't make sense.  For instance:

   While it is well known that the addressing
   properties of IPv4 are limited (hence the larger address space
   provided by IPv6), there is a lesser-known but growing consensus that
   other limitations may be unable to sustain continued growth.

???

This document normatively makes references to several other drafts,
including [draft-templin-intarea-vet], [draft-templin-ranger] and
[draft-russert-rangers] for a singular notion of the "enterprise
abstraction".  From a matter of readibility, and general approach to
standards, for a single definition can we reference a single document?

Section 4.3.6 dicusses the need for per-ETE state.  Security
Considerations do not adequately address mitigating attacks based on,
say, large pings or some other approach that can force a large packet to
return.

In addition, any mechanism where we would expect wide deployment
probably deserves substantial review.  Experimental in this case would
seem to me to be more appropriate than Proposed Standard.

Again, I wish I had more time for more detailed review.

Eliot


Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.