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

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