Re: [Roll] Way forward for draft-clausen-lln-rpl-experiences

[JP Vasseur <[e-mail]>]

Hi Martin,

co-chair hat off …

How often do you think that ISIS LSA should be refreshed ?
Or OSPF opaque LSA for TE extensions be flooded ?
Or BFD packets ? 
Or PCEP Keepalive when turned on ?

Very seriously … these questions apply to all protocols … and you cannot expect the specifications to give you
hard coded values (but default whenever possible); these are topology and application specific, don't you think ?

Thanks.

Cheers.

JP.

On May 18, 2012, at 10:46 PM, Martin Heusse wrote:

> Phil, 
> what you are writing bellow may be true (although...) but it does not address comment 12, that we have no idea when DAOs should be sent and how DAOs should be handled (how long should the route be kept?). 
> 
> Along those lines, 2 comments:
> 1) I notice that draft-ietf-roll-applicability-ami, for instance, ignores DAOs except for specifying that DAOs SHOULD be sent -- so they might not be sent--, even though "Two-way communication is a requirement"(?). At the same time, this draft goes as far as suggesting what parameters to use for trickle (big deal) or for MaxRankIncrease (big deal: will things break if someone uses 512 instead of 1024?). 
> (same comment applies to draft-gnawali-roll-rpl-recommendations-03.)
> 2) <sarcasm> What is the point of making DAOs compact in storing mode (learning the route recursively) while the packets that actually contain data have to carry the whole path anyway? </sarcasm> 
> 
> Best regards,
> Martin
> 
> 
> Philip Levis wrote:
> 
>> For 12, "implementations may exhibit a bad performance if not carefully implemented."  I think it is safe to say this is true for almost ANY protocol. A specification is not intended to be a complete statement of efficient implementation, otherwise you give little latitude to future improvements and good engineering.
> 
> _______________________________________________
> Roll mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/roll