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

[Dino Farinacci <dino@cisco.com>]

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

You are right Steve, but since legacy sites and routers can route to  
the "EID", that was my definition of routable. You are defining it to  
be routable from the the LISP site, which you are right, they are not.

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

It is really simple:

1) When ITR determines destination site is not in the mapping  
database, it will not encapsulate and will translate the source  
address for egress packets.
2) An ETR will translate the destination address for ingress packets  
when they are not encapsulated.

That's it!

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

Right, just want to say we have some flexibility if the sensitivity is  
for ISP filtering.

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

Right, that is indeed what we are doing.

Dino

> 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