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

["Bound, Jim" <jim.bound@hp.com>]

Greg, 

Sounds fair.  ACK on all comments.  One other nit.  I would optimize for
IPv6 and do what you need to do for IPv4.  IPv6 ND/stateless and MIPv6
have advantages that IPv4 will never have so lets not bring IPv6 to IPv4
but let each evolve to its own capabilities.  That is completely fair to
under the new IESG guidelines for work on IPv6.  IF IPv6 has advantages
to us we should use them.

Thanks
/jim

> -----Original Message-----
> From: Greg Daley [mailto:greg.daley@eng.monash.edu.au] 
> Sent: Thursday, July 15, 2004 12:20 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:
> > Hi Greg,
> > 
> > Once I know I have changed links at L2 and prefixes I had 
> received I 
> > can be pretty sure the RA is from a new link and if it is 
> completely 
> > different prefix. This would work for initial deployment 
> too IMO.  My 
> > fear is for years IETF has tried to define such IDs and 
> have not been 
> > successful or have been deployed well in the market when 
> experimental.
> 
> I think that the complete prefix list (CPL) idea is good to 
> have in a draft now.  It makes sense to use that information 
> when it can be built.
> 
> When arriving on a new link after the first RA reception, we 
> still need a means to distinguish between the next RA from a 
> different router on the same link, and rapid transition 
> (ping-pong) between different subnets.
> 
> The cpl draft has a couple of different ways to do this, but 
> really provides best performance when the interval between 
> link changes is > 12 seconds.
> 
> I'd like to see something which doesn't explicitly require 
> link-layer hints to do this.
> 
> If we need to revisit some of the other ideas and see the 
> rusted carcases of what not to do, then your or others' 
> experience will be very valuable.
> 
> > Other options are an ICMP message type to verify a new link 
> or a new 
> > router RA link advertisement for MNs only.
> 
> I think that the big thing which was discovered when Bernard 
> looked into DNAv4 is that MIPv4 advertisements don't work 
> because they're not available everywhere.
> 
> We'd have to balance the cost of an facility not being 
> present (and relying on it, for example, if we had to send a 
> different message than an RS or an RA), as opposed to 
> providing enhancements to router and neighbour discovery, 
> which are almost universal.
> 
> The absence of our optimization then needs to have good 
> fallback cases.
> 
> using incomplete prefix lists may be good enough, if we take 
> into account the chance that there will be disjoint 
> advertised prefixes on a particular link (low?), and do 
> binding signalling even if we're only 95% likely to have 
> received RAs from all routers.
> 
> If the incomplete information is not seen to be good enough, 
> LinkID's may be.  They're included in otherwise vanilla RAs 
> as options and have good failure cases if we move from a link 
> containing them to one without (or the other way around), and 
> complement the presence of prefix advertisements (but don't 
> need them).
> 
> If they're not needed though, they're not needed.
> 
> > But if I were to look at IDs I would try to think about how 
> AAA could 
> > be used per link.
> > 
> > We should have the discussion for sure but with the caveat 
> if we are 
> > sitting here in 3 months and no good ID consensus is happening then 
> > use that as hint it may be stalling us for forward progress.
> 
> That's a very good idea.
> 
> Hopefully it won't take much effort to look into the ideas, 
> but if we're still blocked in 3 months (or less), I think 
> we'd be fairly unwise to not take your advice.
> 
> Greg
> 
>