Re: draft-ietf-ccamp-tracereq

[Xiaoming Fu <fu@cs.uni-goettingen.de>]

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.+49-551-39 14411, Fax.+49-551-39 14403
http://www.ifi.informatik.uni-goettingen.de