Hey Patrick, > On Fri, Mar 6, 2009 at 6:24 PM, David Meyer <[email protected]> wrote: > >> The ISP would still have in their RIB > >> all prefixes attached to the SP's network and the RIB also need to > >> carry all global RLOC identifiers. But overall the growth of the > >> entries in the routers' RIB and FIB would be reduced for each AS. > >> When a client resolves a destination and found out the destination IP > >> address it is forwarded to the network, if the destination is not > >> found in the RIB/FIB it is forwarded to the closest ITR upon the > >> default route. The ITR make a lookup from the MS and once the RLOC is > >> found the packets are encapsulated and forwarded to the ETR. The ETR > >> updates its cache on the information in the packet. Most likely the > >> ETR has to inform the adjacent MS that it is dealing with this new EID > >> entry. > > > > I'm not sure I understand. The map-server connects to the > > ALT, which of course has a RIB, but it seems you're > > talking about the DFZ RIB (RLOCs and all). Which one are > > you talking about? > > I got a little bit carried away here... > I had my first architecture (that haven't been published) in mind > which is close with the MS -except that instead of a MS I had a DNS > server. It got complicated and after some discussions I decided to go > after the host stack instead.
Ok, gotcha, thnx.
> So I'll try to explain what I have in mind. If you have a B-RAS with a
> very good IP-subnetting plan in place you will have only one IP subnet
> on the B-RAS. So applying ITR/ETR on that B-RAS will not reduce the
> size of the DFZ - we are mapping a subnet/RLOC 1-to-1. Also if you
> have very good aggregation in place LISP will not help that much.
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?
> So I thought that the RLOC should be connected to the AS (or actually
> an area) somehow, let say you assign a block /23 to an AS (or
> geographical area) and the ISP are taking its RLOC identifiers from
> that block for its ITR/ETR. The ITR/ETR are located in the ISP network
> but not necessary at the edge routers - if you have ITR/ETR on the
> edge routers you need a lot of IP addresses and you need to replace a
> lot of hardware (costs have to be covered somehow). Instead you place
> them on strategic places in the network so you can have several edge
> routers behind one ITR/ETR.
Sure, you could do it that way.
> 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.
> 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 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.
> Also much can be improved by going after the hosts, e.g. mobility and
> UDT features can be interesting for the enterprises and a good reason
> to upgrade.
Sure, I agree that lots can be done in the hosts.
dAVE
signature.asc
Description: Digital signature
_______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
