[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RRG] Map-encap space for "server" vs. "client" end-users?



On Tue, Mar 4, 2008 at 8:24 PM, Brian Dickson <briand@ca.afilias.info> wrote:
> William Herrin wrote:
>  > On Tue, Mar 4, 2008 at 7:08 PM, Brian Dickson <briand@ca.afilias.info> 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                  herrin@dirtside.com  bill@herrin.us
3005 Crane Dr.                        Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004

--
to unsubscribe send a message to rrg-request@psg.com 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