Subject: RE: [Ospf-wireless-design] DT Direction...

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

> >Could you elaborate?  Do you mean summarization or abstraction?
> 
> I mean summarization or ommision at the wireless boundary. Given
> that you have wireless cloud - why couldn't one limit the amount of
> information that is injected into the cloud? If the wireless 
> cloud is a 
> stub network then this could be limited to just the routes 
> for wireless
> routers and some number of default routes from egress points around
> the cloud. 
> 
> What do you mean by abstraction? 
> 

I was using the term as being synonymous with summarization

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

---

From: "Spagnolo, Phillip A" <[email-masked]>
Date: Fri, 24 Sep 2004 12:54:20 -0700

Here are few comments on differential hellos from implementing Cisco's
draft.

I would call the differential hellos a moderately hard piece.  From my
experience, it is harder than optimized flooding.  But, I wouldn't rule
it out do to implementation, after it is completed it can work well.  My
biggest question about differential hellos is adding a non-periodic
component to the hello process.

A few of the changes necessary (not inclusive):
-state machine (Differential hellos require a somewhat complicated state
machine and processing of the TLVs.  You cannot process the hello
message in order of the TLVs, you must keep all TLVs in memory before
determining what should be done with the packet.)
-sequence # (Increment for any state change)
-Active neighbors (only send in initial hello after new neighbor)
-Drop neighbors (require keeping history of dropped neighbors for 4
*dead interval, clear drop neighbor if renewed)
-Relays added (similar to neighbors)
-Relay deleted  (similar to neighbors)
-Partial state (must make checks of how many items in hello changed from
previous state and set flag if partial info) 
-Graceful restart (has to be changed due to partial info)

Phil

> -----Original Message-----
> From: Henderson, Thomas R 
> Sent: Friday, September 24, 2004 8:39 AM
> To: Spagnolo, Phillip A
> Subject: FW: [Ospf-wireless-design] DT Direction...
> 
> 
> can you comment on how easy/hard it was to implement the
> differential hello piece, and if hard, what was hard about
> it?
> 
> -----Original Message-----
> From: Abhay Roy [mailto:[email-masked]] 
> Sent: Thursday, September 23, 2004 11:53 PM
> To: Acee Lindem
> Cc: [email-masked]
> Subject: Re: [Ospf-wireless-design] DT Direction...
> 
> 
> Acee,
> 
> Yes I agree that flooding is where the biggest gains can be made. 
> So of course we need to start from there. But the "every little 
> bit helps" logic is very valid too ;) And in fact it has been 
> brought up by some of the customers we are talking to.
> 
> I also pointed earlier that we are proposing to overload Hello 
> with (possibly) a lot of new information. So an attempt to 
> condense this information using a seq# (incremental) approach 
> seems appealing in theory. I would like to suggest that we wait to 
> see some simulation/measurement numbers before ruling it out.
> 
> Regards,
> -Roy-
> 
> On 09/22/04-0400 at 6:17pm, Acee Lindem writes:
> 
> > I believe everybody agrees that flooding needs to be 
> optimised but is
> > it really a a forgone conclusion that we need to optimise hellos
> > and database exchange? I know that there was one vote for optimising
> > hello since "every little bit helps".  However, as OSPF WG 
> co-chair and
> > steward of the protocol, I see one of my main roles as 
> questioning whether or 
> > not the existing mechanisms need to be changed. 
> > Also, if flooding is dominant and database exchange is a 
> factor, why wouldn't 
> > we want to focus on reducing the amount of information? I 
> don't have a 
> > proposal for this but I've wondered why nobody has
> > gone down this path. 
> > Thanks,
> > Acee 
> > ----- Original Message ----- From: "Madhavi W. Chandra" 
> <[email-masked]>
> > To: <[email-masked]>
> > Sent: Wednesday, September 01, 2004 12:22 PM
> > Subject: [Ospf-wireless-design] DT Direction...
> >
> >
> >> Hi All,
> >> 
> >> I put together a brief outline as a suggested direction 
> for our Design
> >> Team.  For credibility and effectiveness of the DT, I 
> think we need to
> >> have focused direction and timelines.  Basically, we 
> shouldn't try to
> >> solve everything under the sun for OSPF-MANET...and we 
> shouldn't drag
> >> this on to the point that know one will care...including 
> us the DT! :)
> >> 
> >> Please see attached.  I also put in there the generic requirements
> >> that we (Cisco) have gotten from customers that lead to our design
> >> proposals. (Due to NDAs, I cannot share specifics.)
> >> 
> >>> From what I understand, the problem statement is more an 
> agreement,
> >> and not a formal draft.  So, we should be able to reach that in a
> >> couple of weeks.
> >> 
> >> Thanks!
> >> -Madhavi
> >> 
> >
> >
> > 
> --------------------------------------------------------------
> ------------------
> >
> >