[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [DNA] Issue 1: Use of 1.5 hours in the text




> Ah, ok.  I'd missed that point.  I'm still not keen on the idea of 
> using 
> 3 times the maximum value of MaxRtrAdvInterval if that maximum is 
> to be 
> raised much larger than 1800 seconds.  Perhaps the 1.5 hours can be 
> retained where it relates to prefix changes on routers.
> 
> For expiry of DNA information, 3 times the actual advertised 
> MaxRtrAdvInterval for each prefix.

Sorry, my typing didn't match my thinking there :) I meant:

For expiry of DNA information, perhaps each prefix could expire at 3
times the actual advertised MaxRtrAdvInterval after the last RA received
with the prefix.

Cheers,
Brett.

> Where the same prefix is advertised 
> by more than one router, then the maximum value of 
> MaxRtrAdvInterval 
> could be used.
> 
> Cheers,
> Brett.
> 
> Sathya Narayanan wrote:
> > Brett -
> > 
> >> Perhaps another approach might be to simply have some text that 
> says that when changing the lifetime 
> >> of a prefix, a router must send at least 3 Router Advertisements 
> with the new prefix lifetime before removing the prefix from a 
> link.  Even if a router 
> >> normally only sends Advertisements very infrequently, it doesn't 
> seem unreasonable to make 
> >> it send a few quick ones just during a period of prefix change.
> > 
> > This sounds ok to me. But, I am not sure how this change 
> addresses the issue. If the router advertises very infrequently, 
> the host will start dropping prefixes from the DNAHostPrefixList if 
> we keep the 1.5 hours restriction. After sometime, the list could 
> become empty and useless from DNA point of view.
> > 
> > - Sathya
> > 
> > ----- Original Message -----
> > From: Brett Pentland <brett.pentland@eng.monash.edu.au>
> > Date: Saturday, November 18, 2006 4:59 am
> > Subject: Re: [DNA] Issue 1: Use of 1.5 hours in the text
> > 
> >> Sathya Narayanan wrote:
> >>> Issue: WiMAX is trying to increase the MaxRtrAdvInterval into 
> >> hours or 
> >>> days. Should we change 1.5 hours to 3 * MaxRtrAdvInterval?
> >>> Agreement at the meeting: Yes. Lets make the change. We need to 
> >> include 
> >>> the MaxRtrAdvInterval in the RA so that the hosts can know 
> about 
> >> the 
> >>> value. If different routers on the link use different values 
> for 
> >>> MaxRtrAdvInterval, host should use the minimum (Should it be 
> >> maximum?) 
> >>> value of MaxRtsAdvtInterval times three as the lifetime for 
> >> prefixes in 
> >>> the DNAHostPrefixList.
> >>>
> >>> If you have any objection to the proposed change, please post 
> >> your 
> >>> objection on the list.
> >> Hi Sathya,
> >>
> >> JinHyeock is right about the 1.5 coming from the maximum value 
> of 
> >> MaxRtrAdvInterval.  If this maximum is to be increased to "hours 
> >> or 
> >> days" then I'd worry about just using 3 * that value.
> >>
> >> The 1.5 hours is the time used to age out old prefix 
> information.  
> >> It 
> >> was picked because it was supposed to ensure that at least 3 
> >> router 
> >> advertisements from each router would have been sent in that 
> time. 
> >> The 
> >> idea was to ensure that hosts have received an indication that 
> the 
> >> lifetime of a prefix has been changed if an operator wants to 
> move 
> >> a 
> >> prefix to another link.
> >>
> >> Section 5.1.11 recommends that operators wait for at least 1.5 
> >> hours 
> >> after removing a prefix from a link before reassigning it to 
> >> another 
> >> link. (I don't know if any operators will read this, but I guess 
> >> that's 
> >> another issue)  I don't think it desirable to increase this to 
> days.>>
> >> Perhaps another approach might be to simply have some text that 
> >> says 
> >> that when changing the lifetime of a prefix, a router must send 
> at 
> >> least 
> >> 3 Router Advertisements with the new prefix lifetime before 
> >> removing the 
> >> prefix from a link.  Even if a router normally only sends 
> >> Advertisements 
> >> very infrequently, it doesn't seem unreasonable to make it send 
> a 
> >> few 
> >> quick ones just during a period of prefix change.
> >>
> >> Cheers,
> >> Brett.
> >>
> > 
> 
>