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

From: Daniel Park <[email-masked]>
Date: Tue, 19 Jul 2005 20:36:12 +0000 (GMT)

And I think it is worth to provide the complete comparison list

between Landmark and Linkid Schemes, so that the non DT members can

uderstand and will be able to participate in the selection process for

the link identification method. I hope this is not a

burden for the DT as they already know how each schecme works :)

jak>> I've got no objection if someone wants to do this, but I really don't

think it is necessary. People just need to read the drafts and decide for

themselves which one they like.

Daniel> Strongly disagreed, in my understanding, DNA will decide

which one  would be more valuable method and it will be accepted

as WG item, then another one will be dead.  (I don't think
we need

both) Rather just reading a draft, specific comparison and evaluation

would be more good effort on adopting any protocols within each WG

if available.  So it is definitely necessary at this stage.

Regards

Daniel (Soohong Daniel Park)

Mobile Platform Laboratory. SAMSUNG Electronics

---

From: JinHyeock Choi <[email-masked]>
Date: Mon, 25 Jul 2005 14:11:06 +0900

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. 

> > > Well, it's the same for both schemes, and therefore shouldn't
> > > take up our highest priority (or any if we're pressed for time)...
> >
> > This the the conclusion I can't be sure of. There may be a link
> > in which CompleteRA can't be made as mentioned in Brett's draft
> > below,
> >
> >   It may not be possible to include all of the prefixes in use on the
> >   link due to MTU or administrative limitations.
> 
> Please let me make this clear then:
> 
> This is handled by falling back to CPL, and the RAs do not contain
> completeness indications (i.e it is not a CompleteRA).
> This is described in the draft (2nd paragraph of page 7, and
> fourth Paragraph of page 20).
> 
> Please notice that in the usual case, CompleteRA has the same
> per-packet overhead as Prefix LinkIDs: none.  So in the usual case
> the comments aren't applicable.
> 
> The MTU argument isn't useful for today's RAs and is present
> mainly for future protection:
> 
> For most deployments of routers:  say 4 distinct prefixes/link, the
> maximum overheads for CompleteRA and LinkID aren't very different:
> 
> CompleteRA :- maximum 56 octets Max overhead/RA
> LinkID:-  32 (64 transition) octets Max overhead/RA.
> 
> This assumes that each router advertises at least one prefix.
> 
> Since SEND will add less than 632 octets (320 CGA option,
> 280 octets Signature option, 16 timestamp, 16 Nonce) even
> with 2048bit RSA keys, there will still be 648 octets
> left for the IPv6 header, RA header and options, if we
> limit the RA to even the minimum IPv6 MTU (1280 octets).
> 
> With the headers, SLLAO and MIPv6 Advertisement Interval,
> there are still 576 octets left for PIOs and DNAO or
> LinkID LPIO options.
> 
> So the limitations have to be administrative today (due to
> storage or transmission limitations).
> 
> It's not going to take much/any text to describe
> the tradeoff, if it's needed.
> 
> 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. 

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. 

Thanks in advance for your kind consideration. 

Best Regards

JinHyeock

---

From: Greg Daley <[email-masked]>
Date: Tue, 26 Jul 2005 05:11:33 +1000

Hi JinHyeock,

----- Original Message -----
From: JinHyeock Choi <[email-masked]>
Date: Monday, July 25, 2005 3:11 pm
Subject: Re: [DNA] DNA proposal issue 19 - was [Issue X] LinkID v.s. 
Landmark Prefix
> 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

OK.

[cut]
> 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

---

From: Greg Daley <[email-masked]>
Date: Wed, 27 Jul 2005 10:28:56 -0400

Hi Erik, 

----- Original Message -----
From: Erik Nordmark <[email-masked]>
Date: Monday, July 25, 2005 10:24 pm
Subject: Re: [DNA] DNA proposal issue 19 - was [Issue X] LinkID v.s. 
Landmark Prefix
> Greg Daley wrote:
> 
> > In CPL which is host (only) based, the timers are on the host, 
> and 
> > protect
> > the host from long term damage, by removing unupdated 
> information 
> > at the host.
> > 
> > Even with the most broken readvartisement scheme for stale 
> information,> the damage could only occur for a maximum:
> > (Router out-of-date timer + Host out-of-date timer)
> 
> Are you talking about RFC 2461, or are you talking about a 
> proposal for 
> how CPL could work?

Sorry I think I changed topics in mid e-mail, and referred
to CPL as an example of particular behaviour, before
going back to my main topic.

The inequality refers to modified advertisement schemes
(those which readvertise learnt information), rather than
CPL.

Greg