Scott, > -----Original Message----- > From: Scott Brim [mailto:[email protected]] > Sent: Tuesday, March 17, 2009 2:03 PM > To: Noel Chiappa > Cc: [email protected] > Subject: Re: [rrg] [Re: [lisp] [ipdir] LISP WG] > > I have a few questions about LISP-in-the-host:
I haven't heard about LISP-in-the-host, but if we are talking about a *pure* host (i.e., and not a router that acts like a host) we already have a widely-deployed mechanism for that [RFC5214][draft-templin-isatapv4]. If we are talking about a router that acts like a host, we have VET for that [draft-templin-autoconf-dhcp]. > - Liveness: Compare draft-meyer-loc-id-split-implications. What > level in what stack discovers that packets are not getting > through, and deals with it? The network layer is the only one > that knows what RLOCs are possible. [RFC5214], section 7.2 covers RLOC failure detection through negative acknowledgments, and [RFC5214], Section 8.4 covers RLOC liveness testing through positive acknowledgements: "7.2. Handling ICMPv4 Errors ISATAP interfaces SHOULD process Address Resolution Protocol (ARP) failures and persistent ICMPv4 errors as link-specific information indicating that a path to a neighbor may have failed (Section 7.3.3 of [RFC4861]). ... 8.4. Neighbor Unreachability Detection ISATAP hosts SHOULD perform Neighbor Unreachability Detection (Section 7.3 of [RFC4861]). ISATAP routers MAY perform Neighbor Unreachability Detection, but this might not scale in all environments. After address resolution, ISATAP hosts SHOULD perform an initial reachability confirmation by sending Neighbor Solicitation messages and receiving a Neighbor Advertisement message. ISATAP routers MAY perform this initial reachability confirmation, but this might not scale in all environments." > - Goodput: is there any way for us to change to using a different > src/dst RLOC pair based on performance? If there are multiple RLOCs, why not? Fred [email protected] > By the way see also > http://www.dagstuhl.de/Materials/Files/09/09102/09102.BrimScott1.Slides. pdf > ("REAP or Multipath: Should We Bother?"). I'm not sure I would still > agree with my conclusions but I believe some of the thoughts are useful. > _______________________________________________ > rrg mailing list > [email protected] > http://www.irtf.org/mailman/listinfo/rrg _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
