Re: [RRG] Comments on draft-lewis-lisp-interworking

[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.

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.

> ISP-provided ITR to reach other LISP sites; all of those cases give  
> you uRPF
> or filtering problems.  Packets will only have a source address in  
> the RLOC
> prefix if they've been encapsulated by a customer ITR for  
> transmission to
> another LISP site -- and we must assume that will be rare, at least
> initially.

Or translated into an RLOC.

> 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.

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.

Dino

--
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