Re: [DNA] draft-ietf-dna-cpl-02.txt

[Greg Daley <Greg.Daley@eng.monash.edu.au>]

Hi Thomas,

----- Original Message -----
From: Thomas Narten <narten@us.ibm.com>
Date: Wednesday, February 1, 2006 10:55 am
Subject: Re: [DNA] draft-ietf-dna-cpl-02.txt
> > draft-ietf-dna-cpl-02 is for unmodified routers. Actual DNAv6 draft
> > can be found at
> 
> Yes, I understand this. My previous note was entirely within the
> specific context of receiving an RA (that contained a prefix we 
didn't
> know about) and how to handle that case.
> 
> BTW, I think it is useful to divide the problem space up three ways:
> 
> 1) host recommendations for interacting with non-upgraded routers
>   (i.e., those implementing 2461/2462)
> 
> 2) hosts/routers that can BOTH be upgraded with DNA extensions (the
>   protocol3 document)
> 
> 3) changes to routers that would benefit unmodified hosts. (also
>   contained in protocol3). I view this third category as "fixes" to
>   2461/2462 that all routers should do and as small improvements on
>   2461/2462.
> 
> while it may be OK to tackle cases 2&3 in the same document, I think
> it would be good to make it more clear that case 3 is something we
> want all routers to implement, and not just "if they want to support
> DNA".

I think that we have these broken up into 4 documents
rather than 3, with draft-ietf-dna-hosts and draft-ietf-dna-cpl
taking role 1).

Role 2 is provided by a successor document to draft-pentland-dna-
protocol3
(can we confirm that the name is draft-ietf-dna-protocol ?)

Role 3) is provided by draft-ietf-dna-routers 

Initially, the match for draft-ietf-dna-hosts and CPL wasn't
good with regard to the detail contained in the document and
authors wished for these to remain separate.

> > In most cases if the RA contains all the prefixes, the receipt 
> of first
> > RA is sufficient to check for link change.
> 
> Right. And since I expect this case to be common, its not at all 
clear
> to me that we need to make the DNA algorith more complicated to deal
> with cases that are not expected to happen much in practice.

Well, I guess we're not trying to be restrictive (the routers'
document discusses the issues though).

Greg

> Thomas
>