Re: [Int-area] I-D Action: draft-shen-traceroute-ping-ext-03.txt

Hi Ron,

the traceroute can use either udp/tcp or icmp for transport, e.g. microsoft's 'tracer' uses icmp
for the transport actually.

thanks.
- Naiming

On Jan 5, 2012, at 1:14 PM, Ronald Bonica wrote:

> Carlos,
> 
> Regardless whether the ICMP header is being updated, I don't think that it is necessary to enhance PING. Ping tells you that a host is reachable. SNMP can tell you anything else that you need to know about the host.
> 
>                                                    Ron
> 
> 
> 
>> -----Original Message-----
>> From: Carlos Pignataro [mailto:cpignata@cisco.com]
>> Sent: Wednesday, January 04, 2012 3:30 PM
>> To: Ronald Bonica
>> Cc: int-area@ietf.org
>> Subject: Re: [Int-area] I-D Action: draft-shen-traceroute-ping-ext-
>> 03.txt
>> 
>> Hi Ron,
>> 
>> Thanks for the comments, please see inline.
>> 
>> On 1/4/2012 2:01 PM, Ronald Bonica wrote:
>>> Authors,
>>> 
>>> This draft changes the meaning of bits in the ICMP, TCP and UDP
>> headers. Therefore, if published, it would UPDATE RFCs 792, 793 and
>> 768. You may find that a very high bar to clear!
>>> 
>> 
>> This draft is not really changing the meaning of bits in the ICMP, TCP,
>> and UDP headers. This draft is just describing a way to allocate udp
>> and
>> tcp source port and icmp identifier. And described within the context
>> of
>> the application of this I-D, traceroute. Do you agree?
>> 
>>> In order to lower the bar, I recommend the following changes to your
>> draft:
>>> 
>>> 1) Don't attempt to enhance PING. Therefore, you won't need to
>> redefine any bits in the ICMP header.
>> 
>> This is what draft-shen-udp-traceroute-ext (a predecessor) was doing to
>> some extent. The extension to ICMP (and TCP) came as a consequence to
>> feedback (IIRC) on including ICMP- and TCP-based traceroutes.
>> 
>> Based on the response above, if this is not redefining bits, do you
>> have
>> the same suggestion?
>> 
>>> 2) Encode the Trace Extension structure at a fixed position in the
>> TCP/UDP payload. Therefore, you won't need to redefine any bits in the
>> TCP or UDP headers.
>>> 
>> 
>> This is also good, and I'd be glad to go this route if this is
>> consensus. One reason to include the pointer to a variable start is
>> that
>> during RFC 4884, the structure was at a fixed start and there was
>> strong
>> consensus to have it variable and explicit.
>> 
>>> There isn't any reason to enhance PING. If you want information from
>> a host beyond that which PING already provides, the appropriate
>> protocol is SNMP.
>>> 
>>> The document doesn't explain why the starting position of the Trace
>> Extension Structure needs to be variable. Possibilities are:
>>> 
>>> 1) To reduce the probability of processing errors caused by magic
>> numbers that sometimes occur in non-traceroute packets with TTL equal
>> to 0
>>> 2) To preserve the low order bits of the TCP/UDP payload
>>> 
>>> If you are trying to address problem #1, you can do so by increasing
>> the size of the magic number.
>>> 
>>> If you are trying to address problem #2, you can do so by encoding
>> the extension structure at some reasonably large but fixed location in
>> the TCP/UDP payload.
>>> 
>> 
>> Problem #2. And same as above: I think that a fixed reasonably large
>> location would work as well, though it might imply more checks.
>> 
>> Thanks,
>> 
>> -- Carlos.
>> 
>>> 
>>> --------------------------
>>> Ron Bonica
>>> vcard:       www.bonica.org/ron/ronbonica.vcf
>>> 
>>> 
>>> _______________________________________________
>>> Int-area mailing list
>>> Int-area@ietf.org
>>> https://www.ietf.org/mailman/listinfo/int-area
>>> 
>>> 
> _______________________________________________
> Int-area mailing list
> Int-area@ietf.org
> https://www.ietf.org/mailman/listinfo/int-area