[homenet] Thoughts about routing

[Fred Baker]

Slides from the talk today are at 
http://trac.tools.ietf.org/wg/homenet/trac/attachment/wiki/WikiStart/Homenet%20Routing.pdf.
 I used them to lead a structured discussion of routing technologies 
appropriate in Home and small Office (SOHO) networks, with a view to 
requirements for selection of a routing protocol to "RECEOMMEND" (RFC 2119 
language) that Homenet router vendors implement. This is in part to document a 
discussion we had in the room and in part to lead it into list discussion.

As one might expect, a lot of the discussion was non-controversial. Points that 
raised discussion started with the issue of multihoming as shown on slide 9. A 
question arose on how multi-address interfaces work on typical operating 
systems including Windows, MacOSX, and various Linux variants. It was observed 
that rather than actually forming an address in each prefix as one would expect 
in a multi-prefix network, Linux sees the various prefixes advertised in an RA 
and selects one, forms an address in it, and uses that address until it 
expires. Per RFC 4861, the lifetime on such a prefix is the same as the 
lifetime on the IA_PD granted by the upstream network, which is generally on 
the order of weeks. In the event that we have multiple routers to multiple 
upstream networks each advertising a prefix and one fails - not just the link, 
but the router and therefore the DHCPv6 server in it - the host will continue 
using that prefix until it is actively rescinded.

A number of folks in the room had a discussion during a break about a related 
scenario, and concocted the idea of an "RA Server"; if there are multiple 
routers to multiple upstream networks and therefore advertising prefixes, one 
of them should advertise all of the prefixes, and if the route to any given 
prefix fails (including if the RA Server fails and another takes over the 
function) should remove the prefix from use. In a network using OSPF/IS-IS, the 
obvious router to perform this function might be the Designated Router.

After completing the slides, I made the following statement and opened it for 
discussion: "If I were to make a call today, given the facts in evidence, I 
would want a routing protocol with a high quality open source implementation 
that was proven and documented interoperable with other implementations, and 
which had the necessary characteristics to recover from failures in a period on 
the order of tens of seconds to minutes as opposed to tens of minutes. I would 
recommend either RIPng or OSPFv3, and recommend RPL for 802.15.4 interfaces."

Four comments/discussions came out quickly, and as near as I can tell 
represented viewpoints common in the room.

1) why recommend a routing protocol at all?

I suggested that the probability of use of each of the scenarios on slide 4 were
 single router network: 90th percentile
 tree network:  unusual
 multi-router:  perhaps 5th percentile
 multihomed:unusual

The discussion in the room elevated the multi-homed case, due to corporate 
information security requirements that required an employee's home office to 
use a given network, the presence of TV-bearing and mobile telephone networks, 
and so on. The argument for recommending any protocol at all has to do with the 
zeroconf requirement and the interoperation requirement; if you actually have 
multiple routers in the home, it would be nice if they could exchange routes.

2) Networks calling for other protocols

The room found the requirements of the Smart Grid HAN unconvincing. In summary, 
the sense of the room was that one might sell a router that interfaced a RPL 
network to an OSPF network in the rest of the home; ths might be in a special 
purpose "interior" router, a function of the ESI, or on the CPE Router itself.

3) Why even bring up RIPng?

I bring it up because it is RIPv2 warmed over, and the majority of residential 
routers I surveyed some months back support RIPv2; I expect it is an image 
match to the expectations of companies that make consumer-grade routers, and 
for simple scenarios works "well enough". That said, documents such as RFC 1812 
recommend implementation of OSPF due to its characteristics with respect to 
timing. The sense of the room favored implementation of OSPFv3 over RIPng, and 
suggested that someone look hard at 
http://tools.ietf.org/html/draft-dimitri-zospf with respect to prefix 
management; one wants a well tested and proven-interoperable OSPFv3 
implementation (with OSPFv3 itself at Draft Standard with respect to the 
requirements of RFC 2026) that can also perform subnet prefix management.

There was discussion of a protocol profile; not only place all interfaces into 
area zero by default, but remove the capability for multiple areas and 
advertise the /64 allocated to RPL (if present) in an OSPFv3 type 9 record 
along with the other prefixes on the router. How much of the implementation 
could disappear (the LSDB would now only contain R

Re: [homenet] Thoughts about routing

[Jari Arkko]

Fred,

Thanks for the excellent summary!

I'm in the camp that believes we do need an automatic routing mechanism. Maybe 
it is because I'm in the 5% percentile, maybe it is because I believe we'll see 
more guest/private and non-bridgeable subnets. (At the end of the day, I think 
an open Internet model for all devices will win, and we may be able to get rid 
of guest/private. But at the same time I think we need an answer on how to do 
current network models in IPv6 when the IPv4 answer is adding another NAT. If 
we do not have an answer, a copy of the IPv4 network model will emerge for 
IPv6.)

In any case, I think the choice of a routing mechanism is a practical question. 
What can we realistically expect devices to do. Your data points to RIP, but 
one significant point from yesterday's discussions was that it might be easier 
to do internal network prefix assignment in general topologies with a link 
state routing mechanism. I still worry that we try to optimize too much or aim 
too high with our expectations of functionality. Perhaps something simpler 
would work for prefix assignment and we could just do what most devices already 
have in their code, i.e., RIP. The IETF is often in a danger of inventing new 
solutions as we are protocol engineers, and then failing to get the new stuff 
deployed. But I also like OSPF a lot, and I think it would be a very elegant 
solution. I'm going to see if I can put it into my network, with some prefix 
assignment solution.

I would like to see a recommendation for one protocol though. Something that we 
would expect most home routers to support in the future. I think that 
recommendation needs to be for a general purpose routing protocol that we have 
years and years of experience with.

(We'll of course see some additional things in many networks, too. One topic that has been raised often is LLN and ad hoc routing protocols. These can naturally be accommodated where needed, as the current models in RPL, for instance, call for a border router that can do the necessary per-packet encap and speak RPL. Such a border router should also be a homenet router and be capable of participating in the routing and prefix allocation tasks with the rest of the home network. But I think it would be a mistake to adopt one of the ad hoc network protocols as the basic protocol to run in all home networks. Speaking personally, I would at least like to stick with more traditional solutions and skip the special encap and other things that may come with other designs. For the record, I'm probably as sensor networked as you can be, but I do not use ad hoc routing protocols because I happen to do all my sensor networking with link types -- WLAN, wired, cellular -- that do not call 
for anything special. I know there are other types of situations, but wanted to provide an example of LLN networking that runs in a more traditional architecture.)


Question: Yesterday we talked a little bit about what it means for the routing 
to be turned on automatically. Prefix assignment based on your delegation from 
the ISP is one part of it. What else do we need? Is this just a matter of 
making our home router devices have OSPF on by default, and as soon as the 
device gets its prefix it will start advertising it in the routing protocol?

Jari


___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Thoughts about routing

[Fred Baker]

On Oct 7, 2011, at 5:25 AM, Jari Arkko wrote:

> Question: Yesterday we talked a little bit about what it means for the 
> routing to be turned on automatically. Prefix assignment based on your 
> delegation from the ISP is one part of it. What else do we need? Is this just 
> a matter of making our home router devices have OSPF on by default, and as 
> soon as the device gets its prefix it will start advertising it in the 
> routing protocol?

For the most part, yes. Most of the parameters that OSPF requires have defaults 
specified in the RFC, and while they may or may not be perfect they're not bad. 
In managed configurations (SP, Enterprise, etc) folks twiddle the frequency of 
Hello messages, with a view to quickly detecting a failure; IIRC, OSPF by 
default determines that a neighbor is lost after 4 missed hellos or a link-down 
event, so in the worst case this is 50 seconds from the receipt of the previous 
successful message. I doubt that's a real issue in residential/SOHO networks.

The other parameters in question include 
  - the interface prefix itself, which could be derived as in zospf, 
  - the area number (I'd suggest it default to zero), 
  - the router ID (a random 32 bit number), and 
  - security information. 

I'd suggest that security information be akin to security on an SSID - pester 
the user until he gives you something. zospf may have a comment on security, I 
don't recall. The Router ID in IPv4 networks is often one of the IPv4 
addresses; for IPv6, it could be derived from a MAC address, a serial number, 
or anything else as long as it is unique within the routing domain.

>From my perspective, turning on OSPF by default means that the router will not 
>start actually routing until 40 seconds after it is turned on (OSPF start-up), 
>and will otherwise mean that it beeps on the LAN every ten seconds; the 
>message is in the multicast group ALL-OSPF-ROUTERS, which only other routers 
>should be listening to. By comparison, your favorite 802.1 switch beeps a BPDU 
>on every interface once per second.

I personally have no issue with OSPF given a rational set of defaults and an 
acceptable implementation.
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Thoughts about routing

[Jari Arkko]

Thanks. Makes sense.

Jari

On 07.10.2011 06:28, Fred Baker wrote:

On Oct 7, 2011, at 5:25 AM, Jari Arkko wrote:


Question: Yesterday we talked a little bit about what it means for the routing 
to be turned on automatically. Prefix assignment based on your delegation from 
the ISP is one part of it. What else do we need? Is this just a matter of 
making our home router devices have OSPF on by default, and as soon as the 
device gets its prefix it will start advertising it in the routing protocol?

For the most part, yes. Most of the parameters that OSPF requires have defaults 
specified in the RFC, and while they may or may not be perfect they're not bad. 
In managed configurations (SP, Enterprise, etc) folks twiddle the frequency of 
Hello messages, with a view to quickly detecting a failure; IIRC, OSPF by 
default determines that a neighbor is lost after 4 missed hellos or a link-down 
event, so in the worst case this is 50 seconds from the receipt of the previous 
successful message. I doubt that's a real issue in residential/SOHO networks.

The other parameters in question include
   - the interface prefix itself, which could be derived as in zospf,
   - the area number (I'd suggest it default to zero),
   - the router ID (a random 32 bit number), and
   - security information.

I'd suggest that security information be akin to security on an SSID - pester 
the user until he gives you something. zospf may have a comment on security, I 
don't recall. The Router ID in IPv4 networks is often one of the IPv4 
addresses; for IPv6, it could be derived from a MAC address, a serial number, 
or anything else as long as it is unique within the routing domain.

 From my perspective, turning on OSPF by default means that the router will not 
start actually routing until 40 seconds after it is turned on (OSPF start-up), 
and will otherwise mean that it beeps on the LAN every ten seconds; the message 
is in the multicast group ALL-OSPF-ROUTERS, which only other routers should be 
listening to. By comparison, your favorite 802.1 switch beeps a BPDU on every 
interface once per second.

I personally have no issue with OSPF given a rational set of defaults and an 
acceptable implementation.


___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Thoughts about routing

[Fred Baker]

On Oct 7, 2011, at 3:48 AM, Fred Baker wrote:
> As one might expect, a lot of the discussion was non-controversial. Points 
> that raised discussion started with the issue of multihoming as shown on 
> slide 9. A question arose on how multi-address interfaces work on typical 
> operating systems including Windows, MacOSX, and various Linux variants. It 
> was observed that rather than actually forming an address in each prefix as 
> one would expect in a multi-prefix network, Linux sees the various prefixes 
> advertised in an RA and selects one, forms an address in it, and uses that 
> address until it expires. Per RFC 4861, the lifetime on such a prefix is the 
> same as the lifetime on the IA_PD granted by the upstream network, which is 
> generally on the order of weeks. In the event that we have multiple routers 
> to multiple upstream networks each advertising a prefix and one fails - not 
> just the link, but the router and therefore the DHCPv6 server in it - the 
> host will continue using that prefix until it is actively rescinded.

Speaking strictly for myself, here, this seems actively broken in several ways. 
First, if the design of IPv6 calls for an address in each prefix advertised in 
an RA, what would it take to get Windows, MacOSX, FreeBSD, Linux, Linux, Linux, 
and Linux to do that? All discussion of RFC 3484 seems wasted if the device has 
exactly one address.

But also, the notion of tying the lifetime of a prefix on the LAN with the 
lifetime of the prefix grant seems ill-considered. The purpose of the lifetime 
on the prefix grant (RFC 3363) is to enable an upstream to not need to be asked 
every 30 seconds for something it wants to leave unchanged for a long period of 
time and yet make "a long time" not be "forever". That's reasonable. But in the 
case called out here, it seems like the lifetime of the prefix in an RA should 
be long enough that a host can miss an RA refresh and not lose the address, and 
short enough that we don't have to call in the national guard if someone trips 
over a cable or a power supply goes spitzensparken.

What do we need to do to change that RFC 4861 requirement? If what is required 
is an Internet Draft in 6man (and I would expect it is), I'd be willing to 
write that draft.
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Thoughts about routing

[Thomas Narten]

Fred Baker  writes:

> It was observed that rather than actually forming an address in each
> prefix as one would expect in a multi-prefix network, Linux sees the
> various prefixes advertised in an RA and selects one, forms an
> address in it, and uses that address until it expires.

I'd be surprised if this was in fact what Linux did. This would be a
complete violation of existing specs.

And, I'm sure that the the IPv6 Ready Logo/USGv6 tests would flag such
an implementation as broken.

But indeed, a number of linux implementations have tested successfully
for USGv6 at UNH.

E.g., if you look at
http://www.iol.unh.edu/services/testing/ipv6/usgv6tested.php

It shows SUSE and RHE as having passed the IPv6 tests.

Why do people think that Linux doesn't follow the specs when it comes
to forming addresses via stateless autoconfiguration?

Thomas

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Thoughts about routing

[Fred Baker]

I'll let those who raised the concern respond.

On Oct 7, 2011, at 8:31 AM, Thomas Narten wrote:

> Fred Baker  writes:
> 
>> It was observed that rather than actually forming an address in each
>> prefix as one would expect in a multi-prefix network, Linux sees the
>> various prefixes advertised in an RA and selects one, forms an
>> address in it, and uses that address until it expires.
> 
> I'd be surprised if this was in fact what Linux did. This would be a
> complete violation of existing specs.
> 
> And, I'm sure that the the IPv6 Ready Logo/USGv6 tests would flag such
> an implementation as broken.
> 
> But indeed, a number of linux implementations have tested successfully
> for USGv6 at UNH.
> 
> E.g., if you look at
> http://www.iol.unh.edu/services/testing/ipv6/usgv6tested.php
> 
> It shows SUSE and RHE as having passed the IPv6 tests.
> 
> Why do people think that Linux doesn't follow the specs when it comes
> to forming addresses via stateless autoconfiguration?
> 
> Thomas
> 
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Thoughts about routing

[Jari Arkko]

Fred,



As one might expect, a lot of the discussion was non-controversial. Points that 
raised discussion started with the issue of multihoming as shown on slide 9. A 
question arose on how multi-address interfaces work on typical operating 
systems including Windows, MacOSX, and various Linux variants. It was observed 
that rather than actually forming an address in each prefix as one would expect 
in a multi-prefix network, Linux sees the various prefixes advertised in an RA 
and selects one, forms an address in it, and uses that address until it 
expires. Per RFC 4861, the lifetime on such a prefix is the same as the 
lifetime on the IA_PD granted by the upstream network, which is generally on 
the order of weeks. In the event that we have multiple routers to multiple 
upstream networks each advertising a prefix and one fails - not just the link, 
but the router and therefore the DHCPv6 server in it - the host will continue 
using that prefix until it is actively rescinded.

Speaking strictly for myself, here, this seems actively broken in several ways. 
First, if the design of IPv6 calls for an address in each prefix advertised in 
an RA, what would it take to get Windows, MacOSX, FreeBSD, Linux, Linux, Linux, 
and Linux to do that? All discussion of RFC 3484 seems wasted if the device has 
exactly one address.


Linux actually does configure multiple addresses, and seems capable of using 
them in different situations. Maybe yesterday's comment about Linux behavior 
was more about what it does when a set of addresses has no clear preference 
(RFC 3484 or otherwise. My experience is that it does then use one 
address/router unless something changes. (Indeed, this is often problem as an 
earlier version had a bug that old networks didn't go down despite moving to a 
new network, and if I happened to use the old router's address I was having a 
bad day.)




But also, the notion of tying the lifetime of a prefix on the LAN with the lifetime of the prefix 
grant seems ill-considered. The purpose of the lifetime on the prefix grant (RFC 3363) is to enable 
an upstream to not need to be asked every 30 seconds for something it wants to leave unchanged for 
a long period of time and yet make "a long time" not be "forever". That's 
reasonable. But in the case called out here, it seems like the lifetime of the prefix in an RA 
should be long enough that a host can miss an RA refresh and not lose the address, and short enough 
that we don't have to call in the national guard if someone trips over a cable or a power supply 
goes spitzensparken.

What do we need to do to change that RFC 4861 requirement? If what is required 
is an Internet Draft in 6man (and I would expect it is), I'd be willing to 
write that draft.



I was scanning RFC 4861 and did not see anything about IA_PD or delegation, 
just saw a 30 day default value for the valid lifetime. Where is the text that 
you would like to change?

Jari


___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Thoughts about routing

[Ralph Droms]

On Oct 7, 2011, at 8:41 AM, Jari Arkko  wrote:

> Fred,
> 
> 
>>> As one might expect, a lot of the discussion was non-controversial. Points 
>>> that raised discussion started with the issue of multihoming as shown on 
>>> slide 9. A question arose on how multi-address interfaces work on typical 
>>> operating systems including Windows, MacOSX, and various Linux variants. It 
>>> was observed that rather than actually forming an address in each prefix as 
>>> one would expect in a multi-prefix network, Linux sees the various prefixes 
>>> advertised in an RA and selects one, forms an address in it, and uses that 
>>> address until it expires. Per RFC 4861, the lifetime on such a prefix is 
>>> the same as the lifetime on the IA_PD granted by the upstream network, 
>>> which is generally on the order of weeks. In the event that we have 
>>> multiple routers to multiple upstream networks each advertising a prefix 
>>> and one fails - not just the link, but the router and therefore the DHCPv6 
>>> server in it - the host will continue using that prefix until it is 
>>> actively rescinded.
>> Speaking strictly for myself, here, this seems actively broken in several 
>> ways. First, if the design of IPv6 calls for an address in each prefix 
>> advertised in an RA, what would it take to get Windows, MacOSX, FreeBSD, 
>> Linux, Linux, Linux, and Linux to do that? All discussion of RFC 3484 seems 
>> wasted if the device has exactly one address.
> 
> Linux actually does configure multiple addresses, and seems capable of using 
> them in different situations. Maybe yesterday's comment about Linux behavior 
> was more about what it does when a set of addresses has no clear preference 
> (RFC 3484 or otherwise. My experience is that it does then use one 
> address/router unless something changes. (Indeed, this is often problem as an 
> earlier version had a bug that old networks didn't go down despite moving to 
> a new network, and if I happened to use the old router's address I was having 
> a bad day.)
> 
> 
>> 
>> But also, the notion of tying the lifetime of a prefix on the LAN with the 
>> lifetime of the prefix grant seems ill-considered. The purpose of the 
>> lifetime on the prefix grant (RFC 3363) is to enable an upstream to not need 
>> to be asked every 30 seconds for something it wants to leave unchanged for a 
>> long period of time and yet make "a long time" not be "forever". That's 
>> reasonable. But in the case called out here, it seems like the lifetime of 
>> the prefix in an RA should be long enough that a host can miss an RA refresh 
>> and not lose the address, and short enough that we don't have to call in the 
>> national guard if someone trips over a cable or a power supply goes 
>> spitzensparken.
>> 
>> What do we need to do to change that RFC 4861 requirement? If what is 
>> required is an Internet Draft in 6man (and I would expect it is), I'd be 
>> willing to write that draft.
>> 
> 
> I was scanning RFC 4861 and did not see anything about IA_PD or delegation, 
> just saw a 30 day default value for the valid lifetime. Where is the text 
> that you would like to

The text in question may be in RFC 3633, section 12.1, which requires that the 
valid lifetime for the prefix in the RA must be no later than the valid 
lifetime in the IA_PD. 

- Ralph

> change?
> 
> Jari
> 
> 
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Thoughts about routing

[Ole Troan]

> A number of folks in the room had a discussion during a break about a related 
> scenario, and concocted the idea of an "RA Server"; if there are multiple 
> routers to multiple upstream networks and therefore advertising prefixes, one 
> of them should advertise all of the prefixes, and if the route to any given 
> prefix fails (including if the RA Server fails and another takes over the 
> function) should remove the prefix from use. In a network using OSPF/IS-IS, 
> the obvious router to perform this function might be the Designated Router.

I think as a general principle addressing is independent of routing. and that 
we should not as a result of loss of reachability deprecate an address. every 
address, global or not has different reachability and a host has to handle it.

cheers,
Ole



___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Thoughts about routing

[Jari Arkko]

Ralph,


The text in question may be in RFC 3633, section 12.1, which requires that the 
valid lifetime for the prefix in the RA must be no later than the valid 
lifetime in the IA_PD.




Ah. The full text says:

   ... the requesting router MUST
   set the valid lifetime in those advertisements to be no later than
   the valid lifetime specified in the IA_PD Prefix option.  A
   requesting router MAY use the preferred lifetime specified in the
   IA_PD Prefix option.

I think this is fine, and allows the implementation to do the sensible thing. 
You can put in a smaller time. You can use the exact lease time. You would only 
get into trouble if the PD lease times where insanely small. Fixing that 
requires the operator to notice, and cannot be fixed in IETF specifications. In 
any case, we don't have a huge amount of PD deployment yet, so additional 
practical guidance on what kind of values to use within the rules specified 
above can be useful and might have an impact on what people actually do. 
Personally, I think its rather obvious, but I could of course be missing 
something.

(I'm walking to the meeting site now. I had a day job conference call in the 
morning... Hope you solved all the problems in the morning session already :-)

Jari

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Thoughts about routing

[Erik Nordmark]

On 10/7/11 12:48 AM, Fred Baker wrote:

I suggested that the probability of use of each of the scenarios on slide 4 were
  single router network: 90th percentile
  tree network:  unusual
  multi-router:  perhaps 5th percentile
  multihomed:unusual


Fred,

are the above numbers based on any survey data?

Reason I'm asking is that I have two consumer devices with IPv4 NAT in 
my home (a VoIP box and a backup device) where the instructions said:
1. Insert between or existing router (or PC if you have no router) and 
the DSL/cable modem
2. Insert between your PC and your existing router (or modem if you have 
no router)


Those consumer instructions naturally result in a daisy-chain of IPv4 
RGs/NATs, which is a subset of a tree topology.


I can't be the only person who have a VoIP box or a Time Capsule.

   Erik
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Thoughts about routing

[Erik Nordmark]

On 10/7/11 3:28 AM, Fred Baker wrote:

The other parameters in question include
   - the interface prefix itself, which could be derived as in zospf,
   - the area number (I'd suggest it default to zero),
   - the router ID (a random 32 bit number), and
   - security information.


Fred,

Do existing OSPF implementations have the ability to pick a random 
router ID, and detect when there is a router ID collision?


One benefit of using IS-IS is that the router ID is longer and based on 
a factory-assigned IEEE MAC address.


The zospf appears to have an approach for router ID collisions, but that 
probably isn't (widely) implemented.


(In any case, we'd need to figure out what it means to have stable 
prefixes allocated - to interfaces or to links - but that is the prefix 
autoconfig part of the problem as opposed to the router config part of 
the problem.)


   Erik

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Thoughts about routing

[Fred Baker]

On Oct 7, 2011, at 6:52 PM, Erik Nordmark wrote:

> On 10/7/11 12:48 AM, Fred Baker wrote:
>> I suggested that the probability of use of each of the scenarios on slide 4 
>> were
>>  single router network: 90th percentile
>>  tree network:  unusual
>>  multi-router:  perhaps 5th percentile
>>  multihomed:unusual
> 
> Fred,
> 
> are the above numbers based on any survey data?

They are as scientific as the end of my thumb :-)

> Reason I'm asking is that I have two consumer devices with IPv4 NAT in my 
> home (a VoIP box and a backup device) where the instructions said:
> 1. Insert between or existing router (or PC if you have no router) and the 
> DSL/cable modem
> 2. Insert between your PC and your existing router (or modem if you have no 
> router)
> 
> Those consumer instructions naturally result in a daisy-chain of IPv4 
> RGs/NATs, which is a subset of a tree topology.
> 
> I can't be the only person who have a VoIP box or a Time Capsule.
> 
>   Erik

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Thoughts about routing

[Fred Baker]

On Oct 7, 2011, at 6:55 PM, Erik Nordmark wrote:

> On 10/7/11 3:28 AM, Fred Baker wrote:
>> The other parameters in question include
>>   - the interface prefix itself, which could be derived as in zospf,
>>   - the area number (I'd suggest it default to zero),
>>   - the router ID (a random 32 bit number), and
>>   - security information.
> 
> Fred,
> 
> Do existing OSPF implementations have the ability to pick a random router ID, 
> and detect when there is a router ID collision?

OSPFv2 implementations generally pick one of the IPv4 addresses of the system. 
Not sure I can make a general comment on OSPFv3.

> One benefit of using IS-IS is that the router ID is longer and based on a 
> factory-assigned IEEE MAC address.

> The zospf appears to have an approach for router ID collisions, but that 
> probably isn't (widely) implemented.

ZOSPF is, AFAIK, an internet draft that has never been implemented.

> (In any case, we'd need to figure out what it means to have stable prefixes 
> allocated - to interfaces or to links - but that is the prefix autoconfig 
> part of the problem as opposed to the router config part of the problem.)
> 
>   Erik
> 

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Thoughts about routing

[Michael Richardson]

> "Erik" == Erik Nordmark  writes:
Erik> Reason I'm asking is that I have two consumer devices with
Erik> IPv4 NAT in my home (a VoIP box and a backup device) where the
Erik> instructions said: 1. Insert between or existing router (or PC
Erik> if you have no router) and the DSL/cable modem 2. Insert
Erik> between your PC and your existing router (or modem if you have
Erik> no router)

Erik> Those consumer instructions naturally result in a daisy-chain
Erik> of IPv4 RGs/NATs, which is a subset of a tree topology.

That's a good point:  many VoIP ATAs want to be the first device so that
they can control the QoS, and ideally get the public IP address.

Does your VoIP box do PPPoE as well?  
Or did I misunderstand.

-- 
]   He who is tired of Weird Al is tired of life!   |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON|net architect[
] m...@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video 
   then sign the petition. 







pgp2E9q708fWf.pgp
Description: PGP signature
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Thoughts about routing

[Ole Troan]

Erik,

> The zospf appears to have an approach for router ID collisions, but that 
> probably isn't (widely) implemented.

indeed. zospf or whatever combination of zeroconf OSPF plus OSPF prefix 
assignment is new work.

> (In any case, we'd need to figure out what it means to have stable prefixes 
> allocated - to interfaces or to links - but that is the prefix autoconfig 
> part of the problem as opposed to the router config part of the problem.)

right. we should aim for a stable prefix given no topology changes. if a link 
partitions and merges there will have to be renumbering.
I think this will require stable storage, regardless of this being done via 
DHCP and a God server or via an autonomous approach like zOSPF.

cheers,
Ole



___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Thoughts about routing

[Acee Lindem]

On Oct 7, 2011, at 10:17 PM, Fred Baker wrote:

> 
> On Oct 7, 2011, at 6:55 PM, Erik Nordmark wrote:
> 
>> On 10/7/11 3:28 AM, Fred Baker wrote:
>>> The other parameters in question include
>>>  - the interface prefix itself, which could be derived as in zospf,
>>>  - the area number (I'd suggest it default to zero),
>>>  - the router ID (a random 32 bit number), and
>>>  - security information.
>> 
>> Fred,
>> 
>> Do existing OSPF implementations have the ability to pick a random router 
>> ID, and detect when there is a router ID collision?
> 
> OSPFv2 implementations generally pick one of the IPv4 addresses of the 
> system. Not sure I can make a general comment on OSPFv3.

Since OSPFv3 also uses a 4 byte router ID, our implementation will use the same 
algorithm for picking a router ID as OSPFv2. 


> 
>> One benefit of using IS-IS is that the router ID is longer and based on a 
>> factory-assigned IEEE MAC address.
> 
>> The zospf appears to have an approach for router ID collisions, but that 
>> probably isn't (widely) implemented.
> 
> ZOSPF is, AFAIK, an internet draft that has never been implemented.

Agreed. The 2002 draft died with its expiration in 2003. 

Acee

> 
>> (In any case, we'd need to figure out what it means to have stable prefixes 
>> allocated - to interfaces or to links - but that is the prefix autoconfig 
>> part of the problem as opposed to the router config part of the problem.)
>> 
>>  Erik
>> 
> 
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Thoughts about routing

[Fred Baker]

On Oct 9, 2011, at 8:01 PM, Acee Lindem wrote:

> Since OSPFv3 also uses a 4 byte router ID, our implementation will use the 
> same algorithm for picking a router ID as OSPFv2. 

which is to say "any old thing it wants, quite often an IPv4 address"?
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Thoughts about routing

[Acee Lindem]

On Oct 9, 2011, at 8:41 PM, Fred Baker wrote:

> 
> On Oct 9, 2011, at 8:01 PM, Acee Lindem wrote:
> 
>> Since OSPFv3 also uses a 4 byte router ID, our implementation will use the 
>> same algorithm for picking a router ID as OSPFv2. 
> 
> which is to say "any old thing it wants, quite often an IPv4 address"?


Correct, it uses the best or only configured IPv4 address in the context (aka, 
virtual router). Of course, we'd want to use something else for true 
auto-configuration. 

Thanks,
Acee 
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Thoughts about routing

[Mark Townsley]

On Oct 9, 2011, at 8:53 PM, Acee Lindem wrote:

> 
> On Oct 9, 2011, at 8:41 PM, Fred Baker wrote:
> 
>> 
>> On Oct 9, 2011, at 8:01 PM, Acee Lindem wrote:
>> 
>>> Since OSPFv3 also uses a 4 byte router ID, our implementation will use the 
>>> same algorithm for picking a router ID as OSPFv2. 
>> 
>> which is to say "any old thing it wants, quite often an IPv4 address"?
> 
> 
> Correct, it uses the best or only configured IPv4 address in the context 
> (aka, virtual router). Of course, we'd want to use something else for true 
> auto-configuration. 

And, homenet is of course required to be able to operate in absence of IPv4 as 
well as dual-stack

- Mark

> 
> Thanks,
> Acee 
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Thoughts about routing

[Fred Baker]

On Oct 9, 2011, at 8:53 PM, Acee Lindem wrote:

> Correct, it uses the best or only configured IPv4 address in the context 
> (aka, virtual router). Of course, we'd want to use something else for true 
> auto-configuration. 

Yes. For my money, in the absence of an IPv4 configuration, that's probably 
derived from a MAC Address, a serial number, or something else that is an 
attribute of the bit of equipment. But apart from observing on possible 
sources, Jon Moy would probably put on an animated look and observe that the 
router id is a 32 bit number unique in the routing domain, not necessarily an 
address of any kind.

A tiny bit of history here. Back in 1991 when we were doing the testing that 
resulted in RFC 1246, we (the implementers of 23 different implementations, 
many of which were derivative from the Maryland Prototype, e.g. Rob Coltun's 
code) had a discussion about where the router id should come from, and I 
commented that I had doctored my implementation to select one of the IPv4 
addresses in the area. What I just described was the discussion that followed. 
Maybe everyone else had already made the same choice, or maybe they changed 
their code soon after, but using one of the IPv4 addresses in the area was 
suddenly a pretty common solution. :-)


___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Thoughts about routing

[STARK, BARBARA H]

The subset of tree topology where a consumer places ones router behind
another router is *extremely* common. Statistics I saw several years ago
suggested that probably about 60% of ADSL customers in the US use this
topology. The most common cause for this topology is where the service
provider supplies a free ADSL router with a single port to a subscriber,
and the subscriber then puts their own multi-port router behind that
router. The ADSL router is configured to do the PPPoE, and is also
configured to automatically provide whatever public IP address it gets
to whatever is behind it (via DHCPv4, as a sort of automatic DMZ
function -- the ADSL router also uses that public IP address for its
needs). The ADSL router is often set to provide only that one address,
and not to support a full network of devices. Which is why consumers are
forced to use their own router. This also tends to be how VoIP router +
consumer's wireless router topology works.

I'm sure some people would like to argue as to why this is bad, or it
shouldn't be done. I'm not going to get into that argument. That
argument is irrelevant. The fact is that it's very, very common. 

I agree with those who say that we *don't* need to make sure IPv4 works
everywhere that IPv6 works.
But I think it's an absolute requirement that IPv6 MUST work everywhere
that IPv4 works.

And this is a very common case where IPv4 works. When going to IPv6, the
ADSL router will also be the device that establishes the IPv6
connection. Because the credentials are the same as for IPv4, and the
secondary router doesn't have those credentials. And the consumer forgot
the credentials long ago, and doesn't remember how to configure this
stuff anyway.

IMO, I believe that the best approach would be to solve tree
generically. Which means that the probability of "tree network" would
actually be "common, perhaps 30th percentile" (dividing my "60% in ADSL
networks" by 2).
Barbara

> -Original Message-
> On 10/7/11 12:48 AM, Fred Baker wrote:
> > I suggested that the probability of use of each of the scenarios on
> slide 4 were
> >   single router network: 90th percentile
> >   tree network:  unusual
> >   multi-router:  perhaps 5th percentile
> >   multihomed:unusual
> 
> Fred,
> 
> are the above numbers based on any survey data?
> 
> Reason I'm asking is that I have two consumer devices with IPv4 NAT in
> my home (a VoIP box and a backup device) where the instructions said:
> 1. Insert between or existing router (or PC if you have no router) and
> the DSL/cable modem
> 2. Insert between your PC and your existing router (or modem if you
> have
> no router)
> 
> Those consumer instructions naturally result in a daisy-chain of IPv4
> RGs/NATs, which is a subset of a tree topology.
> 
> I can't be the only person who have a VoIP box or a Time Capsule.
> 
> Erik
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Thoughts about routing

[Jari Arkko]

Barbara,

Thank you very much for providing a concrete data point! I also agree with what 
you say below:


I'm sure some people would like to argue as to why this is bad, or it
shouldn't be done. I'm not going to get into that argument. That
argument is irrelevant. The fact is that it's very, very common.

I agree with those who say that we*don't*  need to make sure IPv4 works
everywhere that IPv6 works.
But I think it's an absolute requirement that IPv6 MUST work everywhere
that IPv4 works.


Jari

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Thoughts about routing

[Fred Baker]

Thanks. That is a big update to my numbers, but one that is important here.

On Oct 10, 2011, at 10:18 AM, STARK, BARBARA H wrote:

> The subset of tree topology where a consumer places ones router behind
> another router is *extremely* common. Statistics I saw several years ago
> suggested that probably about 60% of ADSL customers in the US use this
> topology. The most common cause for this topology is where the service
> provider supplies a free ADSL router with a single port to a subscriber,
> and the subscriber then puts their own multi-port router behind that
> router. The ADSL router is configured to do the PPPoE, and is also
> configured to automatically provide whatever public IP address it gets
> to whatever is behind it (via DHCPv4, as a sort of automatic DMZ
> function -- the ADSL router also uses that public IP address for its
> needs). The ADSL router is often set to provide only that one address,
> and not to support a full network of devices. Which is why consumers are
> forced to use their own router. This also tends to be how VoIP router +
> consumer's wireless router topology works.
> 
> I'm sure some people would like to argue as to why this is bad, or it
> shouldn't be done. I'm not going to get into that argument. That
> argument is irrelevant. The fact is that it's very, very common. 
> 
> I agree with those who say that we *don't* need to make sure IPv4 works
> everywhere that IPv6 works.
> But I think it's an absolute requirement that IPv6 MUST work everywhere
> that IPv4 works.
> 
> And this is a very common case where IPv4 works. When going to IPv6, the
> ADSL router will also be the device that establishes the IPv6
> connection. Because the credentials are the same as for IPv4, and the
> secondary router doesn't have those credentials. And the consumer forgot
> the credentials long ago, and doesn't remember how to configure this
> stuff anyway.
> 
> IMO, I believe that the best approach would be to solve tree
> generically. Which means that the probability of "tree network" would
> actually be "common, perhaps 30th percentile" (dividing my "60% in ADSL
> networks" by 2).
> Barbara
> 
>> -Original Message-
>> On 10/7/11 12:48 AM, Fred Baker wrote:
>>> I suggested that the probability of use of each of the scenarios on
>> slide 4 were
>>>  single router network: 90th percentile
>>>  tree network:  unusual
>>>  multi-router:  perhaps 5th percentile
>>>  multihomed:unusual
>> 
>> Fred,
>> 
>> are the above numbers based on any survey data?
>> 
>> Reason I'm asking is that I have two consumer devices with IPv4 NAT in
>> my home (a VoIP box and a backup device) where the instructions said:
>> 1. Insert between or existing router (or PC if you have no router) and
>> the DSL/cable modem
>> 2. Insert between your PC and your existing router (or modem if you
>> have
>> no router)
>> 
>> Those consumer instructions naturally result in a daisy-chain of IPv4
>> RGs/NATs, which is a subset of a tree topology.
>> 
>> I can't be the only person who have a VoIP box or a Time Capsule.
>> 
>>Erik
>> ___
>> homenet mailing list
>> homenet@ietf.org
>> https://www.ietf.org/mailman/listinfo/homenet

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Thoughts about routing

[Erik Nordmark]

On 10/9/11 8:33 AM, Michael Richardson wrote:



"Erik" == Erik Nordmark  writes:

 Erik>  Reason I'm asking is that I have two consumer devices with
 Erik>  IPv4 NAT in my home (a VoIP box and a backup device) where the
 Erik>  instructions said: 1. Insert between or existing router (or PC
 Erik>  if you have no router) and the DSL/cable modem 2. Insert
 Erik>  between your PC and your existing router (or modem if you have
 Erik>  no router)

 Erik>  Those consumer instructions naturally result in a daisy-chain
 Erik>  of IPv4 RGs/NATs, which is a subset of a tree topology.

That's a good point:  many VoIP ATAs want to be the first device so that
they can control the QoS, and ideally get the public IP address.

Does your VoIP box do PPPoE as well?


Yes.

It is basically a home gateway (without WiFi - wired Ethernet only) with 
a SIM slot and a phone connector added. Thus it has all the usual 
protocols and knobs for Internet connectivity.


The backup device takes the same approach - start with a home gateway 
and add something (in that case a disk plus file sharing software) but 
don't remove anything.


  Erik

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Thoughts about routing

[Curtis Villamizar]

In message <635c3a25-7265-402d-a708-3a07b08ef...@cisco.com>
Fred Baker writes:
 
> On Oct 9, 2011, at 8:01 PM, Acee Lindem wrote:
>  
> > Since OSPFv3 also uses a 4 byte router ID, our implementation will
> > use the same algorithm for picking a router ID as OSPFv2.
>  
> which is to say "any old thing it wants, quite often an IPv4 address"?


A practical solution (of days past) using OSPF was to configure an
address that was not a link address, and then configure it as an alias
to the loopback and also advertise it as a /32 stub, and then tweak
applications to bind to that address.  This loopback address was
reachable even if an Ethernet subnet was partitioned (common).

Providers have all done this on their IPv4-only routers, allocating
the router-id from one or more small prefix which within the network
was all host routes.  That was fine for small number of routers
(hundreds or thousands) and lots of global prefixes (hundreds of
thousand) [note: "or" in the first case; "of" in the second case].

In the absense of this configuration or in an IPv6 network, the
assumption that the router-id is a reachable address is not a good
one.  It is also discouraged by the standards.

An IPv6 /64 has 2 sets of 4 bytes in every address even after tossing
out the top 64 bits.  So picking an address won't work.

What is really needed is a means to recover from a router-id
collision.  One router can detect another using the same router-id
easily enough.  An extension is needed to indicate a collision (there
is a denial of service potential with this).  The behaviour could be
for each router using that router-id (and supporting the extension) to
make another pick and readvertise.  It means taking down adjacencies
and bringing them back up, but perhaps a graceful restart extension
could smooth this.

This is putting lots of code in the little homenet router,
particularly if graceful restart is used.

Random number selection for router-id and this sort of recovery would
solve the zero config OSPF issue related to router-id selection.

Not yet solved in existing zospf draft (afaik) but solvable.

Curtis
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Thoughts about routing

[Curtis Villamizar]

In message 
Acee Lindem writes:


On Oct 9, 2011, at 8:41 PM, Fred Baker wrote:
 
> > 
> > On Oct 9, 2011, at 8:01 PM, Acee Lindem wrote:
> > 
> >> Since OSPFv3 also uses a 4 byte router ID, our implementation will
> >> use the same algorithm for picking a router ID as OSPFv2.
> > 
> > which is to say "any old thing it wants, quite often an IPv4 address"?
>  
>  
> Correct, it uses the best or only configured IPv4 address in the
> context (aka, virtual router). Of course, we'd want to use something
> else for true auto-configuration.
>  
> Thanks,
> Acee 


And on an IPv6 only homenet with no configured addresses it does what?

Curtis
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Thoughts about routing

[Acee Lindem]

On Oct 10, 2011, at 5:18 PM, Curtis Villamizar wrote:

> 
> In message 
> Acee Lindem writes:
> 
> 
> On Oct 9, 2011, at 8:41 PM, Fred Baker wrote:
> 
>>> 
>>> On Oct 9, 2011, at 8:01 PM, Acee Lindem wrote:
>>> 
 Since OSPFv3 also uses a 4 byte router ID, our implementation will
 use the same algorithm for picking a router ID as OSPFv2.
>>> 
>>> which is to say "any old thing it wants, quite often an IPv4 address"?
>> 
>> 
>> Correct, it uses the best or only configured IPv4 address in the
>> context (aka, virtual router). Of course, we'd want to use something
>> else for true auto-configuration.
>> 
>> Thanks,
>> Acee 
> 
> 
> And on an IPv6 only homenet with no configured addresses it does what?

Our Ericsson SmartEdge routers were never meant to be deployed in the home or 
to support complete auto-configuration - I was just responding to Fred's query 
as to what OSPFv3 implementations do today. 
If there is no IPv4 address available and no OSPFv3 Router-ID is explicitly 
configured, we'll log an error and shut the OSPFv3 instance down until such 
time as an IPv4 address or explicit router-id are configured.
A new draft is required for OSPFv3 auto-configuration. 
Thanks,
Acee

> 
> Curtis
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet



smime.p7s
Description: S/MIME cryptographic signature
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Thoughts about routing

[Curtis Villamizar]

In message <0edb3e2d-40f1-4bc8-9057-fe1d70f17...@ericsson.com>
Acee Lindem writes:
 
> On Oct 10, 2011, at 5:18 PM, Curtis Villamizar wrote:
>  
> >=20
> > In message 
> > Acee Lindem writes:
> >=20
> >=20
> > On Oct 9, 2011, at 8:41 PM, Fred Baker wrote:
> >=20
> >>>=20
> >>> On Oct 9, 2011, at 8:01 PM, Acee Lindem wrote:
> >>>=20
>  Since OSPFv3 also uses a 4 byte router ID, our implementation will
>  use the same algorithm for picking a router ID as OSPFv2.
> >>>=20
> >>> which is to say "any old thing it wants, quite often an IPv4 =
> address"?
> >>=20
> >>=20
> >> Correct, it uses the best or only configured IPv4 address in the
> >> context (aka, virtual router). Of course, we'd want to use something
> >> else for true auto-configuration.
> >>=20
> >> Thanks,
> >> Acee=20
> >=20
> >=20
> > And on an IPv6 only homenet with no configured addresses it does what?
>  
> Our Ericsson SmartEdge routers were never meant to be deployed in the =
> home or to support complete auto-configuration - I was just responding =
> to Fred's query as to what OSPFv3 implementations do today.=20
> If there is no IPv4 address available and no OSPFv3 Router-ID is =
> explicitly configured, we'll log an error and shut the OSPFv3 instance =
> down until such time as an IPv4 address or explicit router-id are =
> configured.
> A new draft is required for OSPFv3 auto-configuration.=20
> Thanks,
> Acee
>  
> >=20
> > Curtis


Acee,

I'll have to confess that my most recent employer's equipement was
also not intended for the home.  :-)

I'm sure you saw the suggestions I made in another response.  The fix
for autoconfig may be to pick a random number and create an OSPF
extension to advertise the detection of a collision on a given
router-id, then respond to the collision.  Any device using autoconfig
would have to support this extension.  If colliding with a router that
did not support the extension, that other router would do nothing, but
the autoconfig router would pick a new router-id.

The point is you can't make a unique 32 bit number out of a 48 bit
number or a 64 bit number or an 80 bit number (for a /48).  So you
might as well accept low probability of collision and define a way to
fix the situation.

The absolute worst case is a stomped on LSA that an old router doesn't
update until maxage expires.  That would be bad so maybe we need to
figure out what a legacy OSPF router would do on such a collision
where it got from a neighbor something it did not send as its own LSA.
Hopefully it would readvertise the right stuff and try to withdraw the
bad stuff.  The autoconfig router would just pick a new router-id.

It all sounds fine except maybe the backwards compatibility with no
changes.  Your the OSPF expert so ...

Curtis
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Thoughts about routing

[Jari Arkko]

Home routers would also have MAC addresses, but again, if we need a 32-bit 
quantity then shortened 48/64 bit identifiers may (theoretically) have 
collisions.

That being said, if the home routers have to discover their IPv6 prefix through 
a protocol and store it in flash, they could probably do so also for a router 
ID. Unless there was some chicken and egg problem that required the router ID 
for all this discovery to work...

Jari

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Thoughts about routing

[Fred Baker]

On Oct 11, 2011, at 12:05 AM, Jari Arkko wrote:

> That being said, if the home routers have to discover their IPv6 prefix 
> through a protocol and store it in flash, they could probably do so also for 
> a router ID. Unless there was some chicken and egg problem that required the 
> router ID for all this discovery to work...

(z)ospf requires the router to have a router id in order to join the network, 
which it has to do before it can receive the LSAs from other routers in the 
area to inspect their subnet prefixes. So making the router id dependent on the 
prefix doesn't make a lot of sense to me.

While a MAC Address is not guaranteed to be globally unique, it is intended to 
be; places where duplicates have been seen tend to be manufacturing errors. 
From that perspective, grabbing the least significant 32 bits from a MAC 
address as a first guess seems reasonable. What one would then need to do is 

1) receive the LS Database
2) inspect for other instances of the same router id
3a) if found, attempt to flush the LSA (it might be an old LSA from the same 
router)
3b) if flushed and it is then re-advertised back, there is a collision and the 
other router is asserting ownership; pick a random number

One obviously doesn't actually announce any LSAs using the router ID until a 
unique router id is established.
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Thoughts about routing

[Michael Richardson]

> "Fred" == Fred Baker  writes:
Fred> On Oct 11, 2011, at 12:05 AM, Jari Arkko wrote:

>> That being said, if the home routers have to discover their IPv6
>> prefix through a protocol and store it in flash, they could
>> probably do so also for a router ID. Unless there was some
>> chicken and egg problem that required the router ID for all this
>> discovery to work...

Fred> (z)ospf requires the router to have a router id in order to
Fred> join the network, which it has to do before it can receive the
Fred> LSAs from other routers in the area to inspect their subnet
Fred> prefixes. So making the router id dependent on the prefix
Fred> doesn't make a lot of sense to me.

Fred> While a MAC Address is not guaranteed to be globally unique,
Fred> it is intended to be; places where duplicates have been seen
Fred> tend to be manufacturing errors. From that perspective,
Fred> grabbing the least significant 32 bits from a MAC address as a
Fred> first guess seems reasonable. What one would then need to do
Fred> is

What do we do in that rare case where the bottom 32 of the MAC are
duplicated?   

Also consider that virtual switches (VMware, XEN, etc.) all pretty much
use the same set of MAC addresses.  VMware has a 50:  prefix that they
use, XEN has another, and did you know that 10:00:00 (curisously like
10/8) is reserved for private use... 

So, it would be good for zospf text to say something about this.
I think that we can use 32-bits of MAC address in most cases.

Fred> One obviously doesn't actually announce any LSAs using the
Fred> router ID until a unique router id is established.

okay.

-- 
]   He who is tired of Weird Al is tired of life!   |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON|net architect[
] m...@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video 
   then sign the petition. 


pgpmCSM7cpPzu.pgp
Description: PGP signature
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Thoughts about routing

[Acee Lindem]

On Oct 11, 2011, at 10:27 AM, Michael Richardson wrote:

> 
>> "Fred" == Fred Baker  writes:
>Fred> On Oct 11, 2011, at 12:05 AM, Jari Arkko wrote:
> 
>>> That being said, if the home routers have to discover their IPv6
>>> prefix through a protocol and store it in flash, they could
>>> probably do so also for a router ID. Unless there was some
>>> chicken and egg problem that required the router ID for all this
>>> discovery to work...
> 
>Fred> (z)ospf requires the router to have a router id in order to
>Fred> join the network, which it has to do before it can receive the
>Fred> LSAs from other routers in the area to inspect their subnet
>Fred> prefixes. So making the router id dependent on the prefix
>Fred> doesn't make a lot of sense to me.
> 
>Fred> While a MAC Address is not guaranteed to be globally unique,
>Fred> it is intended to be; places where duplicates have been seen
>Fred> tend to be manufacturing errors. From that perspective,
>Fred> grabbing the least significant 32 bits from a MAC address as a
>Fred> first guess seems reasonable. What one would then need to do
>Fred> is
> 
> What do we do in that rare case where the bottom 32 of the MAC are
> duplicated?   

The conflict must be resolved with one router selecting a different Router-ID. 
That is a problem that would need to be handled in any OSPFv3 
auto-configuration draft.
You cannot have two routers in the same routing domain with the same OSPFv3 
Router ID since their LSAs cannot be differentiated from one another and the 
two routers with the same Router-ID will get into a flooding war.  
Thanks,
Acee


> 
> Also consider that virtual switches (VMware, XEN, etc.) all pretty much
> use the same set of MAC addresses.  VMware has a 50:  prefix that they
> use, XEN has another, and did you know that 10:00:00 (curisously like
> 10/8) is reserved for private use... 
> 
> So, it would be good for zospf text to say something about this.
> I think that we can use 32-bits of MAC address in most cases.
> 
>Fred> One obviously doesn't actually announce any LSAs using the
>Fred> router ID until a unique router id is established.
> 
> okay.
> 
> -- 
> ]   He who is tired of Weird Al is tired of life!   |  firewalls  
> [
> ]   Michael Richardson, Sandelman Software Works, Ottawa, ON|net 
> architect[
> ] m...@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device 
> driver[
>   Kyoto Plus: watch the video 
>  then sign the petition. 
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet



smime.p7s
Description: S/MIME cryptographic signature
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Thoughts about routing

[Fred Baker]

On Oct 11, 2011, at 10:27 AM, Michael Richardson wrote:

> 
>> "Fred" == Fred Baker  writes:
>Fred> On Oct 11, 2011, at 12:05 AM, Jari Arkko wrote:
> 
>>> That being said, if the home routers have to discover their IPv6
>>> prefix through a protocol and store it in flash, they could
>>> probably do so also for a router ID. Unless there was some
>>> chicken and egg problem that required the router ID for all this
>>> discovery to work...
> 
>Fred> (z)ospf requires the router to have a router id in order to
>Fred> join the network, which it has to do before it can receive the
>Fred> LSAs from other routers in the area to inspect their subnet
>Fred> prefixes. So making the router id dependent on the prefix
>Fred> doesn't make a lot of sense to me.
> 
>Fred> While a MAC Address is not guaranteed to be globally unique,
>Fred> it is intended to be; places where duplicates have been seen
>Fred> tend to be manufacturing errors. From that perspective,
>Fred> grabbing the least significant 32 bits from a MAC address as a
>Fred> first guess seems reasonable. What one would then need to do
>Fred> is
> 
> What do we do in that rare case where the bottom 32 of the MAC are
> duplicated?   

Pick a random number. Note that we agree it is a rare case. If it's a router, 
it probably has more than one MAC Address...

> Also consider that virtual switches (VMware, XEN, etc.) all pretty much
> use the same set of MAC addresses.  VMware has a 50:  prefix that they
> use, XEN has another, and did you know that 10:00:00 (curisously like
> 10/8) is reserved for private use... 

Yes, and homes frequently use virtual switches.

To be really honest, yes, it would be good for zospf - if we recommend that - 
to make some suggestions. That said, there is no reason for the suggestions to 
be normative. What OSPF requires is that the RID is unique in the area. It does 
not require that it be derived from any given datum.

> So, it would be good for zospf text to say something about this.
> I think that we can use 32-bits of MAC address in most cases.
> 
>Fred> One obviously doesn't actually announce any LSAs using the
>Fred> router ID until a unique router id is established.
> 
> okay.
> 
> -- 
> ]   He who is tired of Weird Al is tired of life!   |  firewalls  
> [
> ]   Michael Richardson, Sandelman Software Works, Ottawa, ON|net 
> architect[
> ] m...@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device 
> driver[
>   Kyoto Plus: watch the video 
>  then sign the petition. 
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Thoughts about routing

[Russ White]

> What do we do in that rare case where the bottom 32 of the MAC are
> duplicated?   
> 
> Also consider that virtual switches (VMware, XEN, etc.) all pretty much
> use the same set of MAC addresses.  VMware has a 50:  prefix that they
> use, XEN has another, and did you know that 10:00:00 (curisously like
> 10/8) is reserved for private use... 
> 
> So, it would be good for zospf text to say something about this.
> I think that we can use 32-bits of MAC address in most cases.
> 
> Fred> One obviously doesn't actually announce any LSAs using the
> Fred> router ID until a unique router id is established.
> 
> okay.

You need a unique identifier at the equipment level for anything you
intend to auto-configure --autoconfiguring uniqueness is a very hard,
probably impossible, problem on a global scale. So we need to count on
this one thing, no matter what else we might need to back in to.

Now, it might be possible to some hash over a GPS location for a "base,"
and then add on MAC addresses, or some such, but IMHO, homenet should
start with the assumption of having some sort of "unique id" in every
device deployed, available through some sort of local API, and work from
there.

Let's solve problems that can actually be solved... :-)

:-)

Russ

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Thoughts about routing

[Joe Touch]

On 10/10/2011 7:18 AM, STARK, BARBARA H wrote:

The subset of tree topology where a consumer places ones router behind
another router is *extremely* common. Statistics I saw several years ago
suggested that probably about 60% of ADSL customers in the US use this
topology. The most common cause for this topology is where the service
provider supplies a free ADSL router with a single port to a subscriber,
and the subscriber then puts their own multi-port router behind that
router. The ADSL router is configured to do the PPPoE, and is also
configured to automatically provide whatever public IP address it gets
to whatever is behind it (via DHCPv4, as a sort of automatic DMZ
function -- the ADSL router also uses that public IP address for its
needs). The ADSL router is often set to provide only that one address,
and not to support a full network of devices. Which is why consumers are
forced to use their own router.

...

They also do this commonly to introduce or upgrade their WiFi service at 
home without needing to reconfigure the subscriber access box.


To a lot of consumers, IF things can be plugged together, then they WILL BE.


This also tends to be how VoIP router +
consumer's wireless router topology works.


That too...

Joe

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Thoughts about routing

[Michael Richardson]

> "Russ" == Russ White  writes:
Russ> You need a unique identifier at the equipment level for
Russ> anything you intend to auto-configure --autoconfiguring
Russ> uniqueness is a very hard, probably impossible, problem on a
Russ> global scale. So we need to count on this one thing, no matter
Russ> what else we might need to back in to.

Russ> Now, it might be possible to some hash over a GPS location for
Russ> a "base," and then add on MAC addresses, or some such, but

We've assumed a unique MAC, which is 48 bits long. 
But OSPF router-id is 32 bits.What is the likelyhood of a collision 
in the bottom 32-bits of the MAC? 

-- 
]   He who is tired of Weird Al is tired of life!   |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON|net architect[
] m...@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video 
   then sign the petition. 




pgp73LroPJsXJ.pgp
Description: PGP signature
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Thoughts about routing

[Ulrich Herberg]

Hi,

On 10/12/11 8:38 AM, Michael Richardson wrote:
>> "Russ" == Russ White  writes:
> Russ> You need a unique identifier at the equipment level for
> Russ> anything you intend to auto-configure --autoconfiguring
> Russ> uniqueness is a very hard, probably impossible, problem on a
> Russ> global scale. So we need to count on this one thing, no matter
> Russ> what else we might need to back in to.
>
> Russ> Now, it might be possible to some hash over a GPS location for
> Russ> a "base," and then add on MAC addresses, or some such, but
>
> We've assumed a unique MAC, which is 48 bits long. 
> But OSPF router-id is 32 bits.What is the likelyhood of a collision 
> in the bottom 32-bits of the MAC? 
It seems to me that this discussion about duplicate addresses / unique
MAC tool already place in the IETF a number of years ago, e.g. as
reflected in RFC 4862 (IPv6 Stateless Autoconfiguration, section 5.4),
where duplicate address detection is mandatory. It wouldn't have to be
if the assumption holds that all MAC addresses are unique.

Even though the probability of collisions may be low, because of
manufacturer errors / virtual interfaces and virtual machines /
reduction from 48bits to 32bits, there could be collisions. I am not
convinced that we can make Russ' assumption that we need unique
identifiers at equipment level (or at least that seems inconsistent with
previous IETF decisions, so we would need to make a strong case what has
changed since then). I do agree with Russ, though, that verifying
uniqueness is hard.

Regards
Ulrich

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Thoughts about routing

[Ulrich Herberg]

Jari,

On 10/11/11 12:05 PM, Jari Arkko wrote:
> Home routers would also have MAC addresses, but again, if we need a
> 32-bit quantity then shortened 48/64 bit identifiers may
> (theoretically) have collisions.
>
> That being said, if the home routers have to discover their IPv6
> prefix through a protocol and store it in flash, they could probably
> do so also for a router ID. Unless there was some chicken and egg
> problem that required the router ID for all this discovery to work...
I agree. Since we need to configure unique prefixes to each router in
the home anyway, it should not be any problem to do the same for a
router ID (or even just use an address from the configured prefix as
router ID, which should then be unique). A while ago, there were some
plans in AUTOCONF to specify how to use DHCPv6 (-PD) in a multi-hop
network for configuring prefixes in the network. As in a home network, I
assume there is always at least one border router with the global
prefix, specifying something like that seems to be reasonable for me (in
a MANET, that can be more difficult, because there is not necessarily
such a central entity as the border router).

Regards
Ulrich
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Thoughts about routing

[Russ White]

> Russ> You need a unique identifier at the equipment level for
> Russ> anything you intend to auto-configure --autoconfiguring
> Russ> uniqueness is a very hard, probably impossible, problem on a
> Russ> global scale. So we need to count on this one thing, no matter
> Russ> what else we might need to back in to.
> 
> Russ> Now, it might be possible to some hash over a GPS location for
> Russ> a "base," and then add on MAC addresses, or some such, but
> 
> We've assumed a unique MAC, which is 48 bits long. 
> But OSPF router-id is 32 bits.What is the likelyhood of a collision 
> in the bottom 32-bits of the MAC? 

Ah, I see the problem... There is a pretty high likelihood of a
collision, actually, at least as long as you use multiple vendors in
your home network. It's bound to happen to someone, someplace.

So, a suggestion to resolve this:

1. Use the lower 32 bits of one of the mac addresses on the box as the
initial id.

2. Add a new field to the router capabilities that carries the full 48
bit mac address, or even some munged together "longer id," based on
multiple mac addresses on the device, or some such.

3. During initial setup, if you receive a capability that appears to be
from yourself, you open this secondary id section to find out if it's
really you, or someone else who happens to have the same 32 bit id.

4. If it's really you, discard the packet.

5. If it's not really you, and if the other router's "large id" is lower
than yours, choose another mac address from which to take your local id,
and restart your ospf process.

6. If it's not really you, and the other router's "large id" is higher
than yours, then send a router capabilities LSA unicast to this "other
router," so the "other router" knows to change its id.

I don't think IS-IS would have this problem.

:-)

Russ
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Thoughts about routing

[Curtis Villamizar]

In message <17786.1318379...@marajade.sandelman.ca>
Michael Richardson writes:
 
> > "Russ" =3D=3D Russ White  writes:
> Russ> You need a unique identifier at the equipment level for
> Russ> anything you intend to auto-configure --autoconfiguring
> Russ> uniqueness is a very hard, probably impossible, problem on a
> Russ> global scale. So we need to count on this one thing, no matter
> Russ> what else we might need to back in to.
>  
> Russ> Now, it might be possible to some hash over a GPS location for
> Russ> a "base," and then add on MAC addresses, or some such, but
>  
> We've assumed a unique MAC, which is 48 bits long.=20
> But OSPF router-id is 32 bits.What is the likelyhood of a collision=20
> in the bottom 32-bits of the MAC?=20


Each organization has one or more unique OUI which includes one of the
bottom four bytes.  The next three (of those four) are unique only
within the OUI which is the top three bytes (but with two bits given
special meaning).

So what are the chances that two organization start numbering the
bottom bits at zero and work their way up until the bottom three bits
are filled.  Since there are way more than 256 organizations that have
an OUI, collisions, while rare, can happen.

If there is a way to recover from a collision, then its a complete
non-issue and a random number can be used.

Curtis
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Thoughts about routing

[Curtis Villamizar]

In message <4e95096e.5020...@herberg.name>
Ulrich Herberg writes:
 
> Jari,
>  
> On 10/11/11 12:05 PM, Jari Arkko wrote:
> > Home routers would also have MAC addresses, but again, if we need a
> > 32-bit quantity then shortened 48/64 bit identifiers may
> > (theoretically) have collisions.
> >
> > That being said, if the home routers have to discover their IPv6
> > prefix through a protocol and store it in flash, they could probably
> > do so also for a router ID. Unless there was some chicken and egg
> > problem that required the router ID for all this discovery to work...
> I agree. Since we need to configure unique prefixes to each router in
> the home anyway, it should not be any problem to do the same for a
> router ID (or even just use an address from the configured prefix as
> router ID, which should then be unique). A while ago, there were some
> plans in AUTOCONF to specify how to use DHCPv6 (-PD) in a multi-hop
> network for configuring prefixes in the network. As in a home network, I
> assume there is always at least one border router with the global
> prefix, specifying something like that seems to be reasonable for me (in
> a MANET, that can be more difficult, because there is not necessarily
> such a central entity as the border router).
>  
> Regards
> Ulrich


Ulrich,

Whatever ends up being specified should require no configuration and
work when there are:

  zero border routers providing a prefix (outage and/or partition)

  one border router providing a prefix (the easy case)

  multiple border routers providing a prefix

For the large apartment building example that Jim gave, we really
should consider scaling behavior when there are a large number of
border routers providing a prefix within a given mesh.

Curtis
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Thoughts about routing

[Mark Andrews]

While talking about hardware.  These these devices all need a battery
backed clock or all the crypto will be broken.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Thoughts about routing

[Mark Andrews]

In message <669f4202-6fd4-4f13-ae7b-e725d53ad...@gmail.com>, Jim Gettys writes:
> Or you solve the time problem some other way...
> 
> Batteries die too...
>   Jim

Indeed.  It should be a user servicable part.

As to solving it other way, "leap of faith" springs to mind.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Thoughts about routing

[Curtis Villamizar]

In message <4e95836d.4020...@riw.us>
Russ White writes:
 
>  
> > Russ> You need a unique identifier at the equipment level for
> > Russ> anything you intend to auto-configure --autoconfiguring
> > Russ> uniqueness is a very hard, probably impossible, problem on a
> > Russ> global scale. So we need to count on this one thing, no matter
> > Russ> what else we might need to back in to.
> > 
> > Russ> Now, it might be possible to some hash over a GPS location for
> > Russ> a "base," and then add on MAC addresses, or some such, but
> > 
> > We've assumed a unique MAC, which is 48 bits long. 
> > But OSPF router-id is 32 bits.What is the likelyhood of a collision 
> > in the bottom 32-bits of the MAC? 
>  
> Ah, I see the problem... There is a pretty high likelihood of a
> collision, actually, at least as long as you use multiple vendors in
> your home network. It's bound to happen to someone, someplace.
>  
> So, a suggestion to resolve this:
>  
> 1. Use the lower 32 bits of one of the mac addresses on the box as the
> initial id.
>  
> 2. Add a new field to the router capabilities that carries the full 48
> bit mac address, or even some munged together "longer id," based on
> multiple mac addresses on the device, or some such.

Not backwards compatible.  The older OSPF routers will see only the
non-unique 32 bits and the network won't work.

> 3. During initial setup, if you receive a capability that appears to be
> from yourself, you open this secondary id section to find out if it's
> really you, or someone else who happens to have the same 32 bit id.
>  
> 4. If it's really you, discard the packet.
>  
> 5. If it's not really you, and if the other router's "large id" is lower
> than yours, choose another mac address from which to take your local id,
> and restart your ospf process.
>  
> 6. If it's not really you, and the other router's "large id" is higher
> than yours, then send a router capabilities LSA unicast to this "other
> router," so the "other router" knows to change its id.
>  
> I don't think IS-IS would have this problem.
>  
> :-)
>  
> Russ

If the other router doesn't implement the extension you've described,
the network is hosed forever.

If you have more than one link you should receive the LSA (or LSPDU)
that you advertised.  If you have one link, you won't.

If you receive a LSA (or LSPDU) that clearly you didn't advertise,
then you have a collision.  *Both* routers should pick a new router-id
if this condition is detected and they implement this extension.

Don't even bother using a MAC address for the router-id.  Use a random
number.  If a collision occurs, use a different random number.  This
should also work for interfaces without a MAC (not that many homes run
POS today, but maybe some layer-2 in the future).

Here is where it if fuzzy if one router is a legacy router.  It may
not look at LSA (or LSPDU) apparently from itself or may just log a
problem and continue.  When backing off, the bogus advertisements need
to be withdrawn.  A possible backward compatibility wrinkle exists if
the legacy router does not readvertise (being legacy it will not pick
a new router-id).  The problem could persist for maxage.  Better than
forever but still not good.

Don't use a non-configured router-id if you don't support this ability
to back off.  (Routers today don't pick a random router-id and they
shouldn't unless they can backoff).

Curtis
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Thoughts about routing

[Curtis Villamizar]

In message <20111013011929.1f7051527...@drugs.dv.isc.org>
Mark Andrews writes:
 
>  
> While talking about hardware.  These these devices all need a battery
> backed clock or all the crypto will be broken.


Having a clock is not hard but I don't think your statement is true.

Some crypto does not require time, but rather just entropy (a nonce or
challenge).  For crypto that does require time the former can be a
bootstrap of sorts, possibly to get ntp going if very accurate time is
needed (for some reason).

For example ssh with rsa or dsa does not require time.  You need to
know what month and year it is to be good enough as far as checking
certificates.

A lot of the KARP work does require knowing the time to prevent
replay attack.

Curtis
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Thoughts about routing

[Russ White]

> I agree. Since we need to configure unique prefixes to each router in
> the home anyway, it should not be any problem to do the same for a
> router ID (or even just use an address from the configured prefix as
> router ID, which should then be unique). A while ago, there were some
> plans in AUTOCONF to specify how to use DHCPv6 (-PD) in a multi-hop
> network for configuring prefixes in the network. As in a home network, I
> assume there is always at least one border router with the global
> prefix, specifying something like that seems to be reasonable for me (in
> a MANET, that can be more difficult, because there is not necessarily
> such a central entity as the border router).

I think there will be, by default, multiple "border routers." In my
house I currently have 6 devices that provide internet connectivity, and
I assume that number is going nowhere but up. Each of these devices
could, in theory, be a "border router," in some way.

What saves the day is that I don't allow 4 of them to "talk" on the
internal network, and the other two are carefully segregated. But
there's no reason for any of this --there's no reason I shouldn't be
able to use all of them, especially as some of them might be able to
reach outside networks in addition to the Internet at large that others
might not be able to.

:-)

Russ
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Thoughts about routing

[Acee Lindem]

One assumption could be that a legacy router would not support auto-config and, 
if deployed, would have to be configured with a unique Router ID (as they are 
today).  
Thanks,
Acee
On Oct 12, 2011, at 10:46 PM, Curtis Villamizar wrote:

> 
> In message <4e95836d.4020...@riw.us>
> Russ White writes:
> 
>> 
>>>Russ> You need a unique identifier at the equipment level for
>>>Russ> anything you intend to auto-configure --autoconfiguring
>>>Russ> uniqueness is a very hard, probably impossible, problem on a
>>>Russ> global scale. So we need to count on this one thing, no matter
>>>Russ> what else we might need to back in to.
>>> 
>>>Russ> Now, it might be possible to some hash over a GPS location for
>>>Russ> a "base," and then add on MAC addresses, or some such, but
>>> 
>>> We've assumed a unique MAC, which is 48 bits long. 
>>> But OSPF router-id is 32 bits.What is the likelyhood of a collision 
>>> in the bottom 32-bits of the MAC? 
>> 
>> Ah, I see the problem... There is a pretty high likelihood of a
>> collision, actually, at least as long as you use multiple vendors in
>> your home network. It's bound to happen to someone, someplace.
>> 
>> So, a suggestion to resolve this:
>> 
>> 1. Use the lower 32 bits of one of the mac addresses on the box as the
>> initial id.
>> 
>> 2. Add a new field to the router capabilities that carries the full 48
>> bit mac address, or even some munged together "longer id," based on
>> multiple mac addresses on the device, or some such.
> 
> Not backwards compatible.  The older OSPF routers will see only the
> non-unique 32 bits and the network won't work.
> 
>> 3. During initial setup, if you receive a capability that appears to be
>> from yourself, you open this secondary id section to find out if it's
>> really you, or someone else who happens to have the same 32 bit id.
>> 
>> 4. If it's really you, discard the packet.
>> 
>> 5. If it's not really you, and if the other router's "large id" is lower
>> than yours, choose another mac address from which to take your local id,
>> and restart your ospf process.
>> 
>> 6. If it's not really you, and the other router's "large id" is higher
>> than yours, then send a router capabilities LSA unicast to this "other
>> router," so the "other router" knows to change its id.
>> 
>> I don't think IS-IS would have this problem.
>> 
>> :-)
>> 
>> Russ
> 
> If the other router doesn't implement the extension you've described,
> the network is hosed forever.
> 
> If you have more than one link you should receive the LSA (or LSPDU)
> that you advertised.  If you have one link, you won't.
> 
> If you receive a LSA (or LSPDU) that clearly you didn't advertise,
> then you have a collision.  *Both* routers should pick a new router-id
> if this condition is detected and they implement this extension.
> 
> Don't even bother using a MAC address for the router-id.  Use a random
> number.  If a collision occurs, use a different random number.  This
> should also work for interfaces without a MAC (not that many homes run
> POS today, but maybe some layer-2 in the future).
> 
> Here is where it if fuzzy if one router is a legacy router.  It may
> not look at LSA (or LSPDU) apparently from itself or may just log a
> problem and continue.  When backing off, the bogus advertisements need
> to be withdrawn.  A possible backward compatibility wrinkle exists if
> the legacy router does not readvertise (being legacy it will not pick
> a new router-id).  The problem could persist for maxage.  Better than
> forever but still not good.
> 
> Don't use a non-configured router-id if you don't support this ability
> to back off.  (Routers today don't pick a random router-id and they
> shouldn't unless they can backoff).
> 
> Curtis
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet



smime.p7s
Description: S/MIME cryptographic signature
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Thoughts about routing

[Michael Richardson]

> "Mark" == Mark Andrews  writes:
>> Or you solve the time problem some other way...
>> 
>> Batteries die too...  Jim

Mark> Indeed.  It should be a user servicable part.

Mark> As to solving it other way, "leap of faith" springs to mind.

DHCP has an NTP server option.  Does IP6CP?

-- 
]   He who is tired of Weird Al is tired of life!   |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON|net architect[
] m...@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video 
   then sign the petition. 


___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Thoughts about routing

[Michael Richardson]

> "Curtis" == Curtis Villamizar  writes:
>> 2. Add a new field to the router capabilities that carries the
>> full 48 bit mac address, or even some munged together "longer
>> id," based on multiple mac addresses on the device, or some such.

Curtis> Not backwards compatible.  The older OSPF routers will see
Curtis> only the non-unique 32 bits and the network won't work.

There are no zOSPF routers today.

-- 
]   He who is tired of Weird Al is tired of life!   |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON|net architect[
] m...@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video 
   then sign the petition. 
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Thoughts about routing

[Jim Gettys]

Or you solve the time problem some other way...

Batteries die too...
  Jim




On Oct 12, 2011, at 9:19 PM, Mark Andrews  wrote:

> 
> While talking about hardware.  These these devices all need a battery
> backed clock or all the crypto will be broken.
> 
> -- 
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Thoughts about routing

[Curtis Villamizar]

In message <1e8bbe2e-357a-4681-bb84-4e694afd9...@ericsson.com>
Acee Lindem writes:
 
> One assumption could be that a legacy router would not support
> auto-config and, if deployed, would have to be configured with a
> unique Router ID (as they are today).

Got that.

   Don't use a non-configured router-id if you don't support this
   ability to back off.  (Routers today don't pick a random router-id
   and they shouldn't unless they can backoff).

> Thanks,
> Acee

The key uncertainty is the effect of a collision on a legacy router.

This looks like it is covered.  (indentation changed)

  [RFC2328]  13.4.  Receiving self-originated LSAs

It is a common occurrence for a router to receive self- originated
LSAs via the flooding procedure. A self-originated LSA is detected
when either 1) the LSA's Advertising Router is equal to the
router's own Router ID or 2) the LSA is a network- LSA and its
Link State ID is equal to one of the router's own IP interface
addresses.

However, if the received self-originated LSA is newer than the
last instance that the router actually originated, the router must
take special action.  The reception of such an LSA indicates that
there are LSAs in the routing domain that were originated by the
router before the last time it was restarted.  In most cases, the
router must then advance the LSA's LS sequence number one past the
received LS sequence number, and originate a new instance of the
LSA.

[...] In all these cases, instead of updating the LSA, the LSA
should be flushed from the routing domain by incrementing the
received LSA's LS age to MaxAge and reflooding (see Section 14.1).

  [RFC5340]  4.5.1.  Receiving Link State Update Packets

[...]  In IPv4, eight steps are executed for each LSA, as
described in Section 13 of [OSPFV2].  For IPv6, all the steps are
the same, except that Steps 2 and 3 are modified as follows:

  [stub or nssa or reserved scope changes]

It seems then that if the auto-config router picks a new router-id,
the legacy router will correct any damage.  Perhaps the legacy router
will do this for the wrong reasons (collisions, not stale leftovers
from a restart elsewhere), but it seems like it will take action to
fix it.

Acee - should this move to OSPF?  Others - No cross posting please.

Curtis


> On Oct 12, 2011, at 10:46 PM, Curtis Villamizar wrote:
>  
> > 
> > In message <4e95836d.4020...@riw.us>
> > Russ White writes:
> > 
> >> 
> >>>Russ> You need a unique identifier at the equipment level for
> >>>Russ> anything you intend to auto-configure --autoconfiguring
> >>>Russ> uniqueness is a very hard, probably impossible, problem on a
> >>>Russ> global scale. So we need to count on this one thing, no matter
> >>>Russ> what else we might need to back in to.
> >>> 
> >>>Russ> Now, it might be possible to some hash over a GPS location for
> >>>Russ> a "base," and then add on MAC addresses, or some such, but
> >>> 
> >>> We've assumed a unique MAC, which is 48 bits long. 
> >>> But OSPF router-id is 32 bits.What is the likelyhood of a collision 
> >>> in the bottom 32-bits of the MAC? 
> >> 
> >> Ah, I see the problem... There is a pretty high likelihood of a
> >> collision, actually, at least as long as you use multiple vendors in
> >> your home network. It's bound to happen to someone, someplace.
> >> 
> >> So, a suggestion to resolve this:
> >> 
> >> 1. Use the lower 32 bits of one of the mac addresses on the box as the
> >> initial id.
> >> 
> >> 2. Add a new field to the router capabilities that carries the full 48
> >> bit mac address, or even some munged together "longer id," based on
> >> multiple mac addresses on the device, or some such.
> > 
> > Not backwards compatible.  The older OSPF routers will see only the
> > non-unique 32 bits and the network won't work.
> > 
> >> 3. During initial setup, if you receive a capability that appears to be
> >> from yourself, you open this secondary id section to find out if it's
> >> really you, or someone else who happens to have the same 32 bit id.
> >> 
> >> 4. If it's really you, discard the packet.
> >> 
> >> 5. If it's not really you, and if the other router's "large id" is lower
> >> than yours, choose another mac address from which to take your local id,
> >> and restart your ospf process.
> >>
> >> 6. If it's not really you, and the other router's "large id" is higher
> >> than yours, then send a router capabilities LSA unicast to this "other
> >> router," so the "other router" knows to change its id.
> >>
> >> I don't think IS-IS would have this problem.
> >>
> >> :-)
> >>
> >> Russ
> >
> > If the other router doesn't implement the extension you've described,
> > the network is hosed forever.
> >
> > If you have more than one link you should receive the LSA (or LSPDU)
> > that you advertised.  If you have one link, you won't.
> >
> > If you receive a LSA (or LSPDU) that clearly you di

Re: [homenet] Thoughts about routing

[Curtis Villamizar]

In message <15691.1318514...@marajade.sandelman.ca>
Michael Richardson writes:
 
> > "Curtis" == Curtis Villamizar  writes:
> >> 2. Add a new field to the router capabilities that carries the
> >> full 48 bit mac address, or even some munged together "longer
> >> id," based on multiple mac addresses on the device, or some such.
>  
> Curtis> Not backwards compatible.  The older OSPF routers will see
> Curtis> only the non-unique 32 bits and the network won't work.
>  
> There are no zOSPF routers today.

Yes and there are/were ATM switches that implement RFC1577, LANE,
MPOA, and NHRP.  None of that worked very well and it all is
essentially abandoned work now.  Pre-existence alone is not a worth
while evaluation criteria.

If zOSPF works perfectly, including in the presence of legacy routers
which don't look at a new 48 bit mac address router-id extension, we
have no reason to continue the discussion.  We just indicate "use
zOSPF" and we're done.

There seems to be consensus that we're not done.

Curtis
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Thoughts about routing

[Jim Gettys]

On 10/13/2011 02:42 PM, Curtis Villamizar wrote:
>
> Yes and there are/were ATM switches that implement RFC1577, LANE,
> MPOA, and NHRP.  None of that worked very well and it all is
> essentially abandoned work now.  Pre-existence alone is not a worth
> while evaluation criteria.
>
> If zOSPF works perfectly, including in the presence of legacy routers
> which don't look at a new 48 bit mac address router-id extension, we
> have no reason to continue the discussion.  We just indicate "use
> zOSPF" and we're done.
>
> There seems to be consensus that we're not done.
>
On my part, I'm interested in understanding the following:
o scaling properties: I worry about the apartment building case, and
related dense mesh case.
o behaviour when routing both wired and wireless networks.
o multicast behaviour and impact on wireless networks.
o running code
And I'll ask the same about any other routing protocol you wish to
name.  I'm an equal opportunity parade rainer...
- Jim


___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Thoughts about routing

[Curtis Villamizar]

In message <14861.1318513...@marajade.sandelman.ca>
Michael Richardson writes:
 
> > "Mark" == Mark Andrews  writes:
> >> Or you solve the time problem some other way...
> >> 
> >> Batteries die too...  Jim
>  
> Mark> Indeed.  It should be a user servicable part.
>  
> Mark> As to solving it other way, "leap of faith" springs to mind.
>  
> DHCP has an NTP server option.  Does IP6CP?


If you are trying to validate keys or certificates or proteocol
extensions that require knowing the time of day, then using the DHCP
supplied NTP server might not be a great idea.

I'm not fond of protocols that rely on time or monotonically
increasing reboot counts and have no fallback.  I advocated in OSPF
discussions relevant to KARP (to no avail) having at least a fallback
to a mechanism in which time of day or reboot count was not
significant.

This means no certificate expiration check is possible for the
fallback but its better than no connectivity.  The lack of certificate
expiration can be compensated for by creating an explicit revokation
after the key expires and storing that.

Curtis
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Thoughts about routing

[Curtis Villamizar]

In message <4e973605.50...@freedesktop.org>
Jim Gettys writes:
 
> On 10/13/2011 02:42 PM, Curtis Villamizar wrote:
> >
> > Yes and there are/were ATM switches that implement RFC1577, LANE,
> > MPOA, and NHRP.  None of that worked very well and it all is
> > essentially abandoned work now.  Pre-existence alone is not a worth
> > while evaluation criteria.
> >
> > If zOSPF works perfectly, including in the presence of legacy routers
> > which don't look at a new 48 bit mac address router-id extension, we
> > have no reason to continue the discussion.  We just indicate "use
> > zOSPF" and we're done.
> >
> > There seems to be consensus that we're not done.
> >
> On my part, I'm interested in understanding the following:
> o scaling properties: I worry about the apartment building case, and
>   related dense mesh case.

Yep.  OSPF as is may not be appropriate for wireless mesh.  WG needs
to consider this.

> o behaviour when routing both wired and wireless networks.
> o multicast behaviour and impact on wireless networks.
> o running code

Running code is too seldom available when the IETF rushes forward
these days.  A reference implementation would be great.  I know which
code base you have in mind.

> And I'll ask the same about any other routing protocol you wish to
> name.  I'm an equal opportunity parade rainer...
> - Jim

I haven't checked cerowrt to see how much configuration is required of
OSPF.  If it is quagga, then a router-id has to be configured and each
interface has to have OSPF explicitly enabled all with a Cisco style
line oriented config.

Curtis
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Thoughts about routing

[Joe Touch]

On Oct 13, 2011, at 1:30 PM, Curtis Villamizar  wrote:
> I'm not fond of protocols that rely on time or monotonically
> increasing reboot counts and have no fallback.

+1

Let's not add time as an attack vector. 

Joe

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Thoughts about routing

[Jim Gettys]

On 10/13/2011 05:40 PM, Curtis Villamizar wrote:
> In message <4e973605.50...@freedesktop.org>
> Jim Gettys writes:
>  
>> On 10/13/2011 02:42 PM, Curtis Villamizar wrote:
>>> Yes and there are/were ATM switches that implement RFC1577, LANE,
>>> MPOA, and NHRP.  None of that worked very well and it all is
>>> essentially abandoned work now.  Pre-existence alone is not a worth
>>> while evaluation criteria.
>>>
>>> If zOSPF works perfectly, including in the presence of legacy routers
>>> which don't look at a new 48 bit mac address router-id extension, we
>>> have no reason to continue the discussion.  We just indicate "use
>>> zOSPF" and we're done.
>>>
>>> There seems to be consensus that we're not done.
>>>
>> On my part, I'm interested in understanding the following:
>> o scaling properties: I worry about the apartment building case, and
>>   related dense mesh case.
> Yep.  OSPF as is may not be appropriate for wireless mesh.  WG needs
> to consider this.
>
>> o behaviour when routing both wired and wireless networks.
>> o multicast behaviour and impact on wireless networks.
>> o running code
> Running code is too seldom available when the IETF rushes forward
> these days.  A reference implementation would be great.  I know which
> code base you have in mind.

I've been badly burned by standards committees in the past on this
topic.  Happens to be the IEEE folks, however.  Ergo my belief in both
running code and testing in diverse environments outside of laboratories
and meeting rooms.

And, in the case of the home router market, code has to come from some
place. Advocating something that has to be built from scratch seems like
a losing strategy.
>
>> And I'll ask the same about any other routing protocol you wish to
>> name.  I'm an equal opportunity parade rainer...
>> - Jim
> I haven't checked cerowrt to see how much configuration is required of
> OSPF.  
All Dave did was build and package quagga so that others could
conveniently start to play.

> If it is quagga, then a router-id has to be configured and each
> interface has to have OSPF explicitly enabled all with a Cisco style
> line oriented config.
Quagga has been packaged.  You can build other  stuff and packaged it
too, and the code is available to be modified.
- Jim


___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Thoughts about routing

[Lorenzo Colitti]

On Mon, Oct 10, 2011 at 14:16, Curtis Villamizar  wrote:

> Random number selection for router-id and this sort of recovery would
> solve the zero config OSPF issue related to router-id selection.
>
> Not yet solved in existing zospf draft (afaik) but solvable.


zOSPF says what do do in the case of collisions if the router with duplicate
ID is on the same link, but not if it is elsewhere. However, I think it can
be made to work like this:

1. On startup, choose the router ID you had on last boot (if available) or a
random number.
2. Start OSPF with this router ID.
3. If you see a hello packet from a neighbour with your own router ID, you
have a collision on the local link. Change it and back off.
4. If you see a router LSA listing you as a neighbour, but the router ID
that originated this LSA is not a neighbour of yours, you have a duplicate
router ID. Change it and back off.

Are there any cases this does not cover?

As to what to do if there is a collision, I'm not sure. zOSPF says what you
and your neighbours should do if the colliding router is on your link, but I
don't know if that's enough if the colliding router is elsewhere. Any OSPF
experts know the answer to this?
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Thoughts about routing

[Michael Richardson]

> "Joe" == Joe Touch  writes:
Joe> On Oct 13, 2011, at 1:30 PM, Curtis Villamizar
Joe>  wrote:
>> I'm not fond of protocols that rely on time or monotonically
>> increasing reboot counts and have no fallback.

Joe> +1

Joe> Let's not add time as an attack vector.

So, hypothetical attacks via DHCP, which require access to impersonate
the DHCP or PPP server of the ISP are more important than getting a
notion about time so you can prevent DNS attacks?

Tet's talk about what other things you can do if you can hijack the
network connection like that... and how many of them are resolved if
DNSSEC can be used.






pgpc0cm0EGwr0.pgp
Description: PGP signature
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Thoughts about routing

[Acee Lindem]

On Oct 13, 2011, at 9:09 PM, Lorenzo Colitti wrote:

On Mon, Oct 10, 2011 at 14:16, Curtis Villamizar 
mailto:cur...@occnc.com>> wrote:
Random number selection for router-id and this sort of recovery would
solve the zero config OSPF issue related to router-id selection.

Not yet solved in existing zospf draft (afaik) but solvable.

zOSPF says what do do in the case of collisions if the router with duplicate ID 
is on the same link, but not if it is elsewhere. However, I think it can be 
made to work like this:

1. On startup, choose the router ID you had on last boot (if available) or a 
random number.
2. Start OSPF with this router ID.
3. If you see a hello packet from a neighbour with your own router ID, you have 
a collision on the local link. Change it and back off.
4. If you see a router LSA listing you as a neighbour, but the router ID that 
originated this LSA is not a neighbour of yours, you have a duplicate router 
ID. Change it and back off.

Are there any cases this does not cover?

As to what to do if there is a collision, I'm not sure. zOSPF says what you and 
your neighbours should do if the colliding router is on your link, but I don't 
know if that's enough if the colliding router is elsewhere. Any OSPF experts 
know the answer to this?

A new OSPFv3 mechanism is required in support of this. Today, any LSA received 
with the OSPFv3 router's Router-ID is considered to be a stale self-originated 
LSA.

Thanks,
Acee

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Thoughts about routing

[Fred Baker]

On Oct 13, 2011, at 6:09 PM, Lorenzo Colitti wrote:

> On Mon, Oct 10, 2011 at 14:16, Curtis Villamizar  wrote:
> Random number selection for router-id and this sort of recovery would
> solve the zero config OSPF issue related to router-id selection.
> 
> Not yet solved in existing zospf draft (afaik) but solvable.
> 
> zOSPF says what do do in the case of collisions if the router with duplicate 
> ID is on the same link, but not if it is elsewhere. However, I think it can 
> be made to work like this:
> 
> 1. On startup, choose the router ID you had on last boot (if available) or a 
> random number.
> 2. Start OSPF with this router ID.
> 3. If you see a hello packet from a neighbour with your own router ID, you 
> have a collision on the local link. Change it and back off.
> 4. If you see a router LSA listing you as a neighbour, but the router ID that 
> originated this LSA is not a neighbour of yours, you have a duplicate router 
> ID. Change it and back off.
> 
> Are there any cases this does not cover?

On number 3, there is a race condition. If the router took some time to boot, 
this takes care of itself; if this is a flash restart (OSPF started up within 
one or two HELLO intervals of going down) there is some possibility that the 
neighbor simply has some old state. Note that the OSPF Spec has the router 
initially send a HELLO and then start looking for HELLOs from peers that 
announce it; it would be good for OSPF to instead wait for one HELLO interval 
so that it sees the HELLOs from other routers on the LAN before announcing 
itself if it's not sure about the uniqueness of its RID.

On number 4, that would be a Router LSA or Network LSA; in a LAN subnet, the 
RIDs of the routers in the subnet are in the Network LSA.

> As to what to do if there is a collision, I'm not sure. zOSPF says what you 
> and your neighbours should do if the colliding router is on your link, but I 
> don't know if that's enough if the colliding router is elsewhere. Any OSPF 
> experts know the answer to this?

What the router needs to do is 

(1) NOT send an LSA using the RID into the LS database, as this will confuse 
everyone else 
(2) it would be good etiquette to announce one more HELLO in which it lists no 
neighbors so that all of its neighbors, and especially the DR, think it's going 
down. That way it doesn't get into the Network LSA, or if it already did, it 
will be removed.
(3) It has to change its RID and start from the beginning.

The good news is that it now has some subset of the LSA Database, so the second 
exchange will be somewhat quicker, and it already knows who the DR is in at 
least that subnet.

"Random number" is a good description of the source for the RID. MAC Addresses 
and equipment serial numbers tend to be reasonable seeds, and a router will 
usually have more than one such. If it used one MAC address and that didn't 
play, it might try another. If push comes to shove, a call to random() is 
probably in order.
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Thoughts about routing

[Curtis Villamizar]

, it might try another. If push comes to
> shove, a call to random() is probably in order.

Did anyone read my prior email in which I cited the RFCs and section
numbers and quoted the relevant text?

If not, look for:

  Message-Id: <201110131811.p9dibe9i021...@gateway.ipv6.occnc.com>
  To: Acee Lindem 
  cc: "cur...@occnc.com" , Russ White ,
  "homenet@ietf.org" 
  Reply-To: cur...@occnc.com
  From: Curtis Villamizar 
  Subject: Re: [homenet] Thoughts about routing
  In-reply-to: Your message of "Thu, 13 Oct 2011 05:55:07 EDT."
 <1e8bbe2e-357a-4681-bb84-4e694afd9...@ericsson.com>
  Date: Thu, 13 Oct 2011 11:11:14 -0700

We should probably pick up this thread from that message (which had
relevant detail, but no one replied to it).

Curtis
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Thoughts about routing

[Fred Baker]

On Oct 15, 2011, at 6:35 PM, Curtis Villamizar wrote:

> All adjacencies have to go down to change router-id.  The other end of
> the adjacency will withdraw its side of the adjacency.

well, yes, and if I change my routerid, all adjacencies will go down. Not sure 
what the point here is...
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Thoughts about routing

[Robert Raszuk]

Hi Fred,

I think the point is that in your algorithm you stated this step:

> (3) It has to change its RID and start from the beginning.

I would say (perhaps in line with Curtis comment) that this step is 
unrealistic. RID for many reasons (for example mpls-te) is hard 
configured in link state IGPs.


Worse - some vendors - do base on this their very cool hack to forward 
v6 traffic over v4 TE LSPs.


So I think statement that router has to change it's RID is operationally 
non starter.


Cheers,
R.


On Oct 15, 2011, at 6:35 PM, Curtis Villamizar wrote:


All adjacencies have to go down to change router-id.  The other end of
the adjacency will withdraw its side of the adjacency.


well, yes, and if I change my routerid, all adjacencies will go down. Not sure 
what the point here is...
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet




___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Thoughts about routing

[David Täht]

On 10/16/2011 03:35 AM, Curtis Villamizar wrote:
> In message <0651f29f-c816-4a23-bd6f-c791ce89b...@cisco.com>
> Fred Baker writes:
>  
>>  
>> On Oct 13, 2011, at 6:09 PM, Lorenzo Colitti wrote:
>>  
>>> On Mon, Oct 10, 2011 at 14:16, Curtis Villamizar  wrote:
>>> Random number selection for router-id and this sort of recovery would
>>> solve the zero config OSPF issue related to router-id selection.
>>>
>>> Not yet solved in existing zospf draft (afaik) but solvable.

Just as a data point, the babel and AHCP protocols creates a router-id
from a EUI-64. problem solved, there.

-- 
Dave Täht

<>___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Thoughts about routing

[Fred Baker]

On Oct 15, 2011, at 10:06 PM, Robert Raszuk wrote:
> RID for many reasons (for example mpls-te) is hard configured in link state 
> IGPs.
> 
> Worse - some vendors - do base on this their very cool hack to forward v6 
> traffic over v4 TE LSPs.

We appear to have a fundamental "you're on a misconfigured wavelength" problem. 
How many routers do you find using traffic-engineered MPLS LSPs within people's 
homes? How much do you find "hard configured" in a "zero configuration" 
environment?

Earth to Robert...

> So I think statement that router has to change it's RID is operationally non 
> starter.

If the router, operating in a zero configuration environment and concocting its 
RID from some form of random process starting from an equipment differentiable 
seed, finds that its RID duplicates another router's RID, it has three choices. 
It can

  - not change it and screw up the network, which creates an unhappy customer 
and probably blows the entire margin in the router on a customer support call. 

  - not change it and effectively brick itself, which creates an unhappy 
customer and probably blows the entire margin in the router on a customer 
support call. 

  - change the router id, making the network work as the customer expects, 
resulting in a happy customer and the margin staying in the vendor's pocket. 

Pick one.
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Thoughts about routing

[Lorenzo Colitti]

On Sun, Oct 16, 2011 at 16:47, David Täht  wrote:

> Just as a data point, the babel and AHCP protocols creates a router-id
> from a EUI-64. problem solved, there.


And when there is a collision, what happens? The network breaks?

Note that I say "when" there is a collision and not "if" because:

- MAC addresses are supposed to be unique, but in practice, there are
duplicates.
- If a home router supports MAC address cloning, then there are more
duplicates.
- When you try to fit a 64-bit EUI-64 into 32 bits, sooner or later there
will be a collision, because, as my mother used to say, "you can't fit a
quart into a pint pot".
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Thoughts about routing

[Robert Raszuk]

Fred and Curtis,

Many thx for your emails. Indeed perhaps my example of MPLS-TE hack was 
a bit unreal for this alias - you are right. However I intended 
(apparently quite poorly) to express two points which while following 
from time to time this group I keep struggle myself with.


Point #1:

If we are dealing with "zero configuration" network why do I need 
routing protocols ? Why do I need in fact more then one gateway or two 
in the case of multi-homed Grandma ? If I want to build some subnets 
inside I will get an extra router or two, but I see no magic how those 
routers even if coming from the most brilliant vendor will be able to 
guess out of the box my intentions.


Point #2:

If I need more then reliable exit to the internet and need to have few 
subnets at home (like I do today) Fred can call me UFO, but I fail to 
see how difficult is to type two lines to establish a loopback address 
(which I will use from time to time to ssh to the box to check why it is 
not working) or to type 4 more lines to enable any IGP - if ever needed.


So if there is any document already written which I may have missed 
which has the answer to the above I appreciate sharing a pointer.


Automation is great we should have it where needed .. it is just that I 
am completely not convinced that it is needed here.


Best regards,
R.



In message<4e9a6657.70...@raszuk.net>
Robert Raszuk writes:


Hi Fred,

I think the point is that in your algorithm you stated this step:

  >  (3) It has to change its RID and start from the beginning.

I would say (perhaps in line with Curtis comment) that this step is
unrealistic. RID for many reasons (for example mpls-te) is hard
configured in link state IGPs.


If it is hard configured, then is has to be configured correctly.
Otherwise you have a conflict among two configured RID, then you have
a persistent non-working network.

If a autoconfig guy comes along and stomps on it, then only the
autoconfig guy backs off.


Worse - some vendors - do base on this their very cool hack to forward
v6 traffic over v4 TE LSPs.

So I think statement that router has to change it's RID is
operationally non starter.


So you are saying that a vendor has a hack (private undocumented
extension might be the market-speak) that is not backwards compatible
to other implementations *of a full standard* and we can't create a
backwards compatible extension because it would interfere with the
hack?  (which you think is a very cool extension?)


Cheers,
R.


On Oct 15, 2011, at 6:35 PM, Curtis Villamizar wrote:


All adjacencies have to go down to change router-id.  The other end of
the adjacency will withdraw its side of the adjacency.


well, yes, and if I change my routerid, all adjacencies will go
down. Not sure what the point here is...


Curtis




___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Thoughts about routing

[Curtis Villamizar]

In message <4e9a8c15.2030...@gmail.com>
David Täht writes:
 
> On 10/16/2011 03:35 AM, Curtis Villamizar wrote:
> > In message <0651f29f-c816-4a23-bd6f-c791ce89b...@cisco.com>
> > Fred Baker writes:
> >  
> >>  
> >> On Oct 13, 2011, at 6:09 PM, Lorenzo Colitti wrote:
> >>  
> >>> On Mon, Oct 10, 2011 at 14:16, Curtis Villamizar  wrote:
> >>> Random number selection for router-id and this sort of recovery would
> >>> solve the zero config OSPF issue related to router-id selection.
> >>>
> >>> Not yet solved in existing zospf draft (afaik) but solvable.
>  
> Just as a data point, the babel and AHCP protocols creates a router-id
> from a EUI-64. problem solved, there.
>  
> -- 
> Dave Täht


When using a 64 bit value to create a unique 32 bit value there is a
finite but small probability of a collision with OSPF.

Babel is experimental and AHCP is a draft and we aren't going to drop
a full standard because of a router-id issue.  Not that I don't think
Babel and AHCP are promising work.  Certainly flooding in a dense
wireless mesh is not a good thing as Jim pointed out but example so
there are cases where OSPF or ISIS is not applicable.

The topic at the moment is OSPF (and ISIS) so problem not solved by
EUI-64.

Curtis
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Thoughts about routing

[Curtis Villamizar]

In message 
Fred Baker writes:
 
>  
> On Oct 15, 2011, at 6:35 PM, Curtis Villamizar wrote:
>  
> > All adjacencies have to go down to change router-id.  The other end of
> > the adjacency will withdraw its side of the adjacency.
>  
> well, yes, and if I change my routerid, all adjacencies will go
> down. Not sure what the point here is...


If you've just booted up and there is a one in a few million chance
that you'll get half way on the database load on the first adjacency
to come up and have to start over, then I don't think it is a big
deal.

If the point is what if you've been up and running for a while, then
perhaps we need a holdup timer to see if the problem clear if one or
more adjacencies has previously completed a full database load.  This
means that on a power up of everything, there will be merged islands
with conflicts and the conflicts won't resolve until the holdup timer
expires.  Some advice on being slow to correct "staleness" in this
situation would prevent the current OSPF staleness correction wars
(each corrects the other as fast as it can if you manage to configure
a conflict today - apparently common when people clone and edit
configs but occasionally forget to change the router-id - I wouldn't
know since we machine generated the configs where I used to play).

Curtis

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Thoughts about routing

[Curtis Villamizar]

In message <4e9a6657.70...@raszuk.net>
Robert Raszuk writes:
 
> Hi Fred,
>  
> I think the point is that in your algorithm you stated this step:
>  
>  > (3) It has to change its RID and start from the beginning.
>  
> I would say (perhaps in line with Curtis comment) that this step is
> unrealistic. RID for many reasons (for example mpls-te) is hard
> configured in link state IGPs.

If it is hard configured, then is has to be configured correctly.
Otherwise you have a conflict among two configured RID, then you have
a persistent non-working network.

If a autoconfig guy comes along and stomps on it, then only the
autoconfig guy backs off.

> Worse - some vendors - do base on this their very cool hack to forward
> v6 traffic over v4 TE LSPs.
>  
> So I think statement that router has to change it's RID is
> operationally non starter.

So you are saying that a vendor has a hack (private undocumented
extension might be the market-speak) that is not backwards compatible
to other implementations *of a full standard* and we can't create a
backwards compatible extension because it would interfere with the
hack?  (which you think is a very cool extension?)

> Cheers,
> R.
>  
> > On Oct 15, 2011, at 6:35 PM, Curtis Villamizar wrote:
> >
> >> All adjacencies have to go down to change router-id.  The other end of
> >> the adjacency will withdraw its side of the adjacency.
> >
> > well, yes, and if I change my routerid, all adjacencies will go
> >down. Not sure what the point here is...

Curtis
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Thoughts about routing - trends

[Jim Gettys]

On 10/07/2011 03:48 AM, Fred Baker wrote:
> 4) The use of OLSR in mesh network scenarios 
>
> Jim Gettys commented on the fact of OLSR use. The general sense of the room 
> was that OLSRv2 is interesting but out of scope for this discussion as mesh 
> networks are quite different from typical residential and SOHO networks.
>  
Actually, I have no opinion of OLSR, Babel, Babelz or OSPF; it's not my
area of expertise. 

Babel/BabelZ is appearing in CeroWrt today as the people who are
interested in such things are doing the work (we don't need a routing
protocol in the simple single home router case), and it provided the
functionality we needed.

For those who want something else, quagga is in the CeroWrt build for
your hacking pleasure.

And I'm not advocating the homenet working group do anything unusual
about routing at this date; as I said, it's not my area of expertise.

Having said this, I do note the following technological trends:

1) As soon as we get real "plug and play" routers that don't need manual
configuration that work, we'll see a lot more routers in a home
environment.  Other radio technologies (e.g. zigbee) may encourage this
trend.  It seemed like the working group agreed that getting to the
point that just hooking things together would really "just worked" was a
fundamental requirement (and I agree entirely with this sentiment, as it
reflects reality of what already happens in the homes of hackers and
non-hackers alike).

2) wireless is much cheaper to implement than wired networking,
particularly in most houses where pulling cable is hard.  I know this
first hand, where I've pulled a lot of cat 6 and wish I could get it to
places I don't have it.

Unless power line networking really works, I believe that this trend
isn't going to change.  Is there any progress in this area?  I've seen
many promises, and few reliable working products.

3) As soon as you have two routers, you have at least two paths; the
wired connection between them and the wireless.  You may have 3 paths,
if you have both 2.4 and 5ghz radios. Frequency diversity routing
becomes immediately interesting, along with using your ethernet when
it's available in preference to wireless.

4) an apartment building look like a mesh, and possibly with multiple
backhauls possibly with multiple ISP's. One should at least think about
what happens when you have "homes", in such a building, and make sure
nothing breaks. Wireless is messy: it isn't limited to where a wire
goes.  Taking down an entire apartment building/blocks/city would not be
fun.  I know, I've been there (at least to the point of taking down
buildings, and came within a week of a much larger scale disaster).

If you believe 1 + 2 + 3 +4  (as I do), then if you look a few years
out, you end up with something in the "home" that begins to resemble
very strongly what the community mesh networking folks are doing at a
higher scale geographically and in terms of # of nodes today, with
many/most of the same concerns and solutions. Understanding the problems
they've faced/are facing is therefore worth a bit of investment; Radio
diversity is one of the concerns, and interference (of various sorts).

Julius' talk about why frequency diversity is an issue is here:

http://www.youtube.com/watch?v=1VNzm0shSA8

While the issues outlined above are not where home networking is today,
my gut feel is they will be in five years.

If there is *anything* I can urge on the group, is to respect the
scaling problems that can/will occur, and to internalise wireless
!=wired: wireless goes where wireless goes and does not behave like
ethernet. The group needs to ensure nothing "bad" happens when people
start building systems in ways you don't expect, particularly in an
apartment building.  The challenge is balancing the reality of how
wireless works, with "just works" automatic configuration, with "fail
safe" behaviour.
- Jim







___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Thoughts about routing - trends

[Ulrich Herberg]

Hi Jim,

I fully agree with you. Declaring OLSRv2 etc. out of scope just because
"a home is not a mesh network" seems simplistic to me. As you explained
in your mail, many of the problems that mesh networks already solve
successfully today, can be very similar in a home: dynamic topology, no
skilled network operator centrally managing the devices, wireless and
wired devices, limited resources on the routers etc. These were exactly
the motivation for developing such protocols in MANET.

Best regards
Ulrich

On 10/12/11 3:10 AM, Jim Gettys wrote:
> On 10/07/2011 03:48 AM, Fred Baker wrote:
>> 4) The use of OLSR in mesh network scenarios 
>>
>> Jim Gettys commented on the fact of OLSR use. The general sense of the room 
>> was that OLSRv2 is interesting but out of scope for this discussion as mesh 
>> networks are quite different from typical residential and SOHO networks.
>>  
> Actually, I have no opinion of OLSR, Babel, Babelz or OSPF; it's not my
> area of expertise. 
>
> Babel/BabelZ is appearing in CeroWrt today as the people who are
> interested in such things are doing the work (we don't need a routing
> protocol in the simple single home router case), and it provided the
> functionality we needed.
>
> For those who want something else, quagga is in the CeroWrt build for
> your hacking pleasure.
>
> And I'm not advocating the homenet working group do anything unusual
> about routing at this date; as I said, it's not my area of expertise.
>
> Having said this, I do note the following technological trends:
>
> 1) As soon as we get real "plug and play" routers that don't need manual
> configuration that work, we'll see a lot more routers in a home
> environment.  Other radio technologies (e.g. zigbee) may encourage this
> trend.  It seemed like the working group agreed that getting to the
> point that just hooking things together would really "just worked" was a
> fundamental requirement (and I agree entirely with this sentiment, as it
> reflects reality of what already happens in the homes of hackers and
> non-hackers alike).
>
> 2) wireless is much cheaper to implement than wired networking,
> particularly in most houses where pulling cable is hard.  I know this
> first hand, where I've pulled a lot of cat 6 and wish I could get it to
> places I don't have it.
>
> Unless power line networking really works, I believe that this trend
> isn't going to change.  Is there any progress in this area?  I've seen
> many promises, and few reliable working products.
>
> 3) As soon as you have two routers, you have at least two paths; the
> wired connection between them and the wireless.  You may have 3 paths,
> if you have both 2.4 and 5ghz radios. Frequency diversity routing
> becomes immediately interesting, along with using your ethernet when
> it's available in preference to wireless.
>
> 4) an apartment building look like a mesh, and possibly with multiple
> backhauls possibly with multiple ISP's. One should at least think about
> what happens when you have "homes", in such a building, and make sure
> nothing breaks. Wireless is messy: it isn't limited to where a wire
> goes.  Taking down an entire apartment building/blocks/city would not be
> fun.  I know, I've been there (at least to the point of taking down
> buildings, and came within a week of a much larger scale disaster).
>
> If you believe 1 + 2 + 3 +4  (as I do), then if you look a few years
> out, you end up with something in the "home" that begins to resemble
> very strongly what the community mesh networking folks are doing at a
> higher scale geographically and in terms of # of nodes today, with
> many/most of the same concerns and solutions. Understanding the problems
> they've faced/are facing is therefore worth a bit of investment; Radio
> diversity is one of the concerns, and interference (of various sorts).
>
> Julius' talk about why frequency diversity is an issue is here:
>
> http://www.youtube.com/watch?v=1VNzm0shSA8
>
> While the issues outlined above are not where home networking is today,
> my gut feel is they will be in five years.
>
> If there is *anything* I can urge on the group, is to respect the
> scaling problems that can/will occur, and to internalise wireless
> !=wired: wireless goes where wireless goes and does not behave like
> ethernet. The group needs to ensure nothing "bad" happens when people
> start building systems in ways you don't expect, particularly in an
> apartment building.  The challenge is balancing the reality of how
> wireless works, with "just works" automatic configuration, with "fail
> safe" behaviour.
> - Jim
>
>
>
>
>
>
>
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Thoughts about routing - trends

[C Chauvenet]

Hi Jim, 

I agree with you.

Let me just add a few words on #2 : 

You are absolutely right that pulling cable is hard and expensive.
That is the rationale of PLC : Using existing wires.

PLC is already used reliabily for high speed networking, but you are correct 
that it is
not as popular as Wireless. Mostly because networking devices already embed a 
Wifi and/Or Ethernet
interface, rather than a PLC interface. 
So people don't see the need of buying additional material for a connectivity 
they already have…

Though people use PLC because they feel surrounded by RF, or they cannot reach 
some point of the network with wireless, 
or the PLC device is provided by their ISP (like in France).
(There are others reasons for using PLC outside the home, but I think it is out 
of the scope of Homenet).

PLC also suffers from a lack of standardization, and different 
technologies/Standards are often non-interoperable, or simply cannot coexist on 
the same electrical grid.

An effort is ongoing in IEEE P1901.2 to create a standard for low frequency 
narrowband PLC.

Just my 2 cts,
Cédric.

Le 11 oct. 2011 à 21:10, Jim Gettys a écrit :

> On 10/07/2011 03:48 AM, Fred Baker wrote:
>> 4) The use of OLSR in mesh network scenarios 
>> 
>> Jim Gettys commented on the fact of OLSR use. The general sense of the room 
>> was that OLSRv2 is interesting but out of scope for this discussion as mesh 
>> networks are quite different from typical residential and SOHO networks.
>> 
> Actually, I have no opinion of OLSR, Babel, Babelz or OSPF; it's not my
> area of expertise. 
> 
> Babel/BabelZ is appearing in CeroWrt today as the people who are
> interested in such things are doing the work (we don't need a routing
> protocol in the simple single home router case), and it provided the
> functionality we needed.
> 
> For those who want something else, quagga is in the CeroWrt build for
> your hacking pleasure.
> 
> And I'm not advocating the homenet working group do anything unusual
> about routing at this date; as I said, it's not my area of expertise.
> 
> Having said this, I do note the following technological trends:
> 
> 1) As soon as we get real "plug and play" routers that don't need manual
> configuration that work, we'll see a lot more routers in a home
> environment.  Other radio technologies (e.g. zigbee) may encourage this
> trend.  It seemed like the working group agreed that getting to the
> point that just hooking things together would really "just worked" was a
> fundamental requirement (and I agree entirely with this sentiment, as it
> reflects reality of what already happens in the homes of hackers and
> non-hackers alike).
> 
> 2) wireless is much cheaper to implement than wired networking,
> particularly in most houses where pulling cable is hard.  I know this
> first hand, where I've pulled a lot of cat 6 and wish I could get it to
> places I don't have it.
> 
> Unless power line networking really works, I believe that this trend
> isn't going to change.  Is there any progress in this area?  I've seen
> many promises, and few reliable working products.
> 
> 3) As soon as you have two routers, you have at least two paths; the
> wired connection between them and the wireless.  You may have 3 paths,
> if you have both 2.4 and 5ghz radios. Frequency diversity routing
> becomes immediately interesting, along with using your ethernet when
> it's available in preference to wireless.
> 
> 4) an apartment building look like a mesh, and possibly with multiple
> backhauls possibly with multiple ISP's. One should at least think about
> what happens when you have "homes", in such a building, and make sure
> nothing breaks. Wireless is messy: it isn't limited to where a wire
> goes.  Taking down an entire apartment building/blocks/city would not be
> fun.  I know, I've been there (at least to the point of taking down
> buildings, and came within a week of a much larger scale disaster).
> 
> If you believe 1 + 2 + 3 +4  (as I do), then if you look a few years
> out, you end up with something in the "home" that begins to resemble
> very strongly what the community mesh networking folks are doing at a
> higher scale geographically and in terms of # of nodes today, with
> many/most of the same concerns and solutions. Understanding the problems
> they've faced/are facing is therefore worth a bit of investment; Radio
> diversity is one of the concerns, and interference (of various sorts).
> 
> Julius' talk about why frequency diversity is an issue is here:
> 
> http://www.youtube.com/watch?v=1VNzm0shSA8
> 
> While the issues outlined above are not where home networking is today,
> my gut feel is they will be in five years.
> 
> If there is *anything* I can urge on the group, is to respect the
> scaling problems that can/will occur, and to internalise wireless
> !=wired: wireless goes where wireless goes and does not behave like
> ethernet. The group needs to ensure nothing "bad" happens when people
> start building systems in ways

Re: [homenet] Thoughts about routing - trends

[Fred Baker]

On Oct 12, 2011, at 3:44 AM, C Chauvenet wrote:

> You are absolutely right that pulling cable is hard and expensive.

Pulling cable is indeed hard and expensive. In my experience, it is the right 
thing for some applications, such as TV and my home office. Personally, I have 
both wired and wireless throughout the house; my personal rule is that I use 
the shared wireless network for activities that move around, to provide 
convenience at the expense of consistency and bandwidth, and wired for things 
that stand still, to provide stable bandwidth at the price of a one-time wiring 
effort.
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Thoughts about routing - trends

[Russ White]

>> You are absolutely right that pulling cable is hard and expensive.
> 
> Pulling cable is indeed hard and expensive. In my experience, it is the right 
> thing for some applications, such as TV and my home office. Personally, I 
> have both wired and wireless throughout the house; my personal rule is that I 
> use the shared wireless network for activities that move around, to provide 
> convenience at the expense of consistency and bandwidth, and wired for things 
> that stand still, to provide stable bandwidth at the price of a one-time 
> wiring effort.

I do the same --I pull cable for televisions, and even for locations
where a desktop or laptop is going to be sitting on a regular basis. So
I think we should expect wired and wireless as the norm, rather than
expecting wireless all the time.

While I wouldn't want to rule OLSRv2 completely out, I think it should
compete head to head with an extended OSPF and an extended IS-IS, or
even other efforts afoot. I'd rather see requirements first, and a good
solid evaluation of what's available against those requirements, rather
than choosing technologies out of the gate.

:-)

Russ
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Thoughts about routing - trends

[C Chauvenet]

Le 12 oct. 2011 à 13:51, Russ White a écrit :

> 
>>> You are absolutely right that pulling cable is hard and expensive.
>> 
>> Pulling cable is indeed hard and expensive. In my experience, it is the 
>> right thing for some applications, such as TV and my home office. 
>> Personally, I have both wired and wireless throughout the house; my personal 
>> rule is that I use the shared wireless network for activities that move 
>> around, to provide convenience at the expense of consistency and bandwidth, 
>> and wired for things that stand still, to provide stable bandwidth at the 
>> price of a one-time wiring effort.
> 
> I do the same --I pull cable for televisions, and even for locations
> where a desktop or laptop is going to be sitting on a regular basis. So
> I think we should expect wired and wireless as the norm, rather than
> expecting wireless all the time.


I agree.
I may have precised "pulling *NEW* cable is hard and expensive" in my sentence.

> 
> While I wouldn't want to rule OLSRv2 completely out, I think it should
> compete head to head with an extended OSPF and an extended IS-IS, or
> even other efforts afoot. I'd rather see requirements first, and a good
> solid evaluation of what's available against those requirements, rather
> than choosing technologies out of the gate.
> 
> :-)

I think it is a good process, for each competing protocol.

> 
> Russ

Cédric.

> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet
> 


___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Thoughts about routing - scaling

[Jim Gettys]

I've alluded to having suffered from routing problems in the past, and
urged people to be very careful about scaling, and interacting with
unexpected/unintended neighbours, something that seldom happens in wired
networking.

I thought I'd elaborate slightly to help people focus on the problems.

Both of these experiences come from my tenure at OLPC, which attempted
to deploy mesh networking, where I worried about the base system
software (but not the networking, in particular; Michailis Bletsas was
in charge of that).  Both added grey hair to my head and scars to our
backs.

1) we had a situation, in which one of our machines tickled a bug in
existing routers being used in an apartment building causing most all of
the home networks in the apartment building to crash, to the point of
needing reboot.  It wasn't our bug; but it was sure our problem :-(.
This is about all I can say on an open list about what happened here.

The moral: lots of people can hear the packets you transmit; ensuring
nothing bad will happen is "interesting".  The packets escape into the
"ether" and may have consequences you don't anticipate.  And just
because you think that there are only a few participants in a
conversation doesn't make it so.

2) The 802.11s committee, in their infinite wisdom, specified a routing
protocol at layer 2. At least in the draft standard we were working
from, the properties of this routing algorithm had the consequence of
N^2 messages where N was determined by the number of machines that could
hear each other simultaneously (each machine that heard you looking for
the exit to the mesh would each turn around and send another message). I
don't know if the current version of the standard is so brain-dead or
not: the committee had ruled the scaling problem "out of scope" for the
group: after all, no one would ever think of running a mesh in such a
circumstance.  Reality is that kids show up at school at the same time,
(or people enter a conference room at the same time), and it happens.
Let us not suffer from the attitude the IEEE did with 802.11s.

 It doesn't take many machines (somewhere between 15 and 30), that can
hear each other to fry your channel entirely.  It was so bad that we
could only get about 14-16 bits into the preamble of the message before
someone else would transmit and step on the attempted transmission:
another words, the network completely collapsed with scale.

We called this the "dense mesh" problem. Any routing protocol used on
wireless should be evaluated for its scaling properties carefully.

Your first ARP would, of course, trigger this melt down.

The third problem we had in networking we didn't figure out at all: that
awaited my personal encounter with bufferbloat to understand.
- Jim

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Thoughts about routing - trends

[Curtis Villamizar]

In message <4e9494a9.4030...@freedesktop.org>
Jim Gettys writes:
 
> Having said this, I do note the following technological trends:
>  
> 1) As soon as we get real "plug and play" routers that don't need manual
> configuration that work, we'll see a lot more routers in a home
> environment.  Other radio technologies (e.g. zigbee) may encourage this
> trend.  It seemed like the working group agreed that getting to the
> point that just hooking things together would really "just worked" was a
> fundamental requirement (and I agree entirely with this sentiment, as it
> reflects reality of what already happens in the homes of hackers and
> non-hackers alike).
>  
> 2) wireless is much cheaper to implement than wired networking,
> particularly in most houses where pulling cable is hard.  I know this
> first hand, where I've pulled a lot of cat 6 and wish I could get it to
> places I don't have it.
>  
> Unless power line networking really works, I believe that this trend
> isn't going to change.  Is there any progress in this area?  I've seen
> many promises, and few reliable working products.
>  
> 3) As soon as you have two routers, you have at least two paths; the
> wired connection between them and the wireless.  You may have 3 paths,
> if you have both 2.4 and 5ghz radios. Frequency diversity routing
> becomes immediately interesting, along with using your ethernet when
> it's available in preference to wireless.
>  
> 4) an apartment building look like a mesh, and possibly with multiple
> backhauls possibly with multiple ISP's. One should at least think about
> what happens when you have "homes", in such a building, and make sure
> nothing breaks. Wireless is messy: it isn't limited to where a wire
> goes.  Taking down an entire apartment building/blocks/city would not be
> fun.  I know, I've been there (at least to the point of taking down
> buildings, and came within a week of a much larger scale disaster).
>  
> If you believe 1 + 2 + 3 +4  (as I do), then if you look a few years
> out, you end up with something in the "home" that begins to resemble
> very strongly what the community mesh networking folks are doing at a
> higher scale geographically and in terms of # of nodes today, with
> many/most of the same concerns and solutions. Understanding the problems
> they've faced/are facing is therefore worth a bit of investment; Radio
> diversity is one of the concerns, and interference (of various sorts).


Very good points.  Much of the discussion has been focused on the
single home in isolation.

Curtis
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Thoughts about routing - trends

[Ulrich Herberg]

On 10/12/11 7:51 PM, Russ White wrote:
> [...]
>
> While I wouldn't want to rule OLSRv2 completely out, I think it should
> compete head to head with an extended OSPF and an extended IS-IS, or
> even other efforts afoot. I'd rather see requirements first, and a good
> solid evaluation of what's available against those requirements, rather
> than choosing technologies out of the gate.

Hi Russ,

I fully agree. There should be an evaluation against the requirements.
My point was just not to rule out OLSRv2 (or other protocols) based on
the fact that a protocol is used, amongst other, in mesh network
deployments.

Ulrich
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Thoughts about routing - trends

[Curtis Villamizar]

In message <4e957f43.1060...@riw.us>
Russ White writes:
 
>  
> >> You are absolutely right that pulling cable is hard and expensive.
> > Pulling cable is indeed hard and expensive. In my experience, it is
> > the right thing for some applications, such as TV and my home
> > office. Personally, I have both wired and wireless throughout the
> > house; my personal rule is that I use the shared wireless network
> > for activities that move around, to provide convenience at the
> > expense of consistency and bandwidth, and wired for things that
> > stand still, to provide stable bandwidth at the price of a one-time
> > wiring effort.
>  
> I do the same --I pull cable for televisions, and even for locations
> where a desktop or laptop is going to be sitting on a regular
> basis. So I think we should expect wired and wireless as the norm,
> rather than expecting wireless all the time.
>  
> While I wouldn't want to rule OLSRv2 completely out, I think it should
> compete head to head with an extended OSPF and an extended IS-IS, or
> even other efforts afoot. I'd rather see requirements first, and a
> good solid evaluation of what's available against those requirements,
> rather than choosing technologies out of the gate.
>  
> :-)
>  
> Russ


Russ,

At various jobs I pulled 10base2 coax, then 10base5 coax, then twisted
pair.  [Well someone pulled it, but not me.]  Anyone remember vampire
taps in 10base2?  What a reliability headache!

I pulled 10base5 coax at home before I pulled twisted pair and before
trying the early DEC Wavlan stuff that preceeded WiFi (again, at
home).  Too bad I moved and had to pull wire again (but I like the
result).

Back on topic: I do think we should consider OSPF (not so keen on
ISIS, but OK) and should not rule out OLSRv2 or other LLN related work
and MANET work (though I'm far from an expert on LLN or MANET).

We will have to extend OSPF to make zero config possible.  The
extensions should be completely backwards compatible if at all
possible.

Curtis
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Thoughts about routing - trends

[Jeff Tantsura]

Curtis,

At about same time you were moving/re-wiring your new house, I've started to 
use Ethernet over power and have been using it since then :)

Regards,
Jeff  

-Original Message-
From: homenet-boun...@ietf.org [mailto:homenet-boun...@ietf.org] On Behalf Of 
Curtis Villamizar
Sent: Wednesday, October 12, 2011 19:29
To: Russ White
Cc: homenet@ietf.org
Subject: Re: [homenet] Thoughts about routing - trends


In message <4e957f43.1060...@riw.us>
Russ White writes:
 
>  
> >> You are absolutely right that pulling cable is hard and expensive.
> > Pulling cable is indeed hard and expensive. In my experience, it is
> > the right thing for some applications, such as TV and my home
> > office. Personally, I have both wired and wireless throughout the
> > house; my personal rule is that I use the shared wireless network
> > for activities that move around, to provide convenience at the
> > expense of consistency and bandwidth, and wired for things that
> > stand still, to provide stable bandwidth at the price of a one-time
> > wiring effort.
>  
> I do the same --I pull cable for televisions, and even for locations
> where a desktop or laptop is going to be sitting on a regular
> basis. So I think we should expect wired and wireless as the norm,
> rather than expecting wireless all the time.
>  
> While I wouldn't want to rule OLSRv2 completely out, I think it should
> compete head to head with an extended OSPF and an extended IS-IS, or
> even other efforts afoot. I'd rather see requirements first, and a
> good solid evaluation of what's available against those requirements,
> rather than choosing technologies out of the gate.
>  
> :-)
>  
> Russ


Russ,

At various jobs I pulled 10base2 coax, then 10base5 coax, then twisted
pair.  [Well someone pulled it, but not me.]  Anyone remember vampire
taps in 10base2?  What a reliability headache!

I pulled 10base5 coax at home before I pulled twisted pair and before
trying the early DEC Wavlan stuff that preceeded WiFi (again, at
home).  Too bad I moved and had to pull wire again (but I like the
result).

Back on topic: I do think we should consider OSPF (not so keen on
ISIS, but OK) and should not rule out OLSRv2 or other LLN related work
and MANET work (though I'm far from an expert on LLN or MANET).

We will have to extend OSPF to make zero config possible.  The
extensions should be completely backwards compatible if at all
possible.

Curtis
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Thoughts about routing - trends

[Russ White]

> At various jobs I pulled 10base2 coax, then 10base5 coax, then twisted
> pair.  [Well someone pulled it, but not me.]  Anyone remember vampire
> taps in 10base2?  What a reliability headache!

Pulled from cable hanging in a "plenum" in a secure building... Because
there was no way to get cable floor to floor other than through that
single shaft. For a Xerox Star system. Then there was the token bus for
the little Novell network over in legal --another disaster. 

> Back on topic: I do think we should consider OSPF (not so keen on
> ISIS, but OK) and should not rule out OLSRv2 or other LLN related work
> and MANET work (though I'm far from an expert on LLN or MANET).

IS-IS is easier to get to "zero config," and it's actually simpler in
operation... Which is why I brought it up. :-)

> We will have to extend OSPF to make zero config possible.  The
> extensions should be completely backwards compatible if at all
> possible.

Yes, I agree... Or we need w new wired/wireless protocol that jumps both
worlds, and would actually be acceptable and implemented by a large
number of vendors. But that's another entire problem space...

:-)

Russ
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Thoughts about routing - trends

[Curtis Villamizar]

Off list.

In message <4e96d145.5090...@riw.us>
Russ White writes:
 
>  
> > At various jobs I pulled 10base2 coax, then 10base5 coax, then twisted
> > pair.  [Well someone pulled it, but not me.]  Anyone remember vampire
> > taps in 10base2?  What a reliability headache!
>  
> Pulled from cable hanging in a "plenum" in a secure building... Because
> there was no way to get cable floor to floor other than through that
> single shaft. For a Xerox Star system. Then there was the token bus for
> the little Novell network over in legal --another disaster. 

I managed to avoid token ring and novell.

> > Back on topic: I do think we should consider OSPF (not so keen on
> > ISIS, but OK) and should not rule out OLSRv2 or other LLN related work
> > and MANET work (though I'm far from an expert on LLN or MANET).
>  
> IS-IS is easier to get to "zero config," and it's actually simpler in
> operation... Which is why I brought it up. :-)

I've used both.  Why do you think ISIS is simpler in operation?
Because people love to deal with NSAPs?

> > We will have to extend OSPF to make zero config possible.  The
> > extensions should be completely backwards compatible if at all
> > possible.
>  
> Yes, I agree... Or we need w new wired/wireless protocol that jumps both
> worlds, and would actually be acceptable and implemented by a large
> number of vendors. But that's another entire problem space...

We agree on something.  That's good.  :-)

The clueless vendor problem space is a tough one.

> :-)
>  
> Russ

Curtis
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Thoughts about routing - flash/stable storage constraints

[Jim Gettys]

On 10/11/2011 12:05 AM, Jari Arkko wrote:
> Home routers would also have MAC addresses, but again, if we need a
> 32-bit quantity then shortened 48/64 bit identifiers may
> (theoretically) have collisions.
>
> That being said, if the home routers have to discover their IPv6
> prefix through a protocol and store it in flash, they could probably
> do so also for a router ID. Unless there was some chicken and egg
> problem that required the router ID for all this discovery to work...
As to storing in flash, since most in homenet have not typically worked
on embedded systems, worse luck...

There is typically a read/write file system that can store state on a
current Linux home router (e.g. OpenWrt); it may or may not mapped over
the entire flash (which is desirable, as you'd like wear levelling to
use all blocks on the flash).

The bulk of the firmware is likely contained in a read-only file system
called Squashfs, which does LZW compression on a per file basis;
overlayed on top may be a read/write file system.

Most commonly the read/write file system has been a file system called
jffs2 over bare flash, originally implemented on the Compaq iPAQ
handheld, a project I helped lead after I got sick of HTTP.  And OLPC
had a gigabyte of flash (which pushes jffs2 to/beyond it's design
limits). There are later flash file systems under development, but I
don't have first hand experience with any of them.

Flash has the characteristic that write is relatively slow, and erase is
generally glacial.  Most interesting flash file systems try to do lazy
erasure (erase freed blocks when they have a chance later, rather than
at the time you may free a file).

Since you don't want to wear out the flash, the jffs2 does journaling;
one write will commit (potentially) a bunch of changes to multiple
files, rather than each write generating one write.

How many writes you get depends on the flash technology, whether the
flash is "bare" or has some "smart" controller, and the wear levelling
technology (if any) in use, along with whether all blocks participate in
the wear levelling or not (jffs2 does good wear levelling; but using a
big squashfs file system + a very small jffs2 file system will reduce
the effectiveness; some cheap USB storage devices only do wear levelling
on the free blocks, and try to hide the fact it is flash from the system
above.  I put "smart" in quotes, because they've often been hideously
stupid, with their smarts limited to looking like IDE with a very lame
flash translation layer.  The most recent "smart" flash disks for
laptops are actually getting very smart, with some help from the OS to
help with the erasure problem.  But they still cost substantially more,
I suspect.

I think most home routers currently use bare flash, though it's not
clear to me if this will continue or not since the volume market may
make the economics change.

In any case, with flash of any sort, you don't want to sit there and
demand to do lots of periodic writes (on Linux/UNIX you'd mount -atime,
for example). 

All this being said, storing state at the rate of machines/routers
appearing or disappearing on a home network, or your ISP going down,
isn't likely to cause a problem.  You just have to be careful enough to
not do anything really stupid; e.g. you map daemons with chatty logs to
run their logs to /dev/null, or to tempfs in RAM. And you might take a
big latency hit if you have to guarantee the write is stable before
continuing an algorithm (if you run into needing to erase a block for
some reason).  And obviously you don't write tons of data when you don't
half to. And update in place may be a bad idea relative to other
techniques (which is why journaling file systems such as jffs2 are so
desirable).

- Jim
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Thoughts about routing - flash/stable storage constraints

[Curtis Villamizar]

In message <4e95c231.5030...@freedesktop.org>
Jim Gettys writes:
 
> On 10/11/2011 12:05 AM, Jari Arkko wrote:
> > Home routers would also have MAC addresses, but again, if we need a
> > 32-bit quantity then shortened 48/64 bit identifiers may
> > (theoretically) have collisions.
> >
> > That being said, if the home routers have to discover their IPv6
> > prefix through a protocol and store it in flash, they could probably
> > do so also for a router ID. Unless there was some chicken and egg
> > problem that required the router ID for all this discovery to work...
> As to storing in flash, since most in homenet have not typically worked
> on embedded systems, worse luck...
>  
> There is typically a read/write file system that can store state on a
> current Linux home router (e.g. OpenWrt); it may or may not mapped over
> the entire flash (which is desirable, as you'd like wear levelling to
> use all blocks on the flash).
>  
> The bulk of the firmware is likely contained in a read-only file system
> called Squashfs, which does LZW compression on a per file basis;
> overlayed on top may be a read/write file system.
>  
> Most commonly the read/write file system has been a file system called
> jffs2 over bare flash, originally implemented on the Compaq iPAQ
> handheld, a project I helped lead after I got sick of HTTP.  And OLPC
> had a gigabyte of flash (which pushes jffs2 to/beyond it's design
> limits). There are later flash file systems under development, but I
> don't have first hand experience with any of them.
>  
> Flash has the characteristic that write is relatively slow, and erase is
> generally glacial.  Most interesting flash file systems try to do lazy
> erasure (erase freed blocks when they have a chance later, rather than
> at the time you may free a file).
>  
> Since you don't want to wear out the flash, the jffs2 does journaling;
> one write will commit (potentially) a bunch of changes to multiple
> files, rather than each write generating one write.
>  
> How many writes you get depends on the flash technology, whether the
> flash is "bare" or has some "smart" controller, and the wear levelling
> technology (if any) in use, along with whether all blocks participate in
> the wear levelling or not (jffs2 does good wear levelling; but using a
> big squashfs file system + a very small jffs2 file system will reduce
> the effectiveness; some cheap USB storage devices only do wear levelling
> on the free blocks, and try to hide the fact it is flash from the system
> above.  I put "smart" in quotes, because they've often been hideously
> stupid, with their smarts limited to looking like IDE with a very lame
> flash translation layer.  The most recent "smart" flash disks for
> laptops are actually getting very smart, with some help from the OS to
> help with the erasure problem.  But they still cost substantially more,
> I suspect.
>  
> I think most home routers currently use bare flash, though it's not
> clear to me if this will continue or not since the volume market may
> make the economics change.
>  
> In any case, with flash of any sort, you don't want to sit there and
> demand to do lots of periodic writes (on Linux/UNIX you'd mount -atime,
> for example). 
>  
> All this being said, storing state at the rate of machines/routers
> appearing or disappearing on a home network, or your ISP going down,
> isn't likely to cause a problem.  You just have to be careful enough to
> not do anything really stupid; e.g. you map daemons with chatty logs to
> run their logs to /dev/null, or to tempfs in RAM. And you might take a
> big latency hit if you have to guarantee the write is stable before
> continuing an algorithm (if you run into needing to erase a block for
> some reason).  And obviously you don't write tons of data when you don't
> half to. And update in place may be a bad idea relative to other
> techniques (which is why journaling file systems such as jffs2 are so
> desirable).
>  
> - Jim


Jim,

Nice reminder on the limitations of flash and some of the workarounds.
Some neat hardware does erase on write and buffers the write itself,
and can store enough energy in a small battery to flush the writes on
power down.  Its faster and maximized flash life.  Its essentially a
RAM front ended flash.  I think it was expensive for consumer use.
For provider equipement it makes logging to flash feasible thereby
avoiding spinning media which may object to a 65 C ambient.

Routing protocols are even less stateful than DHCP in this regard.
There is no "lease" to be preserved between boots.  The configuration
(today in non-zero-config situations) is not sufficiently immuatable
to put in a squashfs but may not be changed for months or years.  Any
old filesystem over bare flash is OK for that.

Everthing else in a routing protocol is acquired at run time and
therefore should be in RAM (ramfs or in application space RAM).

With a zero config routing protocol at worst there would be a