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

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