Xiaoming,
Thanks for the thorough review. A new version of the draft is available at
http://www.bonica.org/docs/draft-ietf-ccamp-tracereq-04.txt.
Ron
-----Original Message-----
From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On
Behalf Of Xiaoming Fu
Sent: Friday, May 30, 2003 7:20 PM
To: Ron Bonica
Cc: ccamp@ops.ietf.org
Subject: Re: draft-ietf-ccamp-tracereq
Ron,
It is a nice document. I went it through and have a few comments:
- Section 3, 9) - "forwarding plane failu res" ==> _failures_
Oops....
- I didn't understand why the following paragraph appears twice - the
same in Section 3, 13) and 14). I assume you're talking about control
plane failure in 13).
Justification: MTU information is sometimes useful in identifying
the root cause of forwarding plane failures.
You have a point. MTU information, in either direction, can be useful in
debugging
both control and forwarding plane failures. The paragraph should read as
follows in
both 3.13 and 3.14:
Justification: MTU information is sometimes useful in identifying
the root cause of forwarding and control plane failures.
- Again, Section 3, 14):
14) When tracing through the forwarding plane, display the MTU
associated with each hop in the reverse direction.
Meanwhile, in Section 4.3:
The protocol must be stateless. That is, nodes should not have to
maintain state between successive traceroute messages.
Are you assuming the probe and response messages are always hop-by-hop
addressed? Otherwise, the forwarding and reverse paths of transporting
the probe & response pair could differ, e.g., due to the Internet
routing, or policies. And -
Do we need a same transport path for them? If so, how a stateless
traceroute protocol knows the reverse path to forward the response
message? Probably we could create a temporary state while handling a
probe message, to include P_HOP & Interface information like in RSVP,
although the state is used only once in this case.
Requirements 13 and 14 are ambiguous. As a result, you have interpretted
them
in a manner that was not intended. They should be restated as follows:
13) When tracing through the control plane, display the MTU associated with
interface
that forwards datagrams through the traced path.
14) When tracing through the forwarding plane, display the MTU associated
with each
interface that receives datagtrams along the traced path.
- Section 4.1 - I don't understand the following sentense:
Many network forward datagrams that specify
IP options differently than they would forward datagrams that do not
specify IP options.
Maybe they ==> them, but the implication of this sentense is still
unclear to me.
This paragraph should read as follows:
Many networks forward datagrams that specify IP options differently than
they would forward datagrams that do not specify IP options. Therefore,
the introductions of IP options would cause the application to trace a
forwarding path other than the path that its user intended to trace.
- Section 4.2 "IP was _disqualified_ in order to conserve protocol
identifiers." - I'm not sure this is always valid. Anyway,
using UDP would have also to request a port number from IANA; there
is actually a tradeoff among protocol_ID v.s. port number v.s. ICMP
type. BTW, UDP may introduce a little (although minor)
additional overhead.
IANA is much more willing to assign UDP port numbers than protocol-IDs.
This is because there are so many more UDP port numbers available.
- In general I would expect the document would not constrain too much
on protocol details - the latter looks to me more of a protocol
design issue, instead of an informational RFC on "requirement".
In principle, I agree. Section 4 provides just enough protocol requirements
to keep protocol designers away from some known bad design approaches. For
example,
years ago we tried returning MPLS information in ICMP datagrams. This wasn't
well received. So, the requirements document guides us around that bad
approach.
- It looks better if an experimental traceroute protocol (RFC1393 -
traceroute using an IP option) would be referenced and shortly
introduced in Section 2 (e.g., MTU determination).
I thought about referencing RFC 1393 but decided not to because it is not
widely known or implemented.
Ron
My 2 cents.
Xiaoming
Ron Bonica wrote:
Folks,
At the request of the IESG, I have updated draft-ietf-ccamp-tracereq and
sent a new copy to the draft editor. Until the draft editor
posts it, a copy
can be found at
http://www.bonica.org/docs/draft-ietf-ccamp-tracereq-03.txt.
Please take a look, as this draft will need to go through another WG last
call.
===========================================
Ronald P. Bonica Ph: 703 886 1681
vBNS Engineering page: 1 888 268 8021
Ashburn, Va.
===========================================
"We are not on Earth to guard a museum, but
to cultivate a flourishing garden of life."
-- Angelo Giuseppe Roncalli