Re: draft-ietf-ccamp-tracereq

[Xiaoming Fu <[e-mail]>]

Ron,

Thanks for your new version. One more issue:

Current available transport mechanisms for traceroute include ICMP, UDP, 
and TCP. UDP may relief DoS issues, but NAT/firewall might be another 
issue (although we could have STUN). TCP has an issue of connection 
setup latency, however it could be potentially considered (it may also 
have a number of available ports?). To my knowledge, circulations from 
one protocol to protocol are sometimes helpful, for example, SIP 
initially used UDP, while TCP was recently proposed.

Hence, I would suggest a "SHOULD" instead of "MUST" in Section 4.2.

Cheers,
Xiaoming

Ron Bonica wrote:
> 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
>>
>>