IETF 71: dna working group minutes	

WEDNESDAY, March 12, 2008 1510-1610 Afternoon Session II
========================================================

Chairs: Greg Daley, Suresh Krishnan
Minute Taker: George Tsirtsis
Jabber Scribe: Dave Thaler

Document status and scribes - 3 minutes

* Simple DNA protocol presentation : Suresh

Simplified DNA protocol benefiting MNs moving between known links,
with no improvement when moving to unknown links

Simple DNA includes:
-	Link Layer Indication
Dave T> marks all addresses or just all the ones you can do optimistic DAD
Suresh> only for the ones optimistic DAD applies to
Erik> and only on the specific interface
-	Simple DNA Table
Erik> what happens when you get the address from multiple routers.
Suresh> ok we will handle this in the draft
-	Probing
-	Response gathering and assessment
Hemant and Wes> there is a big difference between the simple draft and
complete DNA. Think this is an improvement
Erik> comment from Erik
Dave T> I hope the problem Erik mentions is not common. Be explicit
that this is a change to ND
Suresh> yes
Erik> what you will kill is state you know from old epoc not the new one
Dave T> yes this is better
Suresh> so across interface initializations we do not save the state,
otherwise we do
Bernard> you do not send an NS for each of the prefixes because they
all go to the same router.
Suresh> yes in the draft it says that this is one per router
Stuart> Is it reasonable to say that routers not to use the same mac
and link local addresses on multiple interfaces?
Erik> Yes, this is reasonable advice but is it an issue for old
devices that may still do this? Does it break what we are doing today?
If we get some implementations out there we can see if people come up
with strange behaviors. And if this is mainly for wireless which makes
it more unlikely
Bernard> maybe a problem for cheap gateways that may be cutting corners

Dave T> you also have to deal with the case where you get the NA from
known router and the RA from unknown. Then what happens?
Suresh> It should be based on the order you get these
Dave T> The behavior on the table should be affecting only the row
on the table for that specific router. So the order should not matter.
Suresh> if the RA from unknown router comes first then, if I run MIP I
must create an address and send a BU. You can not wait
Erik> this is ok but it is still correct that the information you get
only affects the information for the specific router.
Dave T> I would say yes you need to send the BU immediately, it is
rare case and does not harm anything

-	Pending work
Some discussion on Tentative option...continue on the list
Suresh> What to do with DHCP?
Bernard> should do it here, differentiates from full DNA and it is simple
Suresh> we use the word "valid" for 2 different things
Bernard> another RFC uses the word "operable" for this
Suresh> ok, good.

Erik> the time value of random delay (500ms) is large, designed for
old contention based LANs. It is ok to recommend a lower number of
even make it dependent on the link speed.
Suresh> so a number or a formula?
Erik> a formula is even better
Some discussion on where this would go since it affects routers, while
mostly this is about hosts.

Jari> should we adopt this as a WG doc? No people disagree. So we take
it as a WG doc.

Suresh> shall we reclassify the complete dna protocol to experimental?
Erik> if you just want to document the ideas then it could be
historic. If you want to try it out (i.e., get IANA numbers) it should
be experimental
Jari> maybe historic and not get IANA numbers which can be done now.
Or make it experimental but then I say you first do the simple dna
work first and then this.
Dave T> I prefer for Info instead for historic because no codepoints
are assigned. It fits better with the definition.
Erik> if we go historic/information then we also need to remove header
definitions etc

Suresh> should we continue working on tentative options in the dna wg?
Preference to keep it in the WG.