On Fri, 28 Mar 2008, Jari Arkko wrote:
This would be very useful addition to the document. Authors?
But note that the overall experience from the specific approach chosen
here was that yes, its possible get it to working, but there are
significant issues both for deployment and for the way the protocol bits
are arranged. Remember that this was an experiment, not a design ready
for standardization. MTU problems are in the list that is in Section 5.3.
A lot of issues are brought up in Section 5 (and elsewhere). For
issues noted, for each I'd like to ask quostions such as:
- was this noticed in the testbed? how?
- was the issue relevant in that context; if not, why not?
- if the issue was noticed, how was it worked around? which
approaches worked (in that restricted context), which did not?
- if the issue was not worked around, what kind of impact not
doing so had in the testbed and in testing?
I suspect some of the issues listed were addressed in some way (not
necessarily in a globally applicable way). For example, wrt MTU
issues, a statement like "MTU increase was not an issue because the
transit network provided 9000B MTU" or "Participating hosts were
manually configured to use 1280B MTU" would have been useful.
So, when reading the report, I find it has basically the following
kinds of content:
1) some general overview of the problem space
2) description of new mechanisms developed
3) description of the testbed where mechanisms were tested
4) description of issues to be considered in future work
However, 4) seems to be mainly about 1) and 2); it would have been
possible to write fundamentally the same draft without any significant
testbed deployment. In other words, the experiences from the testbed
and deployment itself are not extensively captured in the report, and
as a result it is not obvious how useful the testbed was when
considering follow-up activities in this space.
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
IETF mailing list