[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RRG] Map-encap space for "server" vs. "client" end-users?
On 2/21/08 2:20 PM, Brian Dickson allegedly wrote:
For an ITR/ETR model, the benefit of the multihomed entity is only
realized when the *clients* connecting to them have an ITR.
See draft-lewis-lisp-interworking for the concept of a proxy tunnel
router. PTRs can be close to sources or close to destinations, for
different purposes.
On 2/21/08 5:57 PM, Brian Dickson allegedly wrote:
Actually, I was referring to the ITR/ETR model. The ITR bears a large
burden of the operation costs, scaling, performance, etc, while the
benefit goes to the "other" guy at the ETR end - the multi-homed guy.
True, but compare to the costs today. Today every BGP router must
propagate and maintain every prefix announcement, big and small, whether
they ever use it or not. With an ITR/ETR model the only routers that
get prefix mappings are the ones that actually want to use them. So an
ITR bears a burden that benefits an ETR, but only if the ITR wants to
talk to the ETR.
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.
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