[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



I read this draft a couple of weeks ago and had a few comments.
Thanks for reading the draft and sending comments.

First of all, as I have stated before, having this document has been a
big improvement. We need to talk about the way legacy and new networks
communicate, we need to talk about the incentives and deployment
scenarios. Thanks for writing it!
Yes, a big improvement over having nothing, sure.  ;-)

In case 3 (LISP site to Non-LISP site), a LISP site can send packets
  to a non-LISP site because the non-LISP site prefixes are routable.
  The non-LISP site need not do anything new to receive packets.  The
only action the LISP site needs to take is to know when not to LISP-
  encapsulate packets.
Hmm. But aren't there other things involved, too? If you do not
Like what?

LISP-encapsulate, you must be performing some kind of NAT translation to
No, not in this case. We break out the case when the non-LISP site  
wants to send packets to the LISP site into 2 sub-cases, if the LISP  
site has routable addresses and when it does not.
And of course when it doesn't have routable addresses, you have to  
NAT, you have no choice. Just like your home network does.
Observation on Section 4.3: limiting the impact of routable EIDs is not
enough, we have to create an incentive to do so. Since we cannot block
people from advertising things in BGP, pretty much the only remaining
option is to make some other approach more desirable: better, cheaper,
faster, etc. Can you say something about what
That is what the PTR option is for. It's simply a question of having  
this control locally at the site (the NAT solution) or having the  
infrastructure help (the PTR solution). They both have their downsides.
Comment on Section 5: The document should talk about what is the
motivation for deploying PTRs.
Will add to it, but you probably guess the motivation is so you can  
pull PI addresses out of the core as soon as possible without using  
NATs on the edges.
Comment on Section 5: I don't understand how we distinguish advertising
the EIDs vs. larger prefixes. Given the non-aggregability of EIDs, can
Don't assume EIDs are not aggregatable, they could be very much  
aggregatable in IPv6 down to a /16. In IPv4, we'll have to use a few  
prefixes, hopefully just 10 or so and not in the 100s and definitely  
won't deploy it if in the 1000s. But many think this is still a very  
small price to pay (in the 1000s) to be able to suppress more specific  
PA advertisements of PI advertisements from the 10^6 multi-homed sites  
we expect to come.
you even have larger ones, other than "all EIDs"? The business
implications seem severe, because you cannot have contracts for specific
service.
Well, maybe a business opportunity too!

Section 5.2: it seems that the MTU implications of PTRs are different
from pure LISP. In pure LISP, you have the ability to locally configure
Please don't differentiate a PTR from a pure LISP. A PTR is a router  
that does ITR functionality but does not do ETR functionality because  
the packet has a direct-site return path.
your network with an MTU that fits in 1500 bytes even if a LISP header
is added to it. With PTRs, the encapsulation is happening without the
knowledge of the legacy endsite. This means that either we must require
the legacy endsites (and paths to them) to be able to deal with PMTU
discovery or the PTR - LISP site tunneling mechanisms need to be able to carry 1500 byte payload packets. Some discussion of this might be useful
in the document.
See draft-farinacci-lisp-06.txt for resolving MTU issues.

Section 5.3, scaling. It seems that we hit the worst point when 50% of
the Internet is LISP capable and 50% not. Assuming equal traffic
distribution, 25% of traffic in the Internet would have to go through a
PTR, right? It would be interesting to see some discussion of the
How do you think 25% of all traffic today will go through one router?  
Well, it doesn't happen so LISP can't help create more switching  
capacity. You build out many of them. And deployment experience will  
tell us if the "interworking tunnels" should have large diameter (PTRs  
deployed closer to non-LISP sites) or smaller diameter (PTRs deployed  
closer to LISP-sites).
This will also depend on if PA address are also used as EIDs. Because  
you'll have an overlap situation between these two namespaces.
This is why 240.0.0.0/4 has value. You could use it strictly for  
additional addresses for the locator namespace or use it the EID  
namespace. The former is easier to deploy because it would be required  
in a smaller set of product platforms. But the later is more  
beneficial for PTR aggregation performance but will require host  
platform changes too.
anycast routing properties in this situation. For instance, do we expect
PTRs might look like they use anycast addressing since other proposals  
refer to it as such. But it's not using anycast addressing. That is  
the PTR routers do not have the same IP address assigned to each of  
them. They simply advertise the same EID-prefixes making the non-LISP  
sites think there are multiple paths to the EID. This way, you  
distribute load by having sources send to the closest PTR which will  
encapsulate to the LISP site.
that only "all EIDs" can be advertised? If so, how stable can we expect
the anycast routing to stay? Can we expect sudden switching to other
PTRs, which with these traffic amounts would obviously be a pretty
significant event? I'm sure we have some data on this from DNS anycast
already...
I am not following you, how would switching to other PTRs help the  
"all EIDs cannot be advertised" question.
Section 7, security considerations. There is the obvious vulnerability
that you can advertise someone else's EID space as a PTR, and you get to
Someone elses? They all advertise the entire space if we can pull it  
off. And if SoBGP is up and running, we can say what AS origins can  
advertise the EID-prefixes.
see their traffic. But the interesting question is if this is any
different from you doing the same thing in regular BGP. I think there is
one difference -- in BGP you are limited with what you can do for the
attacker - victim site path, because you need to simultaneously attract
the victim's packets to you but also be able to forward them to the
victim after taking a peek into them. With LISP encapsulation, this is
not an issue and you can do it from any location.
I think it's the same, in both cases you build a secure infrastructure  
or you do ingress filtering the best you can.
In any case, I'd like to see some discussion of this draft and the above
topics in the meeting!
Sure, when or if we get a time slot.

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