Re: [rrg] [Re: [lisp] [ipdir] LISP WG]

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
fred.l.templin@boeing.com

> -----Original Message-----
> From: Templin, Fred L
> Sent: Tuesday, March 17, 2009 2:42 PM
> To: 'Scott Brim'; Noel Chiappa
> Cc: rrg@irtf.org
> Subject: RE: [rrg] [Re: [lisp] [ipdir] LISP WG]
> 
> Scott,
> 
> > -----Original Message-----
> > From: Scott Brim [mailto:swb@employees.org]
> > Sent: Tuesday, March 17, 2009 2:03 PM
> > To: Noel Chiappa
> > Cc: rrg@irtf.org
> > 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
> fred.l.templin@boeing.com
> 
> > 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
> > rrg@irtf.org
> > http://www.irtf.org/mailman/listinfo/rrg