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

From: James Goldsmith <[email-masked]>
Date: Sat, 12 Feb 2005 01:22:13 +0000

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

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. 

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. 

Thats all that I have to say.

James

On Sat, 12 Feb 2005 Greg Daley wrote :
> > DNA group has been very inactive for quite some time.
> >
> > There are only two messages in February - one is an IESG
> > announcement, and another is from the chair.
>
>I'm sorry, postings here have been pretty light,
>and it seems I'm taking more than my fair share.
>
> > There were no
> > messages in January and only a few messages in December all between
> > Pekka and Jinkchok on the goals draft.
> >
> > It appears that people have lost interest in this group, and not
> > many seem to care any more about the work pursued in this group.
> > There are only 3 or 4 people have any interest left in DNA group?s
> > continued activities.
>
>
>Certainly mailing list traffic has been light.
>
>This is of concern to both the Chairs and the Area
>Directors.
>
>There are, as you say, a small core of people
>actively driving work for this group.  The number of
>people is probably about three times as large
>as you say, but the silence of the other
>Mailing list members should be explored.
>We really need to see if the (list) members are
>actually interested in the outputs of those
>currently spending cycles on the development.
>
>It is worth noticing that there are at least
>two implementations of ideas under discussion,
>and interest from manufacturers.
>
> > This is very rare for an IETF group where it is easy to see even a
> > smallest working group attract a few hundred people in meetings
> > (and /or on mailing lists).  The main reason is that DNA group
> > hasn?t produced any thing useful ? goals and bcp drafts are just re-
> > iteration of what already exist in IPv4 and IPv6 mobility
> > architecture documents.
>
>At the last IETF session, we didn't have room
>for one of the A-D's to squeeze in (sorry!)
>
>Perhaps we have or will see a waning of interest.
>
>It's worth working out whether this is the case,
>though.
>
>The goals document is a distillation of the
>discussions which originated back in the days of
>MIPv6 development.  At the time, the understanding
>of the problem was actually quite poor, and
>JinHyeock and I (and others) proposed some
>solutions which look naive now.
>
>A set of goals to measure solutions against
>is certainly worth having.  Now that it has
>been approved, the work can move onto something
>closer to implementation.
>
>The BCPs are similar in that people have previously
>been able to design solutions which work in a
>some constrained environments (Eager Cell Switching,
>etc), but have significant drawbacks in others.
>the BCPs are to give something defined in the
>current standards which is useful, safe and
>reasonably fast.
>
>Personally (biased), I think that these documents
>aren't redundant. As far as I can see there
>weren't really any architecture documents for
>mobility in IPv6 :)
>
>Please be aware: this is not a mobility group.
>It's a connectivity group.  Erik Nordmark
>(then an AD) said that he thought the problem was
>broader than movement detection.
>
>So while mobility documents may have had a go at
>defining mechanism for fast reconfiguration
>in a particular network, not everyine will have
>50ms mean delay between RAs, nor FMIPv6.
>
> > Based on past proceedings and discussions, it appears that DNA
> > group cannot propose any solution without Layer 2 event
> > modifications; something that is outside the scope of IETF.
>
>This is not the case.
>
>There are several interesting and widely applicable
>ideas of how to do this at L3.
>
>By monday, a design discussion draft will be
>posted (one of the Design Team products), which
>will shed light on this.
>
>At this stage, DNA-DT discussions have been
>in-camera.  Pekka and I aren't even on the list.
>It's not surprising that details aren't leaking
>out onto the DNA list yet then.
>
>While this is not aimed at secrecy, the DT have
>been doing a good job of effectively and efficiently
>evaluating various solutions.  New ideas and
>knowledge have been uncovered.
>
>Please wait and see for this (only a few days more).
>
> >  I
> > don?t see any interesting proposals being discussed in DNA WG. On
> > the other hand, there are over a dozen actively pursued proposals
> > in IEEE 802.21 ? protocol independent handoff group. For Layer 3
> > solutions, I have not seen any thing better than fast RA draft that
> > exists from pre-DNA group creation.
>
>Well, that depends on your point of view.
>
>There are plenty of drafts in the repository.
>
>
>https://datatracker.ietf.org/public/pidtracker.cgi?command=search_list&search_job_owner=0&search_group_acronym=&search_status_id=&search_cur_state=&sub_state_id=6&search_filename=-dna-&search_rfcnumber=&search_area_acronym=&search_button=SEARCH
>
>You'll notice:
>
>(In the existing protocol space)
>draft-ietf-dna-link-information (None)
>
>draft-narayanan-dna-hosts-bcp
>draft-narayanan-dna-routers-bcp
>draft-jinchoi-dna-cpl
>draft-hong-dna-if-l2
>
>(in the proposal space)
>draft-narayanan-dna-rrd
>draft-daley-dna-det-fastra
>draft-daley-dna-nonce-resp
>draft-daley-dna-prob-fastra
>
>More drafts are expected on monday or by monday.
>
>As you know, a lot of the drafts
>come from a small core of people.
>If they're missing something, then people should
>contribute a more effective solution.
>
>
> > Yes, I know two or three active people in this group are trying to
> > create some sort of solution document, but it appears, based on
> > rather poor traffic on the mailing list, that mobility community
> > has already given up.
>
>Perhaps you are correct with regard to mailing list activity.
>
>It is certainly worth finding out if people
>are interested in the outputs of the group.
>
>Another alternative idea may be that while people
>are interested in the outputs, they are unable
>to devote time to the document and protocol
>development themselves (except for example
>at IETF).
>
>Perhaps we can poll people as to what their
>current level of interest is, and determine if
>some actions need to be taken.
>
>Certainly there needs to be more input on the ML
>for the IETF process to be fully effective.
>Lulls with furious activity around meeting times
>have the potential of blindsiding the group if
>new technical details come out too late to be fixed
>before a session.
>
> > What is the point of creating a document in which most people seem
> > to have lost the interest? In my opinion, the group should become
> > dormant or be closed until IEEE comes up with better event
> > definitions for layer 2 for facilitating faster hand-off.
>
>If people have lost interest and don't
>want to see a document, please speak up.
>
>If you're interested, but quiet, please indicate
>if this is so.
>
>Your advice on how best to advance the group
>is also welcome.
>
>(Chair Hat Off)
>
>Personally, being biased, I think that new
>trigger primitives are only half of the story.
>
>It may take a long time to upgrade or replace
>the majority of deployed link-layer equipment,
>especially those with a firmware or part hardware
>implementation.
>
>Software upgrades on host and routing
>infrastructure are either more common (for routers)
>or don't require co-ordination (for hosts).
>This may give L3 solutions earlier momentum
>than new L2 solutions.
>
>It's also worthwhile to remember that while
>IEEE's protocols are pervasive, they're not
>universal.
>
>Thanks again for having the courage to
>express an opinion.
>
>Greg

---

From: Greg Daley <[email-masked]>
Date: Mon, 14 Feb 2005 11:25:42 +1100

Hi James,

James Goldsmith wrote:
> 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.

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

---

From: Pekka Nikander <[email-masked]>
Date: Mon, 14 Feb 2005 17:22:05 +0200

Dear James,

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

Firstly, I appreciate you voicing your opinion.  Critic is what strives 
you for better.  That said, would you please elaborate?  What is the 
reason that you see them as doing any harm in the first place?  How 
does that harm exceed the good that you see?

If you are sincere with your critic, I'd like to see you back it up.  
On the other hand, if you are just expressing your frustration about 
the silence on the list, we may expect that to change soon.  The design 
team document was submitted today, and should appear shortly.  Either 
Greg or I will announce it here as soon as it appears.

--Pekka