I read this draft a couple of weeks ago and had a few 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!
> 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 LISP-encapsulate, you must be performing some kind of NAT translation to the transit address space, right? You describe that later in the document, but the above text excerpt does not recognize that you have to do more than just send packets... 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 Comment on Section 5: The document should talk about what is the motivation for deploying PTRs. Comment on Section 5: I don't understand how we distinguish advertising the EIDs vs. larger prefixes. Given the non-aggregability of EIDs, can you even have larger ones, other than "all EIDs"? The business implications seem severe, because you cannot have contracts for specific service. 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 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. 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 anycast routing properties in this situation. For instance, do we expect 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... 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 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. In any case, I'd like to see some discussion of this draft and the above topics in the meeting! Jari -- to unsubscribe send a message to [EMAIL PROTECTED] 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
