Hi Xu, You wrote:
>> LISP-ALT routers are deployed in a hierarchy which matches the >> EID prefix allocation hierarchy. LISP-ALT routers at each >> level in the this hierarchy are responsible for aggregating all >> EID prefixes learned from LISP-ALT routers logically "below" >> them and advertising summary prefixes to the LISP-ALT routers >> logically "above" them. > Does LISP-ALT seem like a variation or a simplified instance of > LISP-CONS? Both of them introduce a hierarchical overlay network > which is topology-independent. I think CONS and ALT are driven by a common goal - to build a new network of routers in which aggregation is achieved to a very high degree. On the face of it, this should make the network highly efficient - but this won't be true when the routers are physically scattered all round the world, with their geographic location having little or nothing to do with the prefixes they are handling. It probably should have been clear to me that this was a problem with CONS too. I didn't clearly recognise this because I had too much difficulty understanding how CONS would work anyway. > The difference is: in LISP-CONS, the overlay network is just used > for mapping query and reply. While in LISP-ALT, the overlay can > also be used for forwarding the initial traffic in order to solve > the initial packets loss in ITR when cache missed. Is that > correct? This is one difference, and in principle it is a nifty thing to do with the ALT network - sending the initial traffic packets and using them as mapping requests. This is the same nifty technique APT caching ITRs use with their Default Mapper - but that APT is practical, since the Default Mapper is local, with low delays, low communication costs and high reliability. APT's default mapper tunnels the traffic packet directly to the ETR it chooses, in the usual ITR fashion - whereas ALT is used to deliver the traffic packet to the appropriate ETR via a probably circuitous path over the ALT topology. Another difference is that ALT is made from existing protocols - GRE and BGP. This saves defining new protocols and writing a bunch of new software for each implementation. Another critique of ALT (and I think CONS) is how to secure the way ETRs advertise their EID prefixes. How can any or all of the ALT routers verify that some device, ostensibly the (or one of the) authoritative ETR really is authoritative, right now, for the EID it is advertising? The ETR(s) chosen by the end-user will be changing from time-to-time. I think there needs to be some crypto and a method of verifying these advertisements before traffic packets are sent to the device which advertises these EIDs. That has to have some degree or centralised and/or distributed coordination which I think is not covered by the ALT ID. The security of Ivip's mapping information depends on some crypto protection of the multiple streams of mapping updates (and likewise downloads of the current maps, for ITRD/QSD start-up) and on the Root Update Authorisation Server ensuring it only accepts mapping changes from users via an authenticated method: http://tools.ietf.org/html/draft-whittle-ivip-arch-01#page-60 This makes security a lot easier. It also completely separates the mapping database part of the system from the ETRs, though there is nothing to stop an end-user embedding mapping update functions in their ETR(s), with the required username and password for accessing the Update Authorisation Server system which handles their micronet. >> This is presumably impossible at the edge of the network, since >> the location of ETRs for a given EIDs are scattered around the >> place with little or no correlation with geography. > > ... > >> By mandating the structure of the ALT network be strongly >> driven by address aggregation, this means the connections >> between one router and the next in the hierarchy will have >> little or no relation to geography. Therefore, the average >> length of inter-router distance will be far longer than for >> ordinary BGP routers, where the network structure is based >> primarily on linking to geographic neighbours, and not at all >> on address aggregation. > > If the overlay network is used for traffic forwarding, what you > mentioned is inevitable. My understanding is that the ALT network has 3 or 4 functions: 1 - ITR sends map query. ALT network forwards this to an authoritative query server, which is typically one of the currently active ETRs. 2 - That ETR (or whatever responds to the query) sends the query back through the ALT network. However, this is not required and the ID says it can be sent back directly to the ITR. (The same option was added to CONS, or at least acknowledged as a possibility on the mailing list, after I questioned why the reply had to go back through the CONS network.) 3 - The ITR encapsulates a traffic packet (raising PMTU and fragmentation problems ...) and the ALT network forwards it as for a mapping query. It functions as a mapping query and also, ideally, gets to the ETR - so no traffic packets are lost. 4 - I think there is some suggestion ("gleaning") of piggybacking some EID-RLOC mapping information onto 1 or 3 above, on the basis that the ETR is (or is near) and ITR which will soon want to know the mapping of the sending host. My understanding may be quite wrong. So I don't think that ALT is unworkable only if it is used to forward initial traffic packets. I think it is unworkable because it is a global query server system. I think it is even more unworkable because the path for queries, traffic packets and perhaps replies would often criss-cross countries and oceans. Living in Australia, I know all about the latency of the Pacific Ocean, under which most packets to the outside world travel. > And if the usage of PI address is > desired and encouraged, the major assumption of ALT will have not > a leg to stand on and the things will become worse. I think ALT is completely unviable. I am keen for the the LISP team respond to my critique - now beautifully illustrated by K. Sriram. - Robin http://www.firstpr.com.au/ip/ivip/ -- 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
