Subject: RE: Summary Re: [nemo] comments on "Tree Discovery" draft

From: "Pascal Thubert \(pthubert\)" <[email-masked]>
Date: Fri, 27 Aug 2004 14:26:21 +0200

> > 3. TD is efficient because MR just needs to make a decision based on
> >  the received RA and its preference. No state or routing table is
> > needed.
> 
> "Efficiency" can be defined only if we know requirements and see what
> tradeoffs can be made.  TD is not efficient because the deeper the
> network, the larger RA's will be.  With a tree of height (or depth)
100,
> there'll presumably 100 TIO's in the leaf RA's.  If this is so, TD is
> nor scaleable nor efficient.

Alex: you misread the draft. There's only 1 TIO per tree the MR belongs
to. With nemo basic, it's 1 TIO per RA. TD makes the Default Router List
an ordered list.

Pascal

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 27 Aug 2004 15:13:01 +0200

Pascal Thubert (pthubert) wrote:
>>> 3. TD is efficient because MR just needs to make a decision based
>>>  on the received RA and its preference. No state or routing table
>>>  is needed.
>> 
>> "Efficiency" can be defined only if we know requirements and see 
>> what tradeoffs can be made.  TD is not efficient because the deeper
>>  the network, the larger RA's will be.  With a tree of height (or 
>> depth) 100, there'll presumably 100 TIO's in the leaf RA's.  If
>> this is so, TD is nor scaleable nor efficient.
> 
> 
> Alex: you misread the draft. There's only 1 TIO per tree the MR 
> belongs to. With nemo basic, it's 1 TIO per RA. TD makes the Default 
> Router List an ordered list.

That's right, I've misread.

Still, TreeDepth value on 8bit only?  Does this mean that only 255levels
of aggregation can be made?  This is not scalable.

TreeID: why this field.  Why not simply using the Home Address of the
ingress interface advertising this stuff?  Besides, it can be derived
from the src field of the base header and the prefix in the RA, no need
to add a new field in the TIO... This is not efficient.

What prevents two MR's to set up their TreePreference to the highest
possible values (255)?  If they do so, they'll present potential MR's
wishing to attach to it the same difficulty of choice as if they did not
use any TIO: to AR's can pretend to be default routers and the wishing
MR can not know which one to choose.  So, MR's using 255 TreePreference
are no better than AR's using Router Lifetime 0, from a wishing MR pov.  No?

Why adding a CRC?  Why not a checksum with a virtual header, the classic
stuff?  Why is CRC needed?  Remark RA already has a checksum covering
all RA options... This is not efficient.

Alex