Subject: RE: [Ospf-wireless-design] Design Team Problem Statement

From: "Henderson, Thomas R" <[email-masked]>
Date: Thu, 16 Sep 2004 16:28:32 -0700

> -----Original Message-----
> From: Joe Macker [mailto:[email-masked]] 
> Sent: Wednesday, September 15, 2004 8:46 AM
> To: Henderson, Thomas R
> Cc: [email-masked]
> Subject: Re: [Ospf-wireless-design] Design Team Problem Statement
> 
> 
> Henderson, Thomas R wrote:
> 
> >Sorry I am late to respond to these threads, but I was on
> >vacation, then on some other business travel until yesterday.
> >
> >I will respond to Madhavi's message in a separate email, but
> >have the following separate comments:
> >
> >  
> >
> >>-----Original Message-----
> >>From: Acee Lindem [mailto:[email-masked]] 
> >>Sent: Wednesday, September 01, 2004 7:49 AM
> >>To: [email-masked]
> >>Subject: [Ospf-wireless-design] Design Team Problem Statement 
> >>
> >>
> >>I've struggled with this and here is what Joe and I have come up
> >>with so far. I think it might be good to bounce it off the group
> >>for opinions on what this should contain.
> >>
> >>
> >>             OSPF Wireless Design Team Problem Statement
> >>
> >>  The charter of the design team will be to select the initial
> >>  set of OSPFv3 extensions in support of wireless (or 
> MANET) networks
> >>  and document these in one or more Internet Drafts. The extensions
> >>  will become WG documents and will be reviewed by the OSPF 
> >>and MANET WGs.
> >>  The initial environment will be viewed as:
> >>
> >>   1) Design team will focus on OSPFv3 and not OSPFv2.
> >>   2) Compatibility with non-wireless OSPFv3 implementations must be
> >>      maintained.
> >>   3) Only Intra-area environments will be considered in the 
> >>initial set of
> >>      extensions.
> >>   4) MANET wireless environments will not normally be a transit for
> >>      wireline networks but this shouldn't be precluded.
> >>    
> >>
> >
> >I do not understand how to deal with this goal.  Does this mean that
> >we are optimizing for a stub configuration, but will not preclude
> >hooking it up in transit configuration, in which case it 
> will function
> >correctly but not necessarily be optimized for that scenario?
> >  
> >
> Tom that is how I interpret it.  I agree we should not 
> preclude transit.
> Also, there is more of an initial design emphasis on 
> intraarea mobility 
> enhancements
> 
> Regarding the term optimized...
> 
> I would prefer to target improved effectiveness and robustness 
> improvement goals rather than maximal efficiency.What are the 
> priority 
> factors for improvement and scaling balanced against complexity?
> 
> An example from your recent analysis, is its not clear that 
> the reducing 
> HELLOs is a big issue (e.g., consuming local resource only) 
> for scaling, 
> but it is likely more about the LS flooding process optimization.
> 
> We debated this for a bit at the first design team meeting... 
> but I do 
> not remember a clear conclusion.

I am OK to leave the text as it is, where it doesn't say "optimized".
However, I agree with your goals of effectiveness and robustness
in addition to bandwidth scaling.

> 
> >  
> >
> >>   5) Number of nodes in the wireless network should be 50 - 
> >>XXX (where XXX
> >>      is what is acheivable given the technologies we have to 
> >>chose from).
> >>    
> >>
> >
> >As for this goal 5), how about "The scaling goal for the number of 
> >nodes on the wireless channel is up to 100 nodes, although larger
> >numbers of nodes might also be supportable."?
> >
> >Rationale:
> >- if I recall correctly, larger than 100 node MANETs were considered
> >to be the province of the ANS research group, back when 
> MANET rechartered
> >in 2002
> >- no need to lower limit the number of nodes at 50
> >- by limiting the number of nodes on the wireless *channel*, and not
> >in the overall *network*, we allow for possibility of larger 
> networks 
> >that may only have a small wireless component
> >  
> >
> I hate using number since everything is scaling issues are so 
> scenario 
> dependent (e.g., link rate supported, mobility rates and models, 
> expected neighborhood densities).  But I know people want a nominal 
> notion.  50-100  range sounds about right....But what if in a given 
> scenario 50 scales well with a low impact, low complexity 
> design and 100 
> doesn't? Do we discuss it or do we just say it didn't make 
> the 100 cut.

I agree with you about the observation that "it is all dependent on
scenario," but we probably need to scope it somehow for this problem
statement.  What if we said something like "up to the order of 50-100
nodes" rather than "up to 100 nodes"?

_______________________________________________
Ospf-wireless-design mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ospf-wireless-design

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Wed, 22 Sep 2004 23:03:06 -0700

> Sent: Wednesday, September 22, 2004 1:02 PM
> To: Joe Macker; Madhavi W. Chandra
> Actually this isn't the highest thing on my priority list so I'd
> be more than happy to turn over the problem statement to Tom (since
> he was nominated as DT leader) or someone else. 
>  

Acee,
I can continue to edit the problem statement if you want.

I am trying to organize this effort by summarizing all the
things that people have put on the table so far.  Attached
is a first (incomplete) cut at this-- comments and suggestions
for improvement or clarification are welcome.

Tom