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

Hi Ron

Please see my comments in-line below

-----Original Message-----
From: int-area-bounces@ietf.org [mailto:int-area-bounces@ietf.org] On
Behalf Of Ronald Bonica
Sent: Thursday, January 05, 2012 1:15 PM
To: Carlos Pignataro (cpignata)
Cc: int-area@ietf.org
Subject: 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
[TISSA]

What you indicated above may be true in general sense, however, with
various overlay technologies and virtualizations and use of ECMP in
networks require us to have ability to obtain additional information
that may not be possible or straightforward using SNMP.

Case in point is MPLS ping, we use MPLS ping to obtain label stack
information. Or derive various ECMP paths combinations.

In IP world similar information can be very useful. As an example in an
ECMP environments, it is very useful to identify upstream path that a
packet arrived. 

Currently there is no way ICMP ping can communicate this information nor
SNMP can tell that.

Extension proposed in this draft, in my opinion, allow to extend ICMP
echo messages in a manner that is backward compatible yet allow flexible
framework to extend to overlay networks and ECMP enviorements. 

Thanks
Tissa

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