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

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

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. 

I understand that there are two options, and that they are different.
But it still has to be the case that whatever my site decides to do the end result has to be better than simply pushing the information via BGP, 

Pushing what information to BGP? I'm not following you.
otherwise it won't get done. I think the PTR approach is the potentially 
more attractive approach. However, for me to rely on that there has to
be someone who deploys a PTR. Who do they deploy it? (I think there are 
good answers to this; I'm asking you to document those.)
If a LISP sites wants non-LISP sites to connect to it, which they will, they will figure out how to deploy a PTR. So you, the non-LISP site doesn't have to care. 


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.


This is a motivation from the point of view of the Internet, not a
motivation for me as an business person to buy a new box that serves
some other people.
You don't buy it just because it *only serves* another person. You, as a site, want LISP so you can get portable EID prefixes and that you can do multihoming cheaper and get ingress TE on your links.
As I said above, I think there are reasons for doing this. For instance, 
I could imagine a business where I'm selling PTR connectivity to LISP
sites. However, this appears to work only if I can choose the LISP sites that I'm serving. This seems to imply that I can only advertise part of the identifier space with anycast. I'm wondering how that's better than 
advertising PI space... but maybe your responses below on aggregation
will shed some light on this.
That is not the way it should work, or else you'll have EIDs for each island of support. 

Is your point that there is no motivation for anyone to deploy a PTR?
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.


I'm sorry, but I don't understand why you believe the EIDs are
aggregatable. Sure, we can choose a /4 which holds the EID space. But
the question is whether a PTR can advertise all of this, or if due to
business reasons you want to be able to switch between PTR providers. If 
this is needed, I don't see how you can aggregate EID space.
Not just one PTR. A bunch of them will advertise it for compatibility sake. But if I had to choose I would error on using NAT as the solution because I don't want any additional infrastructure if I can avoid it.
We put PTRs in there to allow a solution that doesn't use NAT. Possibly for IPv6 which could be NAT-free.
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.
I did read it earlier, and I liked the MTU handling. However, you still need to deal with path MTU on the legacy-to-LISP path with PTRs, and as
Could you explain this better please. References don't do me any good. I want to know exactly what you are talking about before I speculate a reply.
I explained above, you have to assume one of the following for this to work: 

1) support for the new ICMP-less path MTU RFC in the legacy site.
2) that ICMP is not blocked in the legacy site or on the path to it
3) that path between PTR and LISP site has MTU > 1500 bytes.


Well, can't you tell from the spec we believe in 3)?
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?


Not one router, but through the set of all PTRs in the world.


Right, so you answered your own question.


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 sounds reasonable, but I'm not sure I fully understand how this
works -- maybe we need to resolve the aggregation question first before 
we can talk about this. If you can aggregate EID space in the PTRs, I
think this will work.


Here's the scenario:

1) Start out deploying 100 PTRs for IPv6.
2) They each advertise an IANA-assigned global IPv6 EID block of 0240::/16. 
3) As more LISP sites come on, you add more PTRs.
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.


So, the PTRs have different IP addresses, but all advertise at least
partially overlapping EID space? Ok, the PTRs do not act as anycast end 

I didn't say that. See scenario above.


points. Still, in the routing system the same EID space is advertised
from multiple locations. I suspect the properties of this are similar to 
anycast.
People confuse this a lot. Anycast is how you assign addresses to boxes. Advertising the same prefix from multiple spots is multi-path routing. 

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