Hi Dino, > -----Original Message----- > From: Dino Farinacci [mailto:[email protected]] > Sent: Monday, January 26, 2009 12:12 PM > To: Templin, Fred L > Cc: Robin Whittle; rrg RG; [email protected]; [email protected]; > [email protected] > Subject: Re: [Int-area] [rrg] Please respond: Questions from > the IESG as towhether a WG forming BOF is necessary for LISP > > > In the "stateless" case, having the LISP ITR return > > packet-too-bigs with degenerate MTUs (i.e., MTUs less > > than 1500) is going to leave source hosts with an > > unsatisfactory experience that they would not incur > > without an ITR/ETR in the middle. > > Ah, then that motivates to upgrade MTUs.
Upgrading to large MTUs everywhere is the desired end-state goal. But, if you are talking about the LISP "stateless" case, you would have no way of knowing when all links everywhere have been updated such that you can safely set the static value to something larger than 1500. > > In the stateful case, LISP relies on a brittle mechanism > > that has known vulnerabilities (e.g., [RFC2923]) and can > > easily be spoofed by off-path attackers. > > Are you saying MTU Discovery is flawed? You as much as said it yourself below... > > RANGER/SEAL fixes both of these problems and much more. > > With a lot more machinery and state. Let's not start this > conversation > again. I'm not sure we finished the conversation last time, and I know it wasn't conducted on the wider list distributions that we are posting to here. > > Fine qualifications noted (I think). About the LISP > > locator reachability bits, that seems like a lot of > > overhead to carry on each and every packet, and it > > 4 bytes per packet? Sorry, I don't think so. I was counting the UDP header as overhead, too. > > also seems to assume symmetric paths. RANGER assumes > > unidirectional tunnels and path asymmetry, i.e., if > > Site 1's packets use ITR A and go through ETR B at > > Site 2, the return traffic could actually come through > > Site 2's ITR C. In the LISP locator reachability case, > > how does C know anything about the reachability of A? > > It can send a Map-Request. But active-active on ingress and egress > will be the norm. > > > Although RANGER could send locator reachability bits > > in control messages as an optimization, its primary > > mechanism is through having the ITR probe the forward > > path to the ITR. Probing is by setting an "ack request" > > bit on every Nth data packet (+/- some delta if > > randomization is desired) and then observing whether > > a steady stream of ACKs comes back. > > This doesn't work because if you are going to claim liveness > through a > protocol, you have to send control packets all the time from > M ITRs to > N ETRs. If you claim liveness, you have to do this before you send > packets. So putting the probe in data packets is not sufficient. The RANGER model sends initial packets through a default mapper, which returns an ICMP redirect; that is not really a "protocol", but rather an alternate means of establishing a FIB entry in the ITR. Once the FIB entry is established, ITR->ETR liveness testing is piggybacked on top of ordinary data packets. That is 1x1; not MxN. > And if you send probes all the time from M ITRs to N ETRs, > you have a > huge scaling problem. RANGER piggybacks liveness testing on top of every Nth (+/- delta) ordinary data packet that flows from one ITR to one ETR. While packets are flowing, probing continues; when no packets are flowing, probing ceases. > > LISP also doesn't seem to take into account that a multi- > > homed site can partition, such that locator reachability > > does not necessarily imply end system reachability via > > specific locators. Nor does it provide a means for an ETR > > (A) to inform the ITR of a better ETR (B) when paths get > > stretched. RANGER has a means to accommodate this. > > Can you state some disadvantages of RANGER? There is no such > thing as > a free lunch, so your design has to make tradeoffs, but you seem to > never state them. Forgive me, and I will try to take a more balanced consideration from now on. For one thing, RANGER requires a means for synchronization of a very large distributed mapping database between a limited number of nodes; that is probably also the case for other map/encaps systems too. This may be tenable if the number of nodes participating in the protocol and the frequency of updates is kept relatively small, but I have no quantitative basis for the claim. > >> If we want to solve this problem, we could do this today > by having a > >> host switch it's TCP connection to another A record. This doesn't > >> happen today because people deal with packet loss, since it doesn't > >> last long *and* rerouting actually works quite well. > >> > >> Van Jacobson always made this comment and I'll never > forget it, "The > >> fact that the Internet drops packets is it's greatest feature". > >> > >> What else can either an xTR or TCP host do when sending ICMP > >> Unreachables are off by default in most modern routers, or they are > >> filtered by firewalls, and route aggregation hides > failures close to > >> packet sources. > > > > RANGER can listen for ICMP unreachables coming from network > > middleboxes that it can verify as on-path by checking the > > Non-starter, you will not get ICMP unreachables, period. So if you > solely depend on it, the solution is a non-starter. ...there - you said it yourself! > > SEAL_ID. In a RANGER world, network middleboxes would be > > encouraged to turn the ICMPs back on because site border > > xTRs will have a means to detect spoofing (i.e., the SEAL_ID). > > But, this is an optimization only; nothing in RANGER depends > > on getting the ICMPs from middleboxes. > > You have to turn it on in all transit routers. You will get > objection > to this. It will never happen and if you think it could possibly > happen, it will take forever. Well, I did say "optimization only"; the ICMPs would be nice to have, but RANGER can live without them. Thanks - Fred [email protected] > > Dino > > _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
