Re: [homenet] New Version Notification for draft-howard-homenet-routing-comparison-00.txt

[Ray Hunter <[e-mail]>]

How would PIO cope with marginal / ad hoc L2 wireless associations that 
can come and go depending on local radio conditions?
[A can always see B, B can always see C, but A can only sometimes see C]

Unless we're assuming all Homenet inter-router links are wired (which is 
certainly not the case in my house)

AFAIK OSPFv3 has better support for routing over ad hoc wireless links 
if necessary (MANET).

I believe most "traditional" routing protocols cannot cope well with 
this challenge.
e.g IS-IS could fail to elect a Designated Intermediate System visible 
to all nodes.

regards,
RayH


Acee Lindem wrote:
> Hi Lee,
>
> See inline.
>
> On Jan 13, 2012, at 11:49 AM, Howard, Lee wrote:
>
>    
>>      
>>> -----Original Message-----
>>> From: Ray Bellis [mailto:[e-mail]]
>>> Sent: Tuesday, January 03, 2012 8:41 AM
>>> To: Howard, Lee
>>> Cc: [e-mail]
>>> Subject: Re: [homenet] New Version Notification for draft-howard-homenet-routing-
>>> comparison-00.txt
>>>
>>>
>>> On 29 Dec 2011, at 22:33, Howard, Lee wrote:
>>>
>>>        
>>>> I got tired of waiting for someone else to drive consensus on a routing solution
>>>>          
>>> If there is consensus, it's for zOSPF, if only because no-one else appears to believe strongly
>>> enough in their preferred solution to write a draft about it.
>>>        
>> I don't think there's consensus on zOSPF.  I think there are a few strong advocates and a lot of pointed silence I did present an alternative (based on a draft), which had an equal mix of "interesting" and "bleah."
>>      
>
> First let's quit calling it zOSPF. It is OSPFv3 with auto-configuration.
>
>    
>> The problem with zOSPF is that it doesn't meet our requirements.  It doesn't detect borders (unless the border happens to have another zOSPF router with the wrong password),
>>      
>
> While this should be part of the solution, I don't see this as something that it necessarily should be built into the routing protocol.
>
>    
>> it requires configuration (for the password),
>>      
>
> How does any protocol do authentication w/o a shared key? If you don't do authentication, you don't need a key.
>
>    
>> it doesn't handle walled gardens (a requirement being debated),
>>      
>
> I don't fully understand this requirement and how it would be handled w/o configuration.
>
>    
>> it's not lightweight.
>>      
>
> A commercial router implementation supporting all the features including OSPF TE and VPNs is certainly not lightweight. However, I just downloaded the latest quagga suite and it is only about 21K there.
>
> Acee-Lindems-iMac-2:ospf6d ealflin$ wc -l  *.[c.h]
>       875 ospf6_abr.c
>        78 ospf6_abr.h
>       787 ospf6_area.c
>       129 ospf6_area.h
>      1270 ospf6_asbr.c
>        95 ospf6_asbr.h
>      1027 ospf6_flood.c
>        66 ospf6_flood.h
>      1654 ospf6_interface.c
>       154 ospf6_interface.h
>      1578 ospf6_intra.c
>       220 ospf6_intra.h
>      1019 ospf6_lsa.c
>       254 ospf6_lsa.h
>       582 ospf6_lsdb.c
>        98 ospf6_lsdb.h
>       348 ospf6_main.c
>      2548 ospf6_message.c
>       149 ospf6_message.h
>       945 ospf6_neighbor.c
>       137 ospf6_neighbor.h
>       322 ospf6_network.c
>        50 ospf6_network.h
>        85 ospf6_proto.c
>       122 ospf6_proto.h
>      1409 ospf6_route.c
>       305 ospf6_route.h
>       535 ospf6_snmp.c
>        29 ospf6_snmp.h
>       701 ospf6_spf.c
>        94 ospf6_spf.h
>       707 ospf6_top.c
>        78 ospf6_top.h
>       697 ospf6_zebra.c
>        51 ospf6_zebra.h
>      1892 ospf6d.c
>       125 ospf6d.h
>     21215 total
>
> I'm not sure about commercial deployments, but I know this distribution has been used as the basis for network research.
>
> Thanks,
> Acee
>
>
>    
>> I'm trying to be fair, and not just protect the PIO proposal because I proposed it.  It needs work.  Its biggest lack is the need for hierarchical addressing, but I think draft-baker-homenet-prefix-assignment solves that.  I don't want to see zOSPF adopted just because its advocates were louder.
>>
>>      
>>> I think Mark and I will need to make that call quite soon, but probably not until the authors
>>> of the architecture draft have incorporated the routing requirements and other comments
>>> since Taipei and put those into -01.
>>>        
>> My perception is that we have three people in favor of zOSPF, three supporting a PIO, seven each supporting a different alternative, and 30 silent.
>>
>> Lee
>>
>>
>> This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.
>> _______________________________________________
>> homenet mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/homenet
>>      
>
>
>