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

RE: [DNA] [Announce] DNA solution framework I-D



Hi Greg,

ACK and good point from Thomas on BCP.  That actually would work and
also we could do that once we are ready to ask implementers to doing
some performance analysis for us.  Pretty easy to set up is my view and
test.  

We are in synch.

Thanks
/jim 

> -----Original Message-----
> From: owner-dna@ecselists.eng.monash.edu.au 
> [mailto:owner-dna@ecselists.eng.monash.edu.au] On Behalf Of Greg Daley
> Sent: Thursday, July 15, 2004 2:47 AM
> To: Bound, Jim
> Cc: Brett Pentland; JinHyeock Choi; Erik Nordmark; 
> dna@eng.monash.edu.au; JinHyeock Choi
> Subject: Re: [DNA] [Announce] DNA solution framework I-D
> 
> Hi Jim
> 
> Bound, Jim wrote:
> > Greg,
> > 
> > Also I am assuming we are going to consider:
> > 
> >  
> > 
> ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-jinchoi-dna-cp
> > l-
> > 00.txt
> > 
> > Which is similar to what I suggested too?
> > 
> 
> Actually, if CPL works well enough, it may be a good idea to 
> suggest as one of the 'best' current practices (if as Thomas 
> seemed to indicate, BCP's don't even need to be widely 
> deployed 'current practices', if they're clearly the best).
> 
> Does this make sense?
> 
> As an existing practice, it could provide our base line 
> performance, and may remove the need for optimizations in 
> some (all????) cases.
> 
> >>My example from DNAv4 was primarily to illustrate that 
> we'll probably 
> >>be (happily) stuck with ND for most of our work.
> > 
> > 
> > OK.
> > 
> > 
> >>I think we'd probably co-operate with DHCWG if there's 
> further work to 
> >>be done on DNAv4 or IPv4 extensions (since that's where most of the 
> >>host autoconfiguration expertise for IPv4's now residing).
> > 
> > 
> > Note we also did build a unique DHCPv6ID in DHCPv6 we may 
> want to look
> > at too.
> > 
> 
> I'll have a look at that.
> 
> 
> >>If there's a need to support devices in a multi-technology 
> >>Internetwork (v6 and v4) then we'll head down that path.
> > 
> > 
> > Agree but that is really a transition issue potentially.
> > 
> 
> Indeed.
> 
> >>My personal opinion is that there are clear advantages 
> >>afforded by IPv6 in this area (SEND being one of the keys), 
> >>and we should spend most of our time building based on the 
> >>best possible technology, if we can do it without building 
> >>air-castles.
> > 
> > 
> > Agree but we cannot be in denial about the limitations of 
> IPv4 for this
> > emerging technology as architects either.
> 
> Agreed.
> 
> Greg
> 
> 
>