[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