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

[Thomas Narten <narten@us.ibm.com>]

Hi Greg.

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

Is there a particular reason to have two documents rather than one?

Indeed, now I'm confused, because it appears I need to read two
documents to understand what hosts are supposed to do to handle case
1. I hope the plan isn't to have two RFCs on this topic...

Can someone summarize the main differences between these two
documents?

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

OK. Could the authors please indicate what their plans are for
reissuing this document and what changes it will contain? (I've read
protocol3, but if another version is coming soone, I should probably
wait before commenting.)

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

I'll have to go read this one. But I thought I saw things in the
protocol3 document that would correspond to role 3.

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

Well, one approach would be to make it clear that this part is
optional to implement. But I certainly assumed it was a required part
of the spec as I read it.

Thomas