[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: draft-bonica-tunneltrace-02
Dave,
if you change "appeared in" to "is within the scope of" I agree.
/Loa
David Allan wrote:
> Loa:
>
> I thought the first criteria (somthing we should do) was met when
> somthing appeared in a WG charter and milestones ;-).
>
> As for the second, I'll agree to disagree. I've provided my suggestions
> as to changes that should be made before IMO the document is a good
> enough starting point. Others should offer their opinions.
>
> cheers
> Dave
>
> > -----Original Message-----
> > From: Loa Andersson [mailto:loa.andersson@utfors.se]
> > Sent: Wednesday, February 20, 2002 11:31 AM
> > To: Allan, David [CAR:NS00:EXCH]
> > 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
> >
> >
> >
>
--
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