On Tue, Mar 4, 2008 at 8:24 PM, Brian Dickson <[EMAIL PROTECTED]> wrote: > William Herrin wrote: > > On Tue, Mar 4, 2008 at 7:08 PM, Brian Dickson <[EMAIL PROTECTED]> wrote:
> >> It's the other way around that matters - your packets being tunneled, > >> means you don't get to see things like: > >> - ICMP unreachables concerning the outer header destination > >> - ICMP MTU exceeded concerning the outer header > >> - ICMP TTL exceeded concerning the outer header > > How is this handled in today's MPLS networks? It seems like they > > should have essentially the same problem: the packet faults at a node > > which doesn't know how to interpret the contents of a packet with the > > given label. > MPLS is, generally, a strictly internal mechansim. While there may be > inter-provider MPLS, I'm not aware > of any significant deployments. > > Which means, any problem can be identified as being entirely one ISP's > problem. > > Plus, there are knobs on MPLS configurations, that allow you to "expose" > the hops, by decrementing IP TTL as it goes. > > It gives a limited ability to traceroute, at least, when that is enabled. Hi Brian, Interesting. If you don't mind, I will restate that answer: 1. MPLS includes hacks which cause network analysis tools to behave as expected most of the time. 2. Even when you hit a corner case where the tools don't work right with MPLS, it's still possible for an end-user using only end-user tools to determine which AS has dropped the ball. This strikes me as a reasonable minimum standard for the support our various approaches to the routing problem have to provide for network analysis tools. What do you think? Regards, Bill Herrin -- William D. Herrin [EMAIL PROTECTED] [EMAIL PROTECTED] 3005 Crane Dr. Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004 -- to unsubscribe send a message to [EMAIL PROTECTED] with the word 'unsubscribe' in a single line as the message text body. archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg
