RE: draft-ietf-ccamp-tracereq

[Ron Bonica <[e-mail]>]

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: [e-mail] [mailto:[e-mail]]On
> Behalf Of Xiaoming Fu
> Sent: Friday, May 30, 2003 7:20 PM
> To: Ron Bonica
> Cc: [e-mail]
> 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
>
>

--
Xiaoming Fu
University of Goettingen, Telematics Group
Lotzestr. 16-18, 37083 Goettingen, Germany
Tel.[phone], Fax.[phone]
http://www.ifi.informatik.uni-goettingen.de