[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: draft-bonica-tunneltrace-02
All,
David has raised many good points that don't seem cosmetic but rather more fundamental. Why should a document be approved as a WG doc. if there are so many conflicting issues?
Enrique Cuevas
AT&T Labs
_______________
ecuevas@att.com
Tel. (732)-420-3252
>-----Original Message-----
>From: Loa Andersson [mailto:loa.andersson@utfors.se]
>Sent: Wednesday, February 20, 2002 11:31 AM
>To: David Allan
>Cc: Ron Bonica; ccamp@ops.ietf.org
>Subject: Re: draft-bonica-tunneltrace-02
>
>
>All,
>
>a more IETF (possibly ccamp) philosophical question. What do
>we do when we accept a document as a WG document. In my mind
>it is a step taken when we realise that this is something that
>the WG group should do and the document is a good enough starting
>point for doing this work.
>
>Even if I agreed with all of Dave's comments it is my 2 c's
>that both the criteria above are met and that we should progress
>the doc as a WG document.
>
>There will be a couple of iterations where the comments will be
>addressed and possibly be worked into the final req doc.
>
>
>/Loa
>
>David Allan wrote:
>
>> 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
>>
>
>
>--
>Loa Andersson
>Chief Architect,
>Utfors Research, Architecture and Future Lab (URAX)
>Utfors AB
>Råsundavägen 12
>Box 525, 169 29 Solna
>Office +46 8 5270 2000
>Office direct +46 8 5270 5038
>Mobile +46 70 848 5038
>Email loa.andersson@utfors.se
>WWW www.utfors.se
>
>