Minor clarification: > If we are talking about a router that acts like a host,
In many low-end system use cases (laptops, etc.), it might be more natural to think of this as a "host that acts like a router". Fred [email protected] > -----Original Message----- > From: Templin, Fred L > Sent: Tuesday, March 17, 2009 2:42 PM > To: 'Scott Brim'; Noel Chiappa > Cc: [email protected] > Subject: RE: [rrg] [Re: [lisp] [ipdir] LISP WG] > > 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
