On 3/4/08 4:08 PM, Brian Dickson allegedly wrote:
Scott Brim wrote:As soon as the packets are tunneled, you lose visibility on what is happening. And if you aren't the guy doing the tunneling, you *really* lose visibility, and in turn, accountability, the ability to localize and diagnose problems, and generally you are left twisting in the wind if anything goes wrong. Which it will. But, unlike, say, VPNs, this isn't a localized set of sites, in a closed community. This is the whole Internet, getting to your site.We're talking about encapsulation across the DFZ. Why would I want a core ISP to examine bodies of my packets? What is the problem with "losing visibility"? None of an intermediate ISP's operational responsibilities involve looking inside beyond the outer IP header.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 If you operate the xTR, you have some ability to do diagnostics. If not, you are relying on the xTR operator. And, when this is affecting inbound traffic, isolating common fault points becomes a big N^2 issue, where N is no longer aggregated... Brian Dickson (Not a big fan of operating networks using GRE, MPLS, or ATM, but have done so.)
and On 3/4/08 5:24 PM, Brian Dickson allegedly wrote: > MPLS is, generally, a strictly internal mechansim. While there may > be inter-provider MPLS, I'm not aware of any significant > deployments. It seems that the problem is that there's an encapsulation which covers multiple DFZ SPs and which no one in particular has responsibility for. I think you might be looking at this like it's a tunnel, like ATM or other "layer networks" (G.805). Map-and-encap isn't a tunnel, it's just an encapsulation. It has no initial state synchronization between ITR/ETR, no setup phase. Anyone can throw packets at an ETR without preamble. So there is no separate "tunnel" entity for anyone to have responsibility for. Responsibility for packet delivery across the DFZ from ITR to ETR is the same as it is today, since packets to the ETR are just packets, with IP headers on them. Propagating TTL expired for encapsulated packets is an interesting thought. I'll have to learn more about what other protocols do. swb -- 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