Ron:
I have a number of comments on the draft.
Clarifications:
The discussion of traceroute in section 5, 2nd para. Are you really saying that
traceroute only reveals the current layer/level and reveals no knowledge of nesting of
lower layer/level tunnels or the relationship of the current level to higher levels?
It doesn't clearly come out.
Comments on application requirements (numbers correspond to the requirement):
1) I think a broader discussion of some of the security issues needs to be raised. First by
whatever means a trace request needs to be able to be instantiated at a tunnel end
point. Second, as a result of initiating a trace, any node in the network may be required to
generate a response to the tracing application. Therefore the tracing application is required
to promiscuously accept responses. A mechanism is required to authoritatively associate
responses with requests and discard spurious messages. Further such a mechanism should not be
able to be leveraged for denial of service attacks (e.g. spurious trace responses forcing lots
of cryptography, defense against replay attacks etc.).
2) Any interface? I think any routable interface (mind you this is where separating out routing
limitations into a separate section reduces the clarity). I think there is a separate stipulation that
there is no representation as to the number of protocol exchanges it takes to perform a trace
(other than permitting the trace originator to perform some measure of flow control by the protocol
being designed to bound the number of responses a transaction will elicit; ideally 1 to 1, this also
has DOS implications similar to ICMP smurf type attacks whereby the responses to a single
message can be unbounded). You actually bring this up obliquely in the protocol requirements, but IMHO it
should be expressed less prescriptively.
3) Is third party really a special case? Can I not instantiate an in-line trace using management
protocols etc. and pull back the results.
4) the application "displays" tunnels (editorial nit)? are we really discussing how much information the
application collects and reports on. The alternative interpretation is that the same amount of
information is always collected, and somehow filtered during presentation.
4) When you say "single hop" or "in detail", are you really saying "this layer" or "constituent
lower layer components"? It could use clarification.
5) Are you sure the collected information includes round trip delay? It's not clear to me
whether this is some pre-existing chunk of information just lying around, or where the trace
transaction is expected to measure RTT on the fly for every hop and provide current view.
6) I think are more accurate statement is support any tunneling technology that is used between
IP endpoints. Otherwise this is not a sustainable requirement. I am concerned, for example, that
any intervening L2 or layer 2 and a half skewers the model. (e.g.. IP/PPP/L2TP, you can only
reveal the PPP end points, or if you look at L2TP tunnel switches, you appear to be SOL)
7) This is the "detail" referred to earlier? Seems this one is subject to the routing
requirements reported later. Might be easier simply to introduce that limitation here.
8) Is the expectation that the quality of information obtained from a control plane trace and a
forwarding plane be comparable? Can you clarify what you mean by a control plane trace? I can see augmenting
signalling protocols to faciliate this (e.g. LSP query I-D), but that does not fit into this discussion.
10) This seems to be overlapping with a solution framework.
11) Any intention of aligning TTL models with the terminology emerging elsewhere (pipe or uniform
models?).
13) Don't quite grok the motivation. I plead ignorance ;-)
The protocol requirements section is actually rather prescriptive. There are specific requirements
in there that end up as either application limitations or part of an applicability statement (e.g. routing
requirements) or design guidelines. The rest shouldn't be in this document.
IMHO at the present time the document is not quite ready for "prime time".
my two cents
Dave