Erik

Brett Pentland wrote:

> Probably.  Unless someone's got a good idea, maybe we can leave it as an
> open issue to be discussed in the WG?
>
> I'll put it down as issue 13.


OK.

How about putting the remaining open issues in the I-D when it ships, so that the reader can see things in one place.

   Erik 

Jim

>How about putting the remaining open issues in the I-D when it ships, so
>> that the reader can see things in one place.
>>


I'd prefer to have an "Issues" web page. It makes maintenace of the issues
easier. One can attach email threads, etc., hard to do in a document. This
worked well for us in SEND and even Seamoby.

            jak

Erik

James Kempf wrote:

>> How about putting the remaining open issues in the I-D when it ships, so
>> that the reader can see things in one place.
>>
>
>
> I'd prefer to have an "Issues" web page. It makes maintenace of the issues
> easier. One can attach email threads, etc., hard to do in a document. This
> worked well for us in SEND and even Seamoby.


Yes, but for the WG meeting Paris, it makes sense to also put the issues in the document, because presumably we want the WG to common on those and they haven't see any of this yet.
Hence a shapshot of the issues (with a pointer to the issues page) in the I-D would be good.

  Erik

Jim

OK, sounds good.

            jak

----- Original Message ----- 
From: "Erik Nordmark" <erik.nordmark@sun.com>
To: "James Kempf" <kempf@docomolabs-usa.com>
Cc: "Brett Pentland" <brett.pentland@eng.monash.edu.au>;
<dna-dt@eng.monash.edu.au>
Sent: Thursday, April 21, 2005 9:41 AM
Subject: Re: [DNA-DT] Solution1, Issue 13: Lifetime of learned prefixes and
routers



>> James Kempf wrote:
>
>>>> >>How about putting the remaining open issues in the I-D when it ships, so
>>>> >>that the reader can see things in one place.
>>>> >>
>>
>>> >
>>> >
>>> > I'd prefer to have an "Issues" web page. It makes maintenace of the

issues

>>> > easier. One can attach email threads, etc., hard to do in a document.

This

>>> > worked well for us in SEND and even Seamoby.
>
>>
>> Yes, but for the WG meeting Paris, it makes sense to also put the issues
>> in the document, because presumably we want the WG to common on those
>> and they haven't see any of this yet.
>> Hence a shapshot of the issues (with a pointer to the issues page) in
>> the I-D would be good.
>>
>>    Erik

Brett

Erik Nordmark wrote:

> Brett Pentland wrote:
>
>> Probably.  Unless someone's got a good idea, maybe we can leave it as an
>> open issue to be discussed in the WG?
>>
>> I'll put it down as issue 13.
>
>
>
> OK.
>
> How about putting the remaining open issues in the I-D when it ships, so that the reader can see things in one place.


Good idea.

Brett. 

Brett

James Kempf wrote:

>> How about putting the remaining open issues in the I-D when it ships, so
>> that the reader can see things in one place.
>>
>
>
> I'd prefer to have an "Issues" web page. It makes maintenace of the issues
> easier. One can attach email threads, etc., hard to do in a document. This
> worked well for us in SEND and even Seamoby.


How about a URL for the issues list in the document?  This will be a -00
and obviously it would come out before a final document is produced by
the WG.

Brett. 

%META:TOPICINFO{author="BrettPentland" date="1114067698" format="1.0" version="1.1"}% %META:TOPICPARENT{name="DNASolution1"}% Back to DNA Solution1 Issue Tracker

Lifetime of learned prefixes and routers

Each router will learn the IP addresses of the other routers on the
link (for use in the delay computation) and the prefixes they advertise
(for DNAO and responding to landmarks).

Each of these pieces already have lifetimes, but the maximum lifetimes
can be fairly large (18 hours for default routers, infinite>>30 days for
the prefixes).

Thus it probably makes sense to add an upper limit how long a router
retains this information from other routers, once those routers stop
sending RAs. 1.5 hours sounds like a good number :-)

But even if we do so, we have the case of newly arriving routers not
having the same information.

Example:
R1 and R2 are on the link.

R1 goes silent. R2 retains it in the router list used for delay
calculation. (And any prefix that was exclusively advertised by R1
would be in the learned prefix list.)

R3 arrives on the link. Even if it sends an RS (or something else)
to quickly learn about the routers (and prefixes) on the link, it will
end up with different information than R2 has, until the 1.5 hours
have passed.

This means that the ranking for RA delay will be off, because R2 will
calculate those based on the routers being (R1, R2, R3) and R3 will
calculate those on (R2, R3).

Is this something we need to fix?

   Erik 

Discussion

-- Main.BrettPentland - 18 Apr 2005

Back to DNA Issue Tracker Base Page