Re: [DNA] DNA proposal issue 19 - was [Issue X] LinkID v.s. LandmarkPrefix

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

Hi JinHyeock,

----- Original Message -----
From: JinHyeock Choi <jinchoe@gmail.com>
Date: Monday, July 25, 2005 3:11 pm
Subject: Re: [DNA] DNA proposal issue 19 - was [Issue X] LinkID v.s. 
Landmark Prefix
> Dear Greg
> 
> > > As of my memory, in DT meeting, no such agreement (about why
> > > FRD is left) is made.
> > 
> > It was left _in_, not _out_.
> > 
> > So it is still under consideration, but it is important to
> > note (as I said above) that the scheme relies on
> > modified link-layer devices on the network side, so it
> > is important (IMO) to have a Base DNA protocol scheme which
> > doesn't explicitly rely on the presence of FastRD to get
> > useful performance.
> > 
> > If the WG desires that FastRD is included in another document,
> > then that's OK.
> > 
> > > An unfortunate incident in D.C. made a paranoid out of me, so
> > > I took keen notice about FRD treatment.
> > 
> > You've received my (public) apology on that count (and my
> > statement that I was of good, if misguided intention), and my
> > undertaking that I'll not interfere in any presentation or
> > decision making by the WG.
> > 
> > > About the FRD applicability, that's the decision for WG. If WG
> > > chooses FRD for its high performance in spite of L2 reliance,
> > > it's WG's call.
> > 
> > Yes.
> > 
> > > It's ok for you have an opinion about FRD and its treatment but
> > > I ask you NOT to assume it as an official agreement before going
> > > through a proper decision procedure.
> > 
> > I never did. Your own quotation of the e-mails describes this.
> 
> Unfortunately I got the impression you did. When I mentioned that 
> WG didn't make a decision that FRD is not under consideration for
> the main DNA solution, you wrote that WG decided at Minneapolis.
> If that impression was not intended, we agreed that WG didn't make
> a decision on FRD yet, right? In case, I wish
> we close this not-so-pleasant issue here. 

OK.


[cut]
> > So, getting back to my main point:
> > 
> > The schemes (CompleteRA and LinkID) are the same for
> > unsolicited RA (disregarding co-existance and
> > synchronization issues).   So we really don't need
> > to identify one scheme as being better for
> > unsolicited RAs.
> 
> The above analysis is dependent on # prefixes on a link. When I 
> worked on CompleteRA, some DT members showed concern for the
> link with high # prefixes. 

Certainly, but the fallback case is also described with CPL.
Each router is able to make an assessment if it can support the
complete number of Prefixes.  Any single router which can take
the load can send the RA as complete.  This will work so long as the 
prefixes are advertised by at least one router on the link.

Advertisement of a subset of the prefixes is even possible
(without coordination) if the cost of completeRA is too high

At the moment DNAO costs floor( ((#prefix * 17)+ 2+7)/ 8) octets.
for all additional prefixes advertised.   That's pretty
efficient compared to PIO.

Even more efficient schemes have been described - 
floor (((#prefix *9)+3+7)/8) octets)
- variant 2.

Given the size of the packets available in IPv6, the larger
option ( even with 6 native PIO prefixes) that can fit 
22 learned prefixes in the DNAO, even with the nastiest SEND
scenario I could describe.

That's a big # of prefixes.

As described before, this is not going to happen on any
well designed network.  We can even add 2 lines to help 
describe network configurations which are bad for this.

> Also I think we'd better have this kind of discussion to 
> investigate whether unsoilcted RA differentiates or not
> first, before jumping to the conclusion that unsolicited
> RA is irrelevant. 

OK, but except in never deployed pathological cases, 
CompleteRA is able to provide the same function as LinkID 
(with additional completeness for CPL).

Greg