Subject: RE: [seamoby] Comments on IRTF mm problem statement

From: Phil Roberts <[email-masked]>
Date: Tue, 1 May 2001 09:19:00 -0400

> -----Original Message-----
> From: Phil Neumiller [mailto:[email-masked]]
> Sent: Tuesday, May 01, 2001 7:37 AM
> To: Phil Roberts; [email-masked]
> Subject: Re: [seamoby] Comments on IRTF mm problem statement
> 
> 
> Phil R.
> 
> You have listed many references at the end of the draft, yet 
> we interpret
> those references in completely different ways.  I look 
> forward to some of
> the authors of those drafts to chime in.

Well, a few of them already reviewed this.  But yes, more comment would be
welcome.

> 
> You seem to reduce the world to router failures.
Hardly.

>  That is not 
> what micromobility
> is about.  That may be one aspect but that is NOT the main gist.
> 
> Thanks,
> 
> Phil
> ----- Original Message -----
> From: "Phil Roberts" <[email-masked]>
> To: "'Phil Neumiller'" <[email-masked]>; 
> <[email-masked]>
> Sent: Monday, April 30, 2001 4:23 PM
> Subject: RE: [seamoby] Comments on IRTF mm problem statement
> 
> 
> >
> > > Hi Phil R,
> >
> > Hi,
> >
> > I haven't answered each point by point, but I hope what 
> I've said covers
> > most of the questions you included.
> >
> > > >There are a couple of seemingly unrelated problems that
> > > > have lead investigators to converge on the desirability of new
> > > >routing protocols to implement host routes within a 
> constrained area.
> > >
> > > The wording of the above sentence could be confusing for 
> MIP/SeaMoby
> > > "outsiders". I suggest SOMETHINK LIKE :
> > >
> > > ...routing protocols that allow for a mobile host to
> > > implement a limited
> > > host routing table to other mobile hosts in the same
> > > constrained routing
> > > area.
> >
> > But I don't think this is what we're interested in.  The 
> work certainly
> > applies to completely fixed networks (for network recovery 
> of failed routers
> > and links) and the problem of scaling is in the routers.
> >
> > > >The problem is to investigate the limits and issues with 
> using (a)
> > > >new protocol(s) to implement host routes to facilitate 
> better mobile
> > > >hosts and network recovery in the presence of failed links or
> > > >routers.
> > >
> > > To be fair, you MUST add that there are perceived deficiencies
> > > in using MIP all the time.  These must be quantified and qualified
> > > by the IRTF.  Specifically, how fast is a fast handoff, and WHEN
> > > IS USING HOST ROUTES EVEN DESIRABLE?
> >
> > I'm not opposed to putting in something about the 
> limitations of MIP, but
> > I'm not sure measuring MIP performance is what we want the 
> IRTF to do.
> > Seems like one could get some MIP implementors to measure 
> its performance.
> > What do others think?
> >
> > >
> > > >The document is a brief statement of the problem to be
> > > >investigated with lots of references to other work that 
> has been done
> > > >already by many others in the area.
> > >
> > > I would reword "with lots of references .. "  with "and 
> the references
> > > to lots of prior work in this area have been included in 
> this draft."
> >
> > Good.
> >
> > >
> > > >   Many investigators in this area have converged on
> > > >   solutions that propose the use of host routing to 
> support mobility
> > > >   within a limited domain, effectively exposing the 
> mobility of end
> > > >   systems to the routing protocols.
> > >
> > > Yes, an MANET has been working on this for years.  I don't think
> > > that's what we want to say here Phil.  What we need to do is talk
> > > about is localized host routing and WHAT it means to be local,
> > > i.e. how many hops, what kind of hops, how is MIP involved and
> > > how does it inter-work.
> >
> > OK.  Doesn't the following take what you're concerned about 
> into account?
> > "Specifically how many nodes could be supported across what 
> kind of network
> > breadth and depth at what cost of complexity in the routers 
> around the edge
> > of such a network?"
> >
> > I hadn't perceived that what we wanted the IRTF to do was 
> come up with an
> > interworking strategy between MIP and some to-be-defined 
> protocol.  Again,
> > other feedback?
> >
> > > If fast recovery is important, MANET has the fastest 
> non-looping and
> > > looping (Distance vector and link state routing) algorithms
> > > and protocols
> > > around.  Fast recovery of what Phil?  The link?  The MN 
> to AR path?
> > > The MN to MN path that bypasses MIP???
> >
> > What *I* have in mind is a completely fixed network with 
> router and link
> > failures where losing the traffic for many seconds results 
> in a much longer
> > service disruption.  I'm not sure these specifics need to 
> be specified in
> > the problem statement, but am open to suggestions from 
> others.  One of the
> > references describes this.
> >
> >
> > > A).  "due mobility" -> "due to mobility"
> > Got it.
> >
> > > A). Why OSPF?
> > > B). Why not BGP?
> > It's a particular problem of link or router failure in a 
> local fixed domain.
> > Hence OSPF.  I guess I'm not willing to ask about scaling 
> host routes across
> > domains where BGP operates just yet.
> >
> >
> > > C). The primary issue needed is to expose the limitations 
> of MIP and
> > > harden what we know about MIP quantitatively so ANY holes can
> > > be filled with local mobility management protocols.  I can
> > > not emphasize
> > > this enough.  THIS IS THE primary REASON.  The secondary REASON
> > > is to investigate if host routes deployed in a limited scoped
> > > way (where the
> > > limitations are set by what MIP can't do) is reasonable.
> > > Also, carefull
> > > analysis of where the MANET boundary is also required.
> >
> > I guess our perceptions of what the ADs requested are 
> reversed.  Perhaps we
> > can get some clarification.
> >
> > Phil
> >
> > >
> > >
> > > Thanks,
> > >
> > > Phil Neumiller
> > >
> > >
> >
> 
>

---

From: "Phil Neumiller" <[email-masked]>
Date: Tue, 1 May 2001 08:18:27 -0500

> > You seem to reduce the world to router failures.

That is the only motivation that calls for a need of micromobility in this
draft isn't it?  What other problem is solved besides this as described
in the draft?

-pdn