Hi Dave, as per request, I suggest we continue on the lisp-list, if further discussions are needed. Comments inline
On Mon, Mar 9, 2009 at 5:08 PM, David Meyer <[email protected]> wrote: > Right now, right? Since its a BRAS I'm assuming what's > behind it is dynamically addressed (and readdressed at > some regular interval). Right? If so, then the things > behind the BRAS might someday be (naturally) renumber > into some EID space, the the BRAS could play xTR (and > hence have a few RLOCs). > > Or do you see it differently? Not much but little. When you design the B-RAS you usually reserve as much IP-addresses as needed for the residential users but after a while this goes broken when a connection that needs static IP-addresses for, e.g. IPsec connectivity - usually a SME subscribing for a xDSL line. This can be avoided if you have separate residential and enterprise B-RAS but guess this is not common. So you are right, after a while there will be more prefixes on the B-RAS. But most of them are PA addresses and aggregated further up in the network. And having ITR/ETR on the B-RAS might break the aggregate - this is a design and not a technology issue. . > >> And to the ALT network you just advertise on prefix, the /23 and not >> the individual RLOC host prefixes. This becomes a sort of super >> aggregate, the AS or an area is shown behind one /23 RLOC prefix. > > You lost me (you don't advertise RLOCs into the ALT). > >> LISP-ALT will be the global directory, which IP prefix is connected to >> which RLOC identifier for time being and this directory will grow but >> it is disconnected from the forwarding plane so the FIB doesn't need >> to be upgraded - only in the AS that grows too big. But that is then >> up to the service provider, split the AS to two AS or buy new hardware >> - the ISP have a choice. > > Again, I think we're mangling a few things here. There > are no RLOCs in the ALT. I was lost here until Dino's reply yesterday. I now understand that there are no RLOCs in the ALT network, it is like a SIP architecture where you (might) have a separate path to setup the session and the RTP streams take another path. Or the old Ipsilon solution where the routers (in LISP, the ALT) were bypassed and a flow was created through the ATM network (in LISP, the current Internet). But LISP + ALT scales better since no signaling and path reservation is needed in the core, only on the affected edges. I hope I got it right now, please correct me if I'm wrong. > >> One question for you, how are you going to deal with portsweep on the ITR? >> I have seen ISP using NAT on the B-RAS (along time ago), an end user >> could easily saturate the NAT table so that all customer behind that >> B-RAS lost connectivity. > > What is portsweep? Do you mean scanning? If so, yeah, its > a problem for everyone on the big bad Internet. I think port scanning is when you are trying to find a back door on a certain host, portsweep is when you are scanning for a certain port on multiple hosts. So the portsweep traffic will end up on the ALT network. Then, as with Ipsilon solution, how to deal with the housekeeping of the cache? If a lot of cache entries are created by portsweep is there a risk that the cache entries are exhausted due to portsweep and what then? In the 90s route-cache was replaced by CEF and stabilized the backbone routers - now putting a route-cache solution back in the network gets me uncomfortable. Don't get me wrong here, this is not against LISP - I'm curious if the technology have improved that much that a cache solution could be used closer to the core. There is a reason why I'm asking this, see below. > >> I think we should design LISP and LISP-ALT so that later on the >> functionality can be taken to the hosts, both options are needed so >> that the enterprise and service providers do have a choice. > > I couldn't follow that. Can you try to rephrase it? > Thnx. Forget the previous, this was when I thought that the ALT and MS contains both RLOC and EID information - and this is not the case. If there would have been RLOC information in the MS I would have been keen to get "hands-on" that solution. Why? My proposal requires upgrades to the hosts and being realistic, every host on the Internet will not be upgraded within e.g. two years (backend hosts doesn't need to be upgraded either) so there will be an interim phase where a hIPv4 proxy is needed in front of the legacy hosts. Only way to do this is to apply DNS spoofing and to have a cache in the proxy. This is doable in enterprise environments, you have to install the hIPv4 proxy between the clients and the DNS server. That is, the proxy is on the very edge of the network and if portsweep exhaust the cache it is only the enterprise that suffers, nobody else. But when you have to implement a hIPv4 proxy for residential users the most logical place is to install it on the B-RAS, then it will be located between the clients and the DNS server so DNS spoofing and caching can be applied. Another place would be the DSLAM that should apply/remove the LISP header to the IP header and creating the hIPv4 header in Layer 2 mode. Scales better but a lot of hardware needs to be upgraded... And then we have the 1000$ question, how to deal with the cache housekeeping?? Can a portsweep exhaust the cache and will end users loose connectivity due to portsweep or bad cache housekeeping? That's the reason why I dropped the proxy solution from my draft at this moment and headed for the hosts instead, the network is kept free from cache solutions - have seen enough problems with route-cache and NAT caches in the forwarding plane, the closer to the core the more vulnerable the caches become. But has the technology improved?? -- patte _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
