Subject: [Int-area] [Fwd: I-D ACTION:draft-shen-icmp-routing-inst-00.txt]

From: Naiming Shen <[email-masked]>
Date: Mon, 13 Nov 2006 17:46:37 -0800

Hi Int-area group,

please review the draft-shen-icmp-routing-inst-00.txt
just submitted, and send any comment you may have.

thanks.
- Naiming

-------- Original Message --------
Subject: I-D ACTION:draft-shen-icmp-routing-inst-00.txt
Date: Mon, 13 Nov 2006 18:50:01 -0500
From: [email-masked]
Reply-To: [email-masked]
To: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title		: ICMP Extensions for Routing Instances
	Author(s)	: N. Shen, E. Chen
	Filename	: draft-shen-icmp-routing-inst-00.txt
	Pages		: 7
	Date		: 2006-11-13
	
    This document specifies the extensions to ICMP that allows
    routing instance information to be included inside the ICMP
    packet. These extensions can be used to facilitate the
    troubleshooting network problems within a routing domain or
    across multiple routing domains.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-shen-icmp-routing-inst-00.txt

To remove yourself from the I-D Announcement list, send a message to
[email-masked] with the word unsubscribe in the body of
the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the
username "anonymous" and a password of your e-mail address. After
logging in, type "cd internet-drafts" and then
"get draft-shen-icmp-routing-inst-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-shen-icmp-routing-inst-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/i-d-announce

_______________________________________________
Int-area mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/int-area

---

From: Thomas Narten <[email-masked]>
Date: Tue, 14 Nov 2006 13:54:31 -0500

> just submitted, and send any comment you may have.

What scope are these extensions intended to cover? Are they restricted
to being included only in ICMP Time Exceeded messages?

The intention seems to be to supplement the info available for
traceroute. But, traceroute sends UDP messages to an arbitrary
port. I.e., there is no one distinctive "traceroute" messages. Thus,
all time exceeded ICMP messages would presumably include these
extensions. (Or maybe just for UDP messages?)

Not sure I really like augmenting ICMP with more stuff only to benefit
a narrow purpose (e.g., traceroute). Slippery slope here. Where do we
draw the line between what is OK and what is not?

And the specific extensions are of little value to most users. i.e.;

   The router MAY include the AS number [3] when sending out the
   ICMP messages.

...

   The router MAY include the Multi-Topology ID [4, 5] when sending
   out the ICMP messages.

...

   The router MAY include the Area ID for OSPF [6] when sending
   out the ICMP messages.

...

   The router MAY include the IS-IS level [7] when sending out the
   ICMP messages.

...

   The router MAY include the IGRP AS ID or EIGRP AS Number when sending
   out the ICMP messages.

...
         
   The router MAY include the virtual router identifier of VRRP [9]
   when sending out the ICMP messages.

Thomas

---

From: Thomas Narten <[email-masked]>
Date: Tue, 14 Nov 2006 14:27:44 -0500

Enke Chen <[email-masked]> writes:

> I am curious how you concluded that "the specific extensions are of 
> little value to most users".

They are of value only to users invoking traceroute, and have some
level of clue. I don't doubt ISPs would find ASN info useful. I, as an
end user, at home, doubt this has any value to me.

But I was referring more that the vast majority of these ICMP messages
will be sent as part of non-traceroute traffic, and thus go places
that don't need the information and can't use it. (Will the also be
included in time exceeded messages associated with TCP?)

As long as it can be demonstrated that including such information
causes no harm, I suppose it's not a big deal.

But I do worry about at what point we say "no" to inserting
information into ICMP that has only limited value.

Thomas

---

From: Naiming Shen <[email-masked]>
Date: Tue, 14 Nov 2006 11:42:02 -0800

Thomas,

> included in time exceeded messages associated with TCP?)

This is a good point. Those objects are optional, but from implementation
angle, it mostly should apply to UDP packets above certain ports.

thanks.
- Naiming

---

From: Enke Chen <[email-masked]>
Date: Tue, 14 Nov 2006 11:23:22 -0800

In the last ten years or longer, customers/providers had to bend 
backward in order to obtain the AS number in debugging network 
problems.  That's why some vendors query the routing table and then 
display the AS number in traceroute. But that information is accurate 
only when the full routes are carried.

Both Naiming and I used to work for a large provider. The need for the 
AS number in the tracereoute is compelling.   Clearly not all extensions 
are equal, and some are more useful than others.

-- Enke