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

[JP Vasseur <[e-mail]>]

Hi Thomas,

See below-

On Jun 4, 2012, at 1:25 AM, Thomas Heide Clausen wrote:

> Dear  JP,
> 
> Opaque LSAs are an interesting, although entirely irrelevant, example - an apples-to-oranges comparison. 
> 
> Opaque LSAs are simply "containers for application specific data, for distribution through an OSPF domain (link, area, AS wide)". As such, it's - of course - difficult to specify a transmission frequency; I am sure that we agree that this naturally is an application dependent issue.
> 
> DAOs are much more akin to OSPF HELLO or LSA packets,

JP> I gave several examples … such as BFD packets, PCEP Keepalive; the point that I was making is that any protocol, you cannot 
expect to provide hard coded value for the timers in the specifications, it depends of what you are trying to achieve.

Thanks.

JP.

> in that they pertain to distributing topology proper for the routing protocol operation - specifically, DAOs are not the slightest like opaque LSAs. OSPF does quite specify expectations for when, for example, a HELLO packet should have been received (RouterDeadInterval / InactivityTimer) or LSAs re-flooded (LSRefreshTime).
> 
> In other words, for opaque LSAs, the content of the LSA is opaque to the routing protocol (could be anything), whereas the dissemination process is well defined. Contrast with DAO, where the content is known (and very much important to the routing protocol), alas, the processing and dissemination is opaque and so you need an external mechanism for DAO to work properly.
> 
> I also note a different point, which is that the environment wherein an OSPF router generally operates (accessible, network engineer access during operation) is very different from the environment wherein an RPL router is expected to operate.
> 
> Finally, there are protocols, typically those designed for non-managed deployments. which permit routers with different parameter configurations to interoperate, and then again others where lack of needed information can simply trigger a request for it to be generated.
> 
> Concluding: thus comparing with an information type for a different purpose, extracted from a protocol for a different deployment with constraints of a different nature doesn't really help.
> 
> Best,
> 
> Thomas
> 
> On May 19, 2012, at 12:39 , JP Vasseur wrote:
> 
>> 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
>> 
>> _______________________________________________
>> Roll mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/roll
> 
> _______________________________________________
> Roll mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/roll