Le 05/02/2014 15:01, Ole Troan a écrit :
Ted,
please take a look at those drafts, and let us know what we've
missed in the DHCP PD "solution space".
I've read all those drafts at one time or another. I just
checked the latest version of
http://tools.ietf.org/html/draft-gmann-homenet-relay-a
Op 5 feb. 2014, om 15:33 heeft Ole Troan het volgende
geschreven:
>>
>> Right, I'm not arguing that we don't need a routing protocol. I'm not even
>> particularly arguing that PD is the right way to delegate prefixes. But it
>> would work, and with no protocol changes—it would just requi
Ted,
>> you make it sound like that's a part and parcel of DHCP. I can't see how you
>> can implement that today.
>
> Eh? It's dead trivial. The draft already sets up relay agents—the only
> difference is that all relays now relay to both CERs, not just one. The
> requesting routers get
On Feb 5, 2014, at 9:01 AM, Ole Troan wrote:
> you make it sound like that's a part and parcel of DHCP. I can't see how you
> can implement that today.
Eh? It's dead trivial. The draft already sets up relay agents—the only
difference is that all relays now relay to both CERs, not just one.
Ted,
>> please take a look at those drafts, and let us know what we've missed in the
>> DHCP PD "solution space".
>
> I've read all those drafts at one time or another. I just checked the
> latest version of
> http://tools.ietf.org/html/draft-gmann-homenet-relay-autoconf and it appears
> to
On Feb 5, 2014, at 3:04 AM, Ole Troan wrote:
> please take a look at those drafts, and let us know what we've missed in the
> DHCP PD "solution space".
I've read all those drafts at one time or another. I just checked the latest
version of http://tools.ietf.org/html/draft-gmann-homenet-relay-
Le 05/02/2014 09:06, Mikael Abrahamsson a écrit :
On Wed, 5 Feb 2014, Brian E Carpenter wrote:
On 05/02/2014 12:13, Michael Richardson wrote:
Pierre Pfister wrote:
...
For instance, if a prefix is for general purpose, and another is for
voice
applications, then hosts may only get addresses
Le 05/02/2014 09:04, Ole Troan a écrit :
Ted,
actually, we're talking about prefix assignment. which may be
splitting hairs, but isn't quite the same as prefix delegation.
Splain? You mean we're talking about the general problem, rather
than the DHCP-PD solution? If so, that's fine, but t
On Wed, 5 Feb 2014, Brian E Carpenter wrote:
On 05/02/2014 12:13, Michael Richardson wrote:
Pierre Pfister wrote:
...
For instance, if a prefix is for general purpose, and another is for voice
applications, then hosts may only get addresses for voice application, and
would therefore not bein
Ted,
>> actually, we're talking about prefix assignment. which may be splitting
>> hairs, but isn't quite the same as prefix delegation.
>
> Splain? You mean we're talking about the general problem, rather than the
> DHCP-PD solution? If so, that's fine, but the specific comment that Markus
Ted,
>> I thought you were asking for host changes to support multiple servers (even
>> if RFC says they should, and I’m not sure it does, I have yet to find one
>> that does).
>
> I think host changes to make this work will be crucial to having hosts that
> can operate on multiple prefixes ma
On 05/02/2014 12:13, Michael Richardson wrote:
> Pierre Pfister wrote:
...
>> For instance, if a prefix is for general purpose, and another is for voice
>> applications, then hosts may only get addresses for voice application, and
>> would therefore not being able to access the internet.
Yes, t
Pierre Pfister wrote:
>> To quote from the charter:
>>
>> Prefix configuration, routing, and security related work shall not
>> cause any changes that are not backwards compatible to existing IPv6
>> hosts. There may be host visible changes in the work on naming and
>> di
On Feb 4, 2014, at 12:10 PM, Markus Stenberg wrote:
> I thought you were asking for host changes to support multiple servers (even
> if RFC says they should, and I’m not sure it does, I have yet to find one
> that does).
I think host changes to make this work will be crucial to having hosts tha
On 4.2.2014, at 15.46, Ted Lemon wrote:
> On Feb 4, 2014, at 6:40 AM, Markus Stenberg wrote:
>> Given N*10^8+ (conservative estimate, N some single digit probably)
>> potential homenet hosts already out there and 0 homenet routers, designing
>> with the assumption that ‘yeah, hosts can change’
Op 3 feb. 2014, om 15:11 heeft Ray Bellis het
volgende geschreven:
>
> On 3 Feb 2014, at 12:51, Alexandru Petrescu
> wrote:
>
>> In this setting the Router3 could run two DHCPRelay processes, and Router1
>> and 2 would be Servers.
>>
>> This would allow Host to obtain an address from each
To quote from the charter:
Prefix configuration, routing, and security
related work shall not cause any changes that are not backwards
compatible to existing IPv6 hosts. There may be host visible changes
in the work on naming and discovery protocols, however.
"backwards compatible" d
On Feb 4, 2014, at 9:09 AM, Ole Troan wrote:
> actually, we're talking about prefix assignment. which may be splitting
> hairs, but isn't quite the same as prefix delegation.
Splain? You mean we're talking about the general problem, rather than the
DHCP-PD solution? If so, that's fine, but
>> Given N*10^8+ (conservative estimate, N some single digit probably)
>> potential homenet hosts already out there and 0 homenet routers, designing
>> with the assumption that ‘yeah, hosts can change’ doesn’t sound too
>> reasonable to me.
>>
>> Then again, what’s wrong with fighting windmills
On Feb 4, 2014, at 6:40 AM, Markus Stenberg wrote:
> Given N*10^8+ (conservative estimate, N some single digit probably) potential
> homenet hosts already out there and 0 homenet routers, designing with the
> assumption that ‘yeah, hosts can change’ doesn’t sound too reasonable to me.
>
> Then
On 3.2.2014, at 21.51, Ted Lemon wrote:
> On Feb 3, 2014, at 2:06 PM, Lorenzo Colitti wrote:
>> Perhaps, but if implementations don't actually do this (and I don't think
>> they do), then it doesn't really matter what the intent was.
> There are no homenet router implementations.
Given N*10^8+
On Feb 3, 2014, at 2:06 PM, Lorenzo Colitti wrote:
> Perhaps, but if implementations don't actually do this (and I don't think
> they do), then it doesn't really matter what the intent was.
There are no homenet router implementations.
___
homenet mail
On Feb 3, 2014, at 9:39 AM, Pierre Pfister wrote:
> I’m not sure DHCP Relaying was intended to work with different DHCP servers.
> In any case, DHCP client was not.
This is not actually true. RFC 3315 was written with the clear anticipation
of the possibility that a DHCP client might talk to
Le 3 févr. 2014 à 07:11, Ray Bellis a écrit :
>
> On 3 Feb 2014, at 12:51, Alexandru Petrescu
> wrote:
>
>> In this setting the Router3 could run two DHCPRelay processes, and Router1
>> and 2 would be Servers.
>>
>> This would allow Host to obtain an address from each (==multi-homed).
I’m
Le 03/02/2014 15:11, Ray Bellis a écrit :
On 3 Feb 2014, at 12:51, Alexandru Petrescu
wrote:
In this setting the Router3 could run two DHCPRelay processes, and
Router1 and 2 would be Servers.
This would allow Host to obtain an address from each
(==multi-homed).
It could, but assume that Ro
On 3 Feb 2014, at 12:51, Alexandru Petrescu
wrote:
> In this setting the Router3 could run two DHCPRelay processes, and Router1
> and 2 would be Servers.
>
> This would allow Host to obtain an address from each (==multi-homed).
It could, but assume that Router3 doesn't yet know anything abou
Le 30/01/2014 14:03, Ole Troan a écrit :
Alex,
changing the thread since this seems to diverge from getting answers to the
questions I asked.
cheers,
Ole
On 30 Jan 2014, at 13:55 , Alexandru Petrescu
wrote:
Pierre,
Thanks for the reply.
Le 30/01/2014 13:46, Pierre Pfister a écrit :
L
Alex,
changing the thread since this seems to diverge from getting answers to the
questions I asked.
cheers,
Ole
On 30 Jan 2014, at 13:55 , Alexandru Petrescu
wrote:
> Pierre,
>
> Thanks for the reply.
>
> Le 30/01/2014 13:46, Pierre Pfister a écrit :
>>
>> Le 30 janv. 2014 à 13:38, Alex
Ted
Thank you for reply.
I found it.
http://trac.tools.ietf.org/wg/homenet/trac/raw-attachment/wiki/WikiStart/homenet-prefixassignment.pdf
Hierarchical DHCP Prefix Delegation
RFC3633 + draft-chakrabarti-homenet-prefix-alloc-00
http://tools.ietf.org/html/draft-chakrabarti-homenet-prefix-alloc-00
Re
On Mar 4, 2013, at 1:27 AM, Shishio Tsuchiya wrote:
> Should we make the draft or presentation which explains this feature as
> informational?
> or is this well known feature?
This is a well-known feature. There's been some debate as to whether this is
the right way to solve the problem for
How does this PD function compare with draft-baker-homenet-prefix-assignment ?
It would be interesting to know the details and experience with the running
code.
- Ralph
On Mar 4, 2013, at 1:27 AM, Shishio Tsuchiya wrote:
> I found NTT/KDDI home gateway has this function.
> IPv6 customer Ed
I found NTT/KDDI home gateway has this function.
IPv6 customer Edge router act as DHCP-pd requesting router.
And if it recieved dhcp-pd prefix , it also act as delegating router for IPv6
interia router.
The pool would be configured from delegated prefix automatically.
Should we make the draft or
On 11/08/2012 07: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 these requirements
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 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
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 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
>
>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.
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
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
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 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
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
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
ge due to
homenet architecture, but not sure it will.
Regs
Carl
-Original Message-
From: homenet-boun...@ietf.org [mailto:homenet-boun...@ietf.org] On Behalf Of
Mikael Abrahamsson
Sent: donderdag 8 november 2012 10:51
To: Wuyts Carl
Cc: Simon Kelley; homenet@ietf.org; Ted Lemon; David
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
f Of
Ted Lemon
Sent: woensdag 7 november 2012 20:08
To: David Lamparter
Cc: Simon Kelley; homenet@ietf.org
Subject: Re: [homenet] DHCP PD for homenets.
On Nov 7, 2012, at 8:00 PM, David Lamparter wrote:
> As I've said in my other mail, you end up going back to some election
> mech
Op 8 nov. 2012, om 03:03 heeft Ted Lemon het volgende geschreven:
> On Nov 7, 2012, at 5:33 PM, "Ole Troan (otroan)" wrote:
>> Disagree. Hierarchical or flat PD (with relays) don't work for multihomed
>> sites, have problems with arbitrary topplogies etc.
>
> You said this before, but you did
On Nov 7, 2012, at 5:33 PM, "Ole Troan (otroan)" wrote:
> Disagree. Hierarchical or flat PD (with relays) don't work for multihomed
> sites, have problems with arbitrary topplogies etc.
You said this before, but you didn't describe any arbitrary topology in which
PD wouldn't work. Could you
On 7 Nov 2012, at 14:50, "Teco Boot" wrote:
> This should be in the homenet-arch, I think.
>
> It sounds so obvious to me, that I described this in a short text in BRDP:
> A Router should request a prefix for attached subnetworks, with
> DHCP-PD [RFC3633], where there is at that moment no
Op 7 nov. 2012, om 23:33 heeft Ole Troan (otroan) het volgende geschreven:
>
>
> On 7 Nov 2012, at 14:50, "Teco Boot" wrote:
>
>> This should be in the homenet-arch, I think.
>>
>> It sounds so obvious to me, that I described this in a short text in BRDP:
>> A Router should request a prefix
Op 7 nov. 2012, om 19:29 heeft Simon Kelley het volgende geschreven:
> On 07/11/12 18:21, David Lamparter wrote:
>> On Wed, Nov 07, 2012 at 06:03:52PM +, Simon Kelley wrote:
>>> On 07/11/12 15:46, Ted Lemon wrote:
>>>
I think the disconnect here is that people are thinking the routers
>
Op 7 nov. 2012, om 16:59 heeft Ole Trøan het volgende geschreven:
> Ted,
>
> this has been proposed a few times. the problems that I see with it are:
> - in an arbitrary topology how do you decide which interfaces you are a
> client on and which interfaces you relay on
> - how do you handle the
This should be in the homenet-arch, I think.
It sounds so obvious to me, that I described this in a short text in BRDP:
A Router should request a prefix for attached subnetworks, with
DHCP-PD [RFC3633], where there is at that moment no on-link prefix
for a selected Border Router.
I could
On Nov 7, 2012, at 8:00 PM, David Lamparter wrote:
> As I've said in my other mail, you end up going back to some election
> mechanism, and from there it's easier to just stick with OSPFv3 (and
> apply the nicer solutions provided by that across all areas) instead of
> creating a new protocol.
Ju
On Wed, Nov 07, 2012 at 07:54:09PM +0100, Ted Lemon wrote:
> On Nov 7, 2012, at 7:21 PM, David Lamparter wrote:=
> > This really falls apart when I'm using 2 ISPs with 2 exit routers.
> > a-k-a, "Where's up?
>
> Why does it fail? The system I described will wind up relaying to both
> delegatin
On Nov 7, 2012, at 7:21 PM, David Lamparter wrote:=
> This really falls apart when I'm using 2 ISPs with 2 exit routers.
> a-k-a, "Where's up?
Why does it fail? The system I described will wind up relaying to both
delegating routers.
___
homenet mai
On Wed, Nov 07, 2012 at 06:29:54PM +, Simon Kelley wrote:
> On 07/11/12 18:21, David Lamparter wrote:
> > On Wed, Nov 07, 2012 at 06:03:52PM +, Simon Kelley wrote:
> >> On 07/11/12 15:46, Ted Lemon wrote:
> >>
> >>> I think the disconnect here is that people are thinking the routers
> >>> t
On Wed, 7 Nov 2012, David Lamparter wrote:
This really falls apart when I'm using 2 ISPs with 2 exit routers.
a-k-a, "Where's up?"
I believe source based routing is needed somewhere.
Either it's done between the ISP routers and that's it, or we expand the
standards so all routers in the home
On 07/11/12 18:21, David Lamparter wrote:
On Wed, Nov 07, 2012 at 06:03:52PM +, Simon Kelley wrote:
On 07/11/12 15:46, Ted Lemon wrote:
I think the disconnect here is that people are thinking the routers
to which prefixes are delegated need to themselves be delegating
routers, but this is
On Wed, Nov 07, 2012 at 06:03:52PM +, Simon Kelley wrote:
> On 07/11/12 15:46, Ted Lemon wrote:
>
> > I think the disconnect here is that people are thinking the routers
> > to which prefixes are delegated need to themselves be delegating
> > routers, but this is incorrect. What they need to
Ted,
>> the OSPF based prefix assignment handle all of these, "out of the starting
>> blocks".
>
> I'm under the impression that a number of issues you mentioned as solved by
> OSPF and not solved by PD are actually not solved by OSPF. To respond
> individually:
which ones?
>> - in an arbi
On 07/11/12 15:46, Ted Lemon wrote:
I think the disconnect here is that people are thinking the routers
to which prefixes are delegated need to themselves be delegating
routers, but this is incorrect. What they need to do is _relay_
prefix delegation requests to the delegating router from whic
On Nov 7, 2012, at 10:59 AM, Ole Trøan wrote:
> the OSPF based prefix assignment handle all of these, "out of the starting
> blocks".
I'm under the impression that a number of issues you mentioned as solved by
OSPF and not solved by PD are actually not solved by OSPF. To respond
individually
Ted,
this has been proposed a few times. the problems that I see with it are:
- in an arbitrary topology how do you decide which interfaces you are a client
on and which interfaces you relay on
- how do you handle the case where multiple routers try to assign a prefix to a
link
- how do you disc
Ted,
this has been proposed a few times. the problems that I see with it are:
- in an arbitrary topology how do you decide which interfaces you are a client
on and which interfaces you relay on
- how do you handle the case where multiple routers try to assign a prefix to
a link
- how do you d
On Nov 7, 2012, at 10:46 AM 11/7/12, Ted Lemon wrote:
> I don't have a particular preference for DHCP-PD over OSPF in homenets, but I
> just wanted to quickly contradict what's been said by several people at the
> mic: that figuring out what prefix to delegate is hard. It's not hard,
> actua
I don't have a particular preference for DHCP-PD over OSPF in homenets, but I
just wanted to quickly contradict what's been said by several people at the
mic: that figuring out what prefix to delegate is hard. It's not hard,
actually—it's dead easy. The reason folks think it's hard is becaus
68 matches
Mail list logo
