[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.
> >>
> >
>
>