[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RRG] Comments on draft-lewis-lisp-interworking
Thus spake "Dino Farinacci" <dino@cisco.com>
Thus spake "Dino Farinacci" <dino@cisco.com>
It's unfortunate that it wouldn't change, because the provider would
need to know about both the PA allocation and the EID assignment.
Effectively, it's double the hassle factor.
The provider doesn't have to know about EID-prefixes. It can filter
and uRPF on the locator address that is part of it's own block.
Packets coming out of a LISP site will have a source address in the EID
prefix if they're headed to a non-LISP site or depending on a
PTR or
Well that depends:
1) If the source address is indeed an EID, and you want your packets to
return from a non-LISP site, then they are routable and hence can be
filtered or uRPF'ed against.
If you assume the existence of PTRs, your EIDs do not need to be "routable"
in the normal sense. There will be a route for them, yes, but it'll be an
aggregate pointing at a PTR, not the customer. Strict uRPF would fail
without a static route.
2) If the source address is out of EID space, but the ITR is doing
LISP-NAT, then again you have a routable address you can filter and uRPF
against.
I'm still trying to wrap my brain around LISP-NAT.
Tony is correct; the ISP now has to maintain routes (for uRPF) or
filters for two prefixes per customer instead of one. OTOH, that is
a cost paid in one place, while the benefit of LISP accrues to
every BGP router with a full table. That seems like a reasonable
trade-off...
No, I disagree. It has to keep a single set of filters, and that is based
on the source address leaving the site. That can be the 1) source host's
address, 2) the ITR's RLOC addres, or 3) a translated address. In all
cases, they are out of the attached provider block.
In at least some of the proposals we're discussing, packet may leave the
site with either an EID (PI) or RLOC (PA) as the source address. That means
the filter for the customer must include both.
There is no choice here, we have to do this. And if we don't accept it,
nothing will come close to getting deployed. So we have to try to make it
work as simplest as we can.
I did say I thought it was a reasonable trade-off. I just wanted to point
out we're shifting/reducing some costs, not eliminating them. I actually
_like_ moving the costs closer to the customer who gets the benefit.
S
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSS dice at every possible opportunity." --Stephen Hawking
--
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