Re: draft-ietf-ccamp-tracereq

[Xiaoming Fu <[e-mail]>]

Ron,

It is a nice document. I went it through and have a few comments:

- Section 3, 9) - "forwarding plane failu res" ==> _failures_

- 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.

- 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.

- 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.

- 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.

- 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".

- 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).

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