[manet] Re: [Autoconf] Fwd: I-D ACTION:draft-chakeres-manet-iana-00.txt

[Christophe Jelger <Christophe.Jelger at unibas.ch>]

Hello Thomas,

Thomas Clausen wrote:
> (...)
>
> Christophe, which complexity is it that you are worried about? The  
> parsing of multi-message packets is something we've done in OLSR  since 
> before RFC3626. The scheduling issues, you can make a scheduler  as 
> complex as you like: taking into account aggregation in a clever  way -- 
> or as simple as you like by simply not doing aggregation.  We've done 
> that in OLSR since before RFC3626 too.

I refered to what you mention when you say "the devil is in the details" 
(i.e. the aggregation scheduler). Of course parsing is not an issue.

> I think it is important, so I will fight very hard ;)
>
> I do not see what different multicast addresses with identical scope  
> for each component would buy us. 

Networking is about exchanging messages between interested parties. I 
just don't buy the idea that each MANET node will have to read and parse 
messages for which it might have "no interest": this sounds like spam to 
me. Moreover having a dedicated mcast addr per protocol is the best 
current practise in the ietf wgs.

> Again, speaking with the OLSRv2-hat,  I 
> definitely would want my TC and HELLO messages to be aggregateable,  and 
> would therefore either say "thou shall send both to generic-manet- 
> mcast-address-XXX", or say "thou shall send both to olsrv2-mcast- 
> address-XXX", but I would *never* want to send them to different  
> addresses.

At the end the draft authors (DYMO, OLSRv2, NHDP) will choose anyway 
what they prefer so that's why I cynically say "I won't fight very hard".

> Anything that would prevent me from aggregating such TCs and HELLOs  
> would, in my opinion, be broken.

I realized that.

> --thomas

_______________________________________________
manet mailing list
manet at ietf.org
https://www1.ietf.org/mailman/listinfo/manet