Well, being a residential CPE vendor, I can confirm some of our customers
deploy /64 only to the CPE.
Not recommended by us, but being a managed CPE, it's the customer making the
final decision on this.
Regs
Carl
-Original Message-
From: homenet-boun...@ietf.org [mailto:homenet-boun.
Well, I've not followed all of the homenet discussions on this PD-story, but I
see a lot of referral to OSPF (v3), so it seems to be assumed that all these
CPEs must "talk" OSPF ?
I think lots of them in the field today are low-end, low memory devices, hence
probably 1. no OSPF will be present a
On Thu, 8 Nov 2012, Wuyts Carl wrote:
Well, being a residential CPE vendor, I can confirm some of our
customers deploy /64 only to the CPE. Not recommended by us, but being a
managed CPE, it's the customer making the final decision on this.
If they only give the end user a /64, then the end c
On Thu, 8 Nov 2012, Wuyts Carl wrote:
I think lots of them in the field today are low-end, low memory devices,
hence probably 1. no OSPF will be present and 2. Calculating SP might
put quite some pressure on its capabilities, no ?
We're talking tens or at max, hundreds of routes (/56 means 25
On 08/11/2012 09:48, Mikael Abrahamsson wrote:
> On Thu, 8 Nov 2012, Wuyts Carl wrote:
>
>> Well, being a residential CPE vendor, I can confirm some of our
>> customers deploy /64 only to the CPE. Not recommended by us, but being
>> a managed CPE, it's the customer making the final decision on thi
Well, indeed things have been running for a long time, even in the 90's, but
(for some reason) in today's world, the CPE should be as low cost as possible,
resulting in cheaper chipsets and restricted memory. On top of the 90's
content, they also now have to include lots of extra's like samba s
Op 8 nov. 2012, om 10:50 heeft Mikael Abrahamsson het volgende geschreven:
> On Thu, 8 Nov 2012, Wuyts Carl wrote:
>
>> I think lots of them in the field today are low-end, low memory devices,
>> hence probably 1. no OSPF will be present and 2. Calculating SP might put
>> quite some pressure o
Well, define "current".
The ones deployed today and last year or so probably will not have a problem
getting upgraded, and as we're managed CPE, this is well under control. But
there is a massive number of CPE devices in the field today which are indeed
not upgradable to an IP-capable firmware
On Nov 8, 2012, at 6:41 AM, Brian E Carpenter
wrote:
> Fine, but when such an end customer buys a second router and plugs it in,
> will she get an error message that says "Please find a new ISP"?
In this case I think our only option is to fall back to bridging.
_
On Nov 7, 2012, at 10:24 PM, Teco Boot wrote:
> And I suggest that if D requests a prefix, for an additional interface, it
> uses unicast to A, with an autoconfigured address. So A receives only one
> request.
No, it doesn't, because that's not what RFC3315 and RFC3633 say to do, and it
would
On 08/11/2012 12:05, Ted Lemon wrote:
> On Nov 8, 2012, at 6:41 AM, Brian E Carpenter
> wrote:
>> Fine, but when such an end customer buys a second router and plugs it in,
>> will she get an error message that says "Please find a new ISP"?
>
> In this case I think our only option is to fall back
On Thu, 8 Nov 2012, Teco Boot wrote:
I hope I misunderstand. If current CPE router and WiFi AP cannot be
upgraded to what we are talking about, we are on a dead end.
I have zero illusion that any devices that have been purchased with
minimum requirements for IPv4 only, giving the deal to whoe
On Thu, 8 Nov 2012, Ted Lemon wrote:
On Nov 8, 2012, at 6:41 AM, Brian E Carpenter
wrote:
Fine, but when such an end customer buys a second router and plugs it in,
will she get an error message that says "Please find a new ISP"?
In this case I think our only option is to fall back to bridgi
On Nov 8, 2012, at 7:25 AM, Brian E Carpenter
wrote:
> Without some fundamental surgery on the IPv6 specs, I fear that is true,
> so does it have to become (gulp) a feature of the homenet architecture?
I think it does, or the architecture becomes irrelevant because no-one will be
brave enough t
On Thu, Nov 8, 2012 at 1:32 PM, Mikael Abrahamsson wrote:
> On Thu, 8 Nov 2012, Ted Lemon wrote:
>
>> On Nov 8, 2012, at 6:41 AM, Brian E Carpenter
>> wrote:
>>>
>>> Fine, but when such an end customer buys a second router and plugs it in,
>>> will she get an error message that says "Please find
On Nov 7, 2012, at 11:18 PM, Teco Boot wrote:
> I checked the draft-ietf-ospf-ospfv3-autoconfig-00. I think the proposal
> doesn't meet expectations of users, with regard of protocol convergence. The
> default timers are far too conservative. First reconfig on OSPF router in my
> hands is adju
Well of course not. Do you think they will be bothered by the fact that a
second router (from another ISP) is not working properly ? Please note, I'm
talking about managed CPE, not retail, that's another model.
I do understand what you mean, but it is not that simple. It is also very
differe
Op 8 nov. 2012, om 13:06 heeft Ted Lemon het volgende geschreven:
> On Nov 7, 2012, at 10:24 PM, Teco Boot wrote:
>> And I suggest that if D requests a prefix, for an additional interface, it
>> uses unicast to A, with an autoconfigured address. So A receives only one
>> request.
>
> No, it d
I don't think bridging should be considered for homenet. Don't forget
the following in the charter:
"Also, link layer networking technology is poised to become more
heterogeneous, as networks begin to employ both traditional Ethernet
technology and link layers designed for low-powered sensor n
On Thu, 8 Nov 2012, Robert Cragie wrote:
In a lot of these conversations, the "lightswitch guys" (as someone
called the LLN proponents) seem to get forgotten.
So let's just say that giving a single /64 to the home is incompatible
with homenet architecture, and we need more addresses. I'm fine
On 08/11/2012 12:25 PM, Brian E Carpenter wrote:
On 08/11/2012 12:05, Ted Lemon wrote:
On Nov 8, 2012, at 6:41 AM, Brian E Carpenter
wrote:
Fine, but when such an end customer buys a second router and plugs
it in,
will she get an error message that says "Please find a new ISP"?
In this cas
Op 8 nov. 2012, om 13:31 heeft Mikael Abrahamsson het volgende geschreven:
> On Thu, 8 Nov 2012, Teco Boot wrote:
>
>> I hope I misunderstand. If current CPE router and WiFi AP cannot be upgraded
>> to what we are talking about, we are on a dead end.
>
> I have zero illusion that any devices t
On 08/11/2012 13:45, Mattia Rossi wrote:
>
>> On 08/11/2012 12:25 PM, Brian E Carpenter wrote:
>>> On 08/11/2012 12:05, Ted Lemon wrote:
On Nov 8, 2012, at 6:41 AM, Brian E Carpenter
wrote:
> Fine, but when such an end customer buys a second router and plugs
> it in,
> will
On 08/11/2012 13:41, Mikael Abrahamsson wrote:
> On Thu, 8 Nov 2012, Robert Cragie wrote:
>
>> In a lot of these conversations, the "lightswitch guys" (as someone
>> called the LLN proponents) seem to get forgotten.
>
> So let's just say that giving a single /64 to the home is incompatible
> with
Op 8 nov. 2012, om 14:03 heeft Acee Lindem het volgende geschreven:
>
> On Nov 7, 2012, at 11:18 PM, Teco Boot wrote:
>
>> I checked the draft-ietf-ospf-ospfv3-autoconfig-00. I think the proposal
>> doesn't meet expectations of users, with regard of protocol convergence. The
>> default timers
Comment inline.
Robert
On 08/11/2012 12:25 PM, Brian E Carpenter wrote:
On 08/11/2012 12:05, Ted Lemon wrote:
On Nov 8, 2012, at 6:41 AM, Brian E Carpenter
wrote:
Fine, but when such an end customer buys a second router and plugs it in,
will she get an error message that says "Please find a
Dave,
On 08/11/2012 12:57, Dave Taht wrote:
> On Thu, Nov 8, 2012 at 1:32 PM, Mikael Abrahamsson wrote:
>> On Thu, 8 Nov 2012, Ted Lemon wrote:
>>
>>> On Nov 8, 2012, at 6:41 AM, Brian E Carpenter
>>> wrote:
Fine, but when such an end customer buys a second router and plugs it in,
will
On Thu, Nov 8, 2012 at 3:30 PM, Brian E Carpenter
wrote:
> Dave,
>
> On 08/11/2012 12:57, Dave Taht wrote:
>> On Thu, Nov 8, 2012 at 1:32 PM, Mikael Abrahamsson wrote:
>>> On Thu, 8 Nov 2012, Ted Lemon wrote:
>>>
On Nov 8, 2012, at 6:41 AM, Brian E Carpenter
wrote:
> Fine, but when
>
>I think we should aim higher do what's best in the long run, and then CPE
>manufacturers will adapt. Yes, these new CPEs might be USD5-10 more than
>current generation, initially, but as these requirements spread and more
>people/ISPs buy, it'll be the new lowest standard and cost will drop.
HI,
> So let's just say that giving a single /64 to the home is incompatible with
> homenet architecture, and we need more addresses. I'm fine with that.
Yes please. I think some ISPs *need* to get a signal like this.
Sander
___
homenet mailing list
h
On Thu, 8 Nov 2012, Howard, Lee wrote:
I think we should aim higher do what's best in the long run, and then
CPE manufacturers will adapt. Yes, these new CPEs might be USD5-10 more
than current generation, initially, but as these requirements spread
and more people/ISPs buy, it'll be the new l
>> even though this would destroy the benefits of subnetting.
>I think it is arguable whether bridging is the least damaging
>solution. It fundamentally does not work with route-over multi-link
>subnets and would therefore require some extra L2 weirdness at a LLN
>border router. If ISPs are goin
What would happen today if a /64 showed up? Why change that behavior?
On 11/8/12 10:09 AM, "Victor Kuarsingh" wrote:
>
>>> even though this would destroy the benefits of subnetting.
>>I think it is arguable whether bridging is the least damaging
>>solution. It fundamentally does not work with
Also consider a dual-homed homenet where one ISP gives a /64 and the
other gives a /56. I guess that has to revert to bridging mode too.
I was going to suggest a solution, where the router within the homenet
simply asks for a DHCP-PD, and if it gets one it keeps routing,
otherwise it
On 11/8/12 10:07 AM, "Mikael Abrahamsson" wrote:
>On Thu, 8 Nov 2012, Howard, Lee wrote:
>
>>> I think we should aim higher do what's best in the long run, and then
>>> CPE manufacturers will adapt. Yes, these new CPEs might be USD5-10
>>>more
>>> than current generation, initially, but as thes
On 08/11/2012 15:09, Victor Kuarsingh wrote:
>>> even though this would destroy the benefits of subnetting.
>> I think it is arguable whether bridging is the least damaging
>> solution. It fundamentally does not work with route-over multi-link
>> subnets and would therefore require some extra L2
I noticed it had been reduced from minutes to 30 seconds in this version. I
guess that rules out RIPng. Since this is a new specification we'll take lower
hello/dead under advisement. However, I doubt we go as low as 1 and 4.
Acee
On Nov 8, 2012, at 9:24 AM, Teco Boot wrote:
>
> Op 8 nov. 20
I don't think bridging should be considered for homenet. Don't forget
the following in the charter:
"Also, link layer networking technology is poised to become more
heterogeneous, as networks begin to employ both traditional Ethernet
technology and link layers designed for low-powered sensor netw
Op 8 nov. 2012, om 16:56 heeft Acee Lindem het volgende geschreven:
> I noticed it had been reduced from minutes to 30 seconds in this version. I
> guess that rules out RIPng. Since this is a new specification we'll take
> lower hello/dead under advisement. However, I doubt we go as low as 1 a
On 8/11/2012, at 11:17 AM, Teco Boot wrote:
>
> Op 8 nov. 2012, om 16:56 heeft Acee Lindem het volgende geschreven:
>
>> I noticed it had been reduced from minutes to 30 seconds in this version. I
>> guess that rules out RIPng. Since this is a new specification we'll take
>> lower hello/dea
Op 8 nov. 2012, om 17:28 heeft Andrew McGregor het volgende geschreven:
>
> On 8/11/2012, at 11:17 AM, Teco Boot wrote:
>
>>
>> Op 8 nov. 2012, om 16:56 heeft Acee Lindem het volgende geschreven:
>>
>>> I noticed it had been reduced from minutes to 30 seconds in this version. I
>>> guess th
Mat,
That looks good to me, I hope the architecture authors will pick it up.
Brian
On 08/11/2012 16:15, Mattia Rossi wrote:
I don't think bridging should be considered for homenet. Don't forget
the following in the charter:
"Also, link layer networking technology is poise
On Thu, 8 Nov 2012, Howard, Lee wrote:
I've made this point to the WG several times. Complexity leads to
unpredictability.
Could you please point me to where you have done this. I went back a year
and read posts by you, and couldn't really find any such point (not a
clear one anyway).
Is
An ISP that gives out a single /64 is broken. As long as we have a way
to indicate "out of /64s" (because that could happen, even if you are
given a /48, and have some pathology...), then we are good.
A home may have multiple ISPs, and people are gonna notice that some of
them work better than
> "Brian" == Brian E Carpenter writes:
Brian> Also consider a dual-homed homenet where one ISP gives a /64
Brian> and the other gives a /56. I guess that has to revert to
Brian> bridging mode too.
no. Let's let the /56 work well, and let the /64-ISP break.
--
Michael Richardso
> "Mattia" == Mattia Rossi writes:
>> In a lot of these conversations, the "lightswitch guys" (as
>> someone called the LLN proponents) seem to get forgotten.
Mattia> So what happens if the "lightswitch guys" want to plug-in a
Mattia> router, which they have to, as they can't
> "Mattia" == Mattia Rossi writes:
Mattia> might become:
Mattia> The home network needs to be adaptable to such ISP
Mattia> policies, and thus make no assumptions about the stability
Mattia> of the prefix received from an ISP, or the length of the
Mattia> prefix that ma
Op 8 nov. 2012, om 14:03 heeft Acee Lindem het volgende geschreven:
>
> I'd expect homenet ethernet and WiFi interfaces to default to the broadcast
> type.
Then, we cannot have costs per neighbor, correct?
By experience I've became aware this is a bad idea on wireless networks, like
WiFi.
Wha
> "Leddy," == Leddy, John writes:
Leddy> What would happen today if a /64 showed up? Why change that
Leddy> behavior?
An RFC6204 router with a single LAN interface is perfectly happy getting
a /64.
An RFC6204 router with more than one LAN interface that doesn't get
enough address s
> "Brian" == Brian E Carpenter writes:
>> Yes please. I think some ISPs *need* to get a signal like this.
Brian> Sure, but that does *not* excuse us from specifying how the
Brian> end user gets service in such a situation.
so, lets' say you come home with a new fancy router... a
You'd have to do this through manual configuration.
Thanks,
Acee
On Nov 8, 2012, at 2:08 PM, Teco Boot wrote:
>
> Op 8 nov. 2012, om 14:03 heeft Acee Lindem het volgende geschreven:
>>
>> I'd expect homenet ethernet and WiFi interfaces to default to the broadcast
>> type.
>
> Then, we cannot
On Nov 8, 2012, at 2:11 PM, Michael Richardson wrote:
> interfaces, the IPv6 CE router SHOULD log a system management
> error.
>
> it doesn't tell us to start bridging.
Sure, but "log a system management error" is not something that a home router
vendor can meaningfully impl
On Nov 8, 2012, at 8:20 AM, Teco Boot wrote:
> Once the client has determined the address of a server, it may under
> some circumstances send messages directly to the server using
> unicast.
The document then goes on to describe under what circumstances the client may
unicast, and they do not in
On 8 Nov 2012, at 14:28, Ted Lemon wrote:
>
> Sure, but "log a system management error" is not something that a home router
> vendor can meaningfully implement, unless it puts a speaker in the home
> router and has it start bellowing "out of addresses" in every known language.
>
> But the rea
On Nov 8, 2012, at 2:40 PM, Ray Bellis wrote:
> I note that the Apple Airport Utility pops up warnings about various errors,
> some of which relate to sub-optimal network configuration, rather than
> misconfiguration. In particular, they warn you if you try to use double NAT.
This is very cool
On Fri, Nov 9, 2012 at 3:40 AM, Ray Bellis wrote:
>
> On 8 Nov 2012, at 14:28, Ted Lemon wrote:
>>
>> Sure, but "log a system management error" is not something that a home
>> router vendor can meaningfully implement, unless it puts a speaker in the
>> home router and has it start bellowing "ou
This whole thread is making me think that specifying that we use either babel
(with attention to getting it documented properly) or one of the OSPFv4 MANET
extensions, in the case where we have only a /64 and perhaps any time we find
we have an 802.11s, ad-hoc or NBMA interface in play. That wa
Just to be clear - using a /64 will not necessarily break a home network
with a LLN. It's just that some kludge will be needed and the least
preferable IMHO for LLNs is bridging.
So I would suggest something like:
"The home network needs to be adaptable to such ISP policies, and thus
make no
Can this be generalized for anytime a prefix offered is not large enough
to cover the number of interfaces?
On 11/8/12 3:40 PM, "Robert Cragie" wrote:
>Just to be clear - using a /64 will not necessarily break a home network
>with a LLN. It's just that some kludge will be needed and the least
Independent of the routing protocol, I don't think we want to inject a /128
advertisement for every device in the homenet into the homenet routing domain.
Acee
On Nov 8, 2012, at 3:21 PM, Andrew McGregor wrote:
> This whole thread is making me think that specifying that we use either babel
> (w
Oops, meant to reply to the list the first time...
I see no reason not to do this... we'd have to have just about as much
information to bridge successfully, and a few hundred routes is no big deal.
Andrew
On 8/11/2012, at 3:49 PM, Acee Lindem wrote:
> Independent of the routing protocol, I d
On Nov 8, 2012, at 4:40 PM, Andrew McGregor wrote:
> I see no reason not to do this... we'd have to have just about as much
> information to bridge successfully, and a few hundred routes is no big deal.
+1
I realize that I've been arguing for a different solution, but I agree that
this is bett
On Nov 8, 2012, at 4:44 PM, Ted Lemon wrote:
> On Nov 8, 2012, at 4:40 PM, Andrew McGregor wrote:
>> I see no reason not to do this... we'd have to have just about as much
>> information to bridge successfully, and a few hundred routes is no big deal.
Is a few hundred enough to meet the presen
On 08/11/12 21:44, Ted Lemon wrote:
On Nov 8, 2012, at 4:40 PM, Andrew McGregor wrote:
I see no reason not to do this... we'd have to have just about as much
information to bridge successfully, and a few hundred routes is no big deal.
+1
I realize that I've been arguing for a different solu
64 matches
Mail list logo
