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

Re: RE: [DNA] Best current practice for DNA



Hi Zhigao and Daniel,

I think that the solutions mentioned
are useful and interesting to DNA.

We're looking at three stages for the work 
in DNA though.

The first stage is goals/requirements planning,
the second is definition of the state of the 
art,  and the third is definition of new protocols
and procedures.

Even with the FastRA mechanism and its definition,
this is considered a new protocol (as is APID)
because of the behavioural modification involved.

What we need for the BCP is how best to combine
existing standards-based techniques to provide DNA.

For example, if we receive an unsolicited Router
Advertisement, how do we use that for link-change detection?

Sending of solicitations, and choosing a DAD state may be
applicable.  Also upper layer behaviours on reception of
L2 hints can be defined (I'd guess there would be either
no change, or a short message queue halt to check DNA).

SEND may come in here, as it will be an RFC before
the BCP is published.

What do others think about this?

Greg 
----- Original Message -----
From: Zhigao Chen <zgchen@psl.com.sg>
Date: Sunday, February 29, 2004 2:42 pm
Subject: RE: [DNA] Best current practice for DNA

> Hi Greg and all,
> 
> Recently we submitted a DNAv6 proposal, and the I-D can be found at
> http://www.ietf.org/internet-drafts/draft-chen-dnav6-apid-00.txt. 
> Builton NDv6, the proposal utilizes the generalized "APID", which is
> available from L2 hints.
> 
> In a nutshell, hosts create the mapping between each already-known 
> APIDand the corresponding default AR information in a so-called 
> APID Cache.
> They report unknown APID in RS message and ARs disseminate their on-
> linkAPID to hosts. Based on the APID Cache, a host perceives it 
> stays on the
> same link or back to a previous link or is attaching to a new link. 
> Whenan APID in a new L3 hint is recognized, it performs 
> reachability test
> (using unicast RS/RA exchange) and address validation to ascertain
> whether an existing address can be used to fast re-establish L3
> connectivity. DAD can be either omitted or done in parallel with DAD
> (Optimistic DAD is used in the proposal). Plus, we think the random
> delay before sending the RA in reachability test is no longer 
> necessary.Thus, DNA latency is reduced.
> 
> We would like to seek your comments on this I-D and hope it could
> contribute to the BCP work in the WG.
> 
> Regards,
> Zhigao
> 
> > -----Original Message-----
> > From: owner-dna@ecselists.eng.monash.edu.au 
> > [mailto:owner-dna@ecselists.eng.monash.edu.au] On Behalf Of 
> > Gregory Daley
> > Sent: Sunday, February 29, 2004 9:17 PM
> > To: dna@eng.monash.edu.au
> > Subject: [DNA] Best current practice for DNA
> > 
> > 
> > 
> > 
> > Hi, 
> > 
> > I'd like people to start thinking as to what's
> > best current practice for DNA in IPv6 networks.
> > 
> > There's a charter milestone on this issue, and
> > it will be discussed at the session.
> > 
> > Please post your ideas beforehand, so that we can
> > spend our time as effectively as possible during the session.
> > 
> > Greg 
> > 
> > 
> 
> 
> 
> 
>