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

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

Alex: the draft is not too thick, please read it better:

> >>> 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.

It means that you can not be deeper than 255 hops from the AR. Enough
considering TTL.

> 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.
> 

This gives a unique ID for the tree. It's needed to prevent loops. It
comes from the root-MR and can not be deduced from any field in the TIO.

> 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?

If a MR uses that preference in its algorithm (case of a managed
network), then it will be configured appropriately. Case of fire brigade
for instance. The simplest algorithm just uses the least depth to a
grounded tree.  

> 
> 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.
> 
That CRC is not there to validate the packet. It is the checksum of the
careofs to the outside. It is used to detect if the path to the outside
has changed. 

Pascal

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 27 Aug 2004 16:46:25 +0200

Pascal Thubert (pthubert) wrote:
> Alex: the draft is not too thick, please read it better.

Ok, I read it better; it's indeed not thick (16 pages) but there are 
still unclear things...

>>>>> 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.
>>> 
>>> 
>>> belongs to. With nemo basic, it's 1 TIO per RA. TD makes the 
>>> Default Router List an ordered list.
>> 
> 255levels of aggregation can be made?  This is not scalable.
> 

I see no relation between TTL and TreeDepth.  A moving network may offer
an AR that is not its MR, the moving network may introduce more hops
within itself.  Do you have a form of AR-to-MR communication (AR and MR
of same moving network) such as to propagate consistently that TIO
modifications.

> classic stuff?  Why is CRC needed?  Remark RA already has a checksum
>> covering all RA options... This is not efficient.
>> 
> That CRC is not there to validate the packet. It is the checksum of 
> the careofs to the outside. It is used to detect if the path to the 
> outside has changed.

Where does the draft say so?

First, where does the MR CoA come from?  It's not in the TIO.  It's not
in the src field of the RA.  The TreeID is the Home Address initially,
not the CoA.

Second, does CRC-32c algorithm guarantee a unique output for a unique
set of Care-of Addresses?  Not even MD5 does.  This is not efficient.

Third, if one wants to say that something has changed why not simply
sending a bit in the TIO that says "something has changed".  This is
less expensive than computing CRC's...

Alex