Re: [DNA] Re: Interest in DNA or not? (Re: )

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

Hi James,

James Goldsmith wrote:
> Greg:
> 
> I am happy that you took this mail in good sprit. 
> 
> Here are my three comments:
> 
> 1) Goals and BCP drafts are Ok for novices, but there are no fundamental 
> advancement of knowledge in these drafts. So, they are just the place 
> holders, similar to padding in the data frames to align on certain 
> boundaries;-)

Indeed.  That's what RFC's are basically for.  They're not for the
Illuminati of a particular technology to pore over, but for deployers
or implementers, some of which won't know why certain steps were taken.

Not everyone will read the goals document.  It has been mostly useful
to those people in the group considering the problems.

The BCPs will be less relevant if people make modifications to
protocols (using things like a DNA solution).  There aren't really
specifications of this today for the person who doesn't read RFC2461
regularly.

The latest versions of the BCP draft provide usual case performance
statistics though, for triggered RS/RA exchanges.   The figures there
are telling (though predictable):

You can't use RFC2461 RS/RA, the primary routing discovery mechanism
in IPv6, to support real-time voice (or video or user sessions or...).

So something has to be done.  If that doesn't mean standards track, it's
still worth documenting (IMO).


> 2) If you ignore Alper et. al's link hint draft which pre-exist before 
> DNA group, all other drafts that you mentioned below have been 
> co-authored by just the three authors - yourself, Jin-choi, and  
> Narayna. That, by any definition, is extremely limited participation 
> from the standardization point of view.

I try not to ignore the link information draft.

It's pretty important, in terms of IETF interest in sub-L3 issues.

There are other drafts, some of which predate DNA and are mobileip
or IPv6 titled. Also, please be aware that there are co-authors on the
list of publications which you mentioned, which are making important
contributions.

You're right though, that there are some people putting a lot of
time into DNA work.  It's pretty amazing that people can be employed
for a while (like me) to never send a packet which is forwarded by
a router :)

You may be pleased to know that I'm not a member of the DNA design team.
I've been following their progress through reports, and they're doing
well.  There are new ideas coming out of the (sub)group.

So maybe an idea which wasn't proposed by the three authors you mention
will be the focus of DNA standardization.

> 3) Honestly, I don't find any thing compelling in the solutions because  
> all we have are variations of fast RA with various names such as det RA, 
> probalistic RA or stochastic RA (waiting for it ;-). RA caching in light 
> weight APs is big no. Unless, someone can prove near-optimality of a 
> pure L3 solution, you are simply advancing something that will do more 
> harm than good.

Well, we've already had more harm than good advanced in RFC3775 :)

In Mobile IPv6, there wasn't time, space or inclination to do
movement detection for mobile hosts correctly.

So some of the Router Advertisement timers were modified.  I was there
at the time, and contributed text.  It certainly wasn't any person's
favourite specification (the RA timers/MD), but there wasn't any way of
indicating succinctly how to use triggers, or which circumstances things
could be done in (at L3).


I'm pretty sure that the next draft isn't going to be stochastic RA
(unless you submit it - it's getting pretty close to April 1).

As you say, most of the drafts on the list cover RA delivery.
There are three main areas where I think DNA may be able to contribute:

* When and how to initiate checks.
* How to identify from a single received message that change
   has occurred
* How to receive change information reliably and quickly.

These are being covered, and probably have the same level of attention
(considering link-hints, BCP, prefix lists, draft-pentland-mobileip-linkid).

These may not have the same architectural challenges as IPv6
multihoming, but are relatively achieveable, and potentially useful.

If changes at L2 or in deployed networks make this unuseful, we'll
take a serious look at that, and whether there should be a DNA group.

It's going to be possible to prove the optimality and safety of
L3 change detection solutions, though.

It's also going to be possible to ask L2 designers: please give
L3 the information and choice, the host is capable of deciding.
Perhaps less per-technology focus will be needed by L2 designers,
and they can concentrate on shipping frames fast.

How this is achieved in reality may be different though, with
wireless issues potentially dominating anything which can be done
at L3.

> Thats all that I have to say.
> 
> James

Well, your opinions are definitely sought.

Sometimes the light of reason shines through someone
saying "Wait a minute!".

Feel free to discuss some more of these ideas
(if you have the time or inclination).

Greg