On Sep 28, 2011, at 5:43 PM, Fred Baker wrote:

> 
> On Sep 28, 2011, at 5:58 PM, Mark Townsley wrote:
> 
>> Since you asked, *I* think that a homenet has functional overlap (what I 
>> called "at least a smaller and slightly different subset" in my email) in 
>> terms of requirements to LLNs. At first blush, it looks like RPL has lots of 
>> functionality - perhaps more than we really need for homenet, and by your 
>> own admission more than you need for LLN's - but will hold reservation on 
>> what I think best fits the bill until we see Fred's analysis, hear from 
>> others, etc. 
> 
> My two yen, which may be all it's worth...
> 
> If I were a Linksys/D-Link/NetGear/* product manager asking about what 
> protocols to put in, I wouldn't be asking about what still exists in Internet 
> Drafts and is thought by the engineers designing it to be better than sliced 
> bread, but about what was inexpensive to implement, likely to be close to 
> bug-free, and definitively accomplished the goal. I note that most routers 
> for the IPv4 residential routing marketplace implement RIPv2; I know of one 
> that implements no routing protocol, one that implements RIPv2 and RIPv1 (!), 
> and one that implements RIPv2 and OSPF (don't ask which they are, I don't 
> remember). This is from a google search of residential routers a few months 
> ago and covered perhaps 20 products from half as many vendors. So my first 
> inclination is to say that for a residential IPv6 network, RIPng is probably 
> an image match for those vendors.
> 
> I have a personal bias in the direction of OSPF or IS-IS; I think that once 
> the code is debugged, SPF-based protocols are more stable (no 
> count-to-infinity), given a reasonable set of defaults generate far more 
> stable networks, and definitively know when there is more than one router on 
> a LAN, which can be important in subnet distribution. 

I spent enough years on OSPF and ISIS to agree with you that these protocols 
are well proven, widely deployed with the number of 
recent improvements (MTR, fast convergence, …) to name a few are particularly 
appealing. But before choosing a routing protocol
the first step consists of listing the requirements. In LLN, as you rightly 
pointed out, "smart objects" have a set of constraints in terms
of resources … far from where we are on traditional routers … Thus I would 
strongly encourage to list the set of requirements for this
type of devices before making any sort of selection on the routing protocol of 
choice, taking into account where we will be in a few years
when the number of these objects will not be limited to a few dozens, the LSDB 
*will* grow … 

> 
> My first choice would NOT be something that isn't proven in the field in 
> multiple interoperable implementations. 
> 
> As a person thinking about making a recommendation, I'd suggest that folks 
> read https://tools.ietf.org/html/rfc2026#section-4.1.2 and ask themselves why 
> that level of interoperability isn't mandatory.
> _______________________________________________
> homenet mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/homenet

_______________________________________________
homenet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet

Reply via email to