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

From: Michael Thomas <[email-masked]>
Date: Mon, 30 Apr 2001 16:14:03 -0700 (PDT)

Phil Roberts writes:
 > 
 > Hi Mike,
 > 
 > Perhaps, but I thought investigation using host routes and routing protocols
 > to support those was the point of this exercise?  What would you suggest as
 > an alternative?  Do you just want to make sure mobile subnets are evaluated?

   Yes; "host routes" are just a degenerate form
   of a subnet prefix, after all. IMO, the point
   of the protocol is to allow subnets to move
   around within a contained area (ie, still leads
   to globally aggregated prefixes), that makes
   them look for all intents and purposes as
   stationary hosts (except in routers of the
   contained area). Though host routes for mobile
   nodes are likely to be the most common, I think
   it would be a mistake to not consider any old
   prefix up front so that we can address any
   hidden problems with the protocol (if any).

		Mike

---

From: Phil Roberts <[email-masked]>
Date: Mon, 30 Apr 2001 18:56:08 -0400

Hi Mike,

Phil

> -----Original Message-----
> From: Michael Thomas [mailto:[email-masked]]
> Sent: Monday, April 30, 2001 6:54 PM
> To: Phil Roberts
> Cc: 'Phil Neumiller'; [email-masked]
> Subject: RE: [seamoby] Comments on IRTF mm problem statement
> 
> 
> 
> Hi Phil,
> 
> Just as a top level comment, can we remove all
> references to host routes? There's no reason why
> we should limit this to /128 and /32 subnets. I
> think that the exact same thing is happening with
> MIP (though it's a lot murkier there because of 
> the changed CoA).
>     
> 	Mike
> 
> Phil Roberts writes:
>  > 
>  > > 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
>  > > 
>  > > 
>