On Feb 20, 2015, at 11:33 AM, Juliusz Chroboczek
wrote:
>> Has the group considered a Bier model for multicast in the home?
>
> As in a place where you put dead people?
Bier is a new working group in the routing area.
https://datatracker.ietf.org/wg/bier/charter/
_
On Feb 20, 2015, at 8:22 AM, Mikael Abrahamsson wrote:
> 2. We set up some kind of L2 switching domain between the APs. This would
> require VLAN support in the HGWs, and something to set this up with loop
> avoidance etc. Oh oh oh, we could use IEEE 802.1aq that already uses ISIS as
> control
So Teco, to satisfy your use case, which I share, you would actually need the
homenet to identify all Wifi access points that are being used to serve hosts,
and treat those as a single subnet, correct?
___
homenet mailing list
homenet@ietf.org
https://
On Feb 19, 2015, at 5:23 PM, Teco Boot wrote:
> After having selected the Homenet Routing Protocol, I expect some discussion
> on how to set the metric. If box A from vendor A sets cost=100 on 1GE links
> and another box B from vendor B sets cost=50 on 2Mbit/sec WiFi links, we
> might have non-
On Feb 19, 2015, at 2:11 PM, Mikael Abrahamsson wrote:
> I'd imagine it's easier to do AQM on routed ports instead of switched ports
> as well, that's where I can imagine CeroWRT choosing this approach.
I don't think it is easier to do AQM on routed ports. If you do the easy
version of AQM fo
On Feb 19, 2015, at 1:56 PM, Ralph Droms wrote:
> But I think one of the important points for homenet is that many people will
> just buy "internet" devices, not routers and switches. I've been out of the
> loop so I should go back and check the architecture before I say too much
> more ... wh
On Feb 19, 2015, at 1:55 PM, Mikael Abrahamsson wrote:
> My employer has millions of subscribers using IPv4 multicast TV channels
> currently.
How's that getting through the NAT?
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/l
On Feb 19, 2015, at 1:55 PM, Steven Barth wrote:
> There is draft-ietf-dnssd-hybrid-00 for which we have specified glued to HNCP
> and a reference implementation. I think DNSSD is actually mostly covered or
> are you referring to any specific issue of that solution?
Hm, I will have to try it ou
On Feb 19, 2015, at 1:32 PM, Mikael Abrahamsson wrote:
> If 802.11 is so bad for multicast, do we even want to run IPv6 over it?
This would be a great objection to using 802.11 for host networks, but it's a
lousy argument against using 802.11 for transit networks!
> I know Dave T is trying to e
On Feb 19, 2015, at 1:29 PM, Ralph Droms wrote:
> If I can extrapolate and oversimplify a bit, now we've gotten to a
> fundamental problem: how does a random collection of devices, links and ports
> sort itself by DWIM into a coherent home network? How does a device with 16
> ports decide to g
On Feb 19, 2015, at 1:22 PM, Mikael Abrahamsson wrote:
> If we're going to be routing multicast within the home, we're most likely
> going to have to use some kind of variant of PIM. Asking the L2 switches
> people connect to the router to support both PIM and MLD snooping seem like
> it might
On Feb 19, 2015, at 1:08 PM, Mikael Abrahamsson wrote:
> I would like my router-to-router links to not have a lot of hosts in them if
> I can avoid it.
Why is that?
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homene
On Feb 19, 2015, at 12:33 PM, Mikael Abrahamsson wrote:
> Sure, ISIS could be made smarter when it comes to this, but it all comes down
> to what the requirements are. Right now when we started to evaluate routing
> protocols, people started pitching USP for their perticular favorite, and we
>
On Feb 19, 2015, at 12:09 PM, Mikael Abrahamsson wrote:
> I don't know if this is true or not. I know ISIS was running on Cisco 2500
> routers (which are motorola 68030 at 20MHz. I've had these kinds of devices
> involved in the "single level" ISIS domain for a fairly large network (I
> believe
On Feb 19, 2015, at 12:05 PM, Mikael Abrahamsson wrote:
> Yes. I don't see the problem with this.
It means that every single device on a wired network is on a different subnet.
Perhaps it doesn't cause any extreme harm, but it certainly makes managing and
debugging the network harder, and it
On Feb 19, 2015, at 10:41 AM, Mikael Abrahamsson wrote:
> Really? Then you and me have fundamental difference in opinion what
> topologies we want to see in homenet. I want to see fewer broadcast domains.
> If we're going to keep the large L2 domains, then we don't really need
> homenet at all.
On Feb 19, 2015, at 6:41 AM, Mikael Abrahamsson wrote:
> Basically, Dave Taht and Jim Gettys have been working a lot in these
> "marginal networks". They have a lot of experience. Personally, I don't see
> their kind of networks as something Homenet needs to support. I can see us
> needing to s
On Feb 19, 2015, at 3:52 AM, Mikael Abrahamsson wrote:
> For instance the security work now being done on HNCP. Does ISIS already
> offer the same functionality? I can't evaluate security very well, I don't
> know how many active in this working group that can. I would rather use an
> already s
On Feb 19, 2015, at 2:43 AM, Mikael Abrahamsson wrote:
> If people are making routing protocol decision based on the fact that they
> think most of the homenet links are going to be current incarnation of
> 802.11, then we're lacking consensus on a lot wider range of requirements
> than just th
On Feb 3, 2015, at 7:57 AM, Ole Troan wrote:
> what behaviour is that?
At the moment, handsets typically prefer wifi if available. Android 5 will
actually use both interfaces in an MPVD-style separation, so that the presence
of a WiFi interface is taken advantage of if it works, but doesn't b
On Feb 3, 2015, at 4:27 AM, Markus Stenberg wrote:
> PVD tell you also about the kind of connectivity available there etc. While I
> am sure we _could_ fabricate local one, it is much easier to tell that e.g.
> one upstream connection is pay-per-byte 4g, and other one is VDSL2 and let
> hosts m
On Feb 3, 2015, at 4:07 AM, Ole Troan wrote:
> is it actually obvious that you'd pass the PVDs to the hosts in homenets?
> PVDs contain policy. and allowing them to pass the administrative boundary
> into a home is also up to policy.
> given that we already have options to control DNS server sele
On Nov 24, 2014, at 10:56 AM, Juliusz Chroboczek
wrote:
> I'm a little ashamed to admit that I don't understand the purpose of
> reverse DNS.
Reverse DNS is useful for logging, so that you can associate a name with a
host. You don't necessarily want to (and may not be able to) send a request
On Nov 24, 2014, at 4:47 AM, Markus Stenberg wrote:
> Is this actually desired by the operators? At least here (.fi), ISPs seem to
> consider the reverse pointing to x.customer.y.isp.fi a feature, not a bug, of
> the current IPv4 deployment and specified same for future IPv6 deployments as
> we
On Nov 13, 2014, at 2:13 PM, Michael Richardson wrote:
> The devices that do not want to be discovered.
The point is that that description doesn't clearly identify any devices.
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/list
On Nov 13, 2014, at 2:07 PM, STARK, BARBARA H wrote:
> After dealing fairly extensively with such devices, I've personally come to
> the conclusion that it depends on the specific application and the usage
> model of the application. I don't think a global recommendation is possible.
Right, I a
On Nov 13, 2014, at 1:50 PM, STARK, BARBARA H wrote:
> If it does some form of multicast advertising of its "services", or is
> discoverable through a multicast discovery mechanism, over IP.
So to address this use case you'd want to say "if this is a device that
provides services using local n
On Nov 13, 2014, at 1:19 PM, Michael Richardson wrote:
> I'm saying: pick a GUA if you are a device which should be
> discoverable/reachable by default. That's not to say what your ACL should
> be. I presume that these devices do not otherwise use resources the way that
> my phone or laptop does
On Nov 13, 2014, at 1:17 PM, Michael Richardson wrote:
> I would say exactly that: they should prefer ULA over GUA,
Who is "they"?
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
On Nov 13, 2014, at 12:12 PM, Michael Thomas wrote:
> That said, I really do wonder -- given how trivial it is with v6 to get a
> GUA, -- how easy it is
> to keep things within, say, the home that we don't want to accidentally
> leaking out onto
> the internet from doing so[*]. My guess: hard.
On Nov 13, 2014, at 11:35 AM, Michael Thomas wrote:
> There's always two faced dns too. I would think you can do that even with,
> say, a provider
> dns delegation. The CPE would need to know "in" from "out" and decide what to
> serve up
> (rr requests, (i)xfer, hidden master zone xfer...) based
On Nov 13, 2014, at 11:35 AM, Michael Thomas wrote:
> Why guess when you can break into $MEGACORP and steal their server logs? If
> there's
> anything that the Snowden/NSA bizness should teach us is that brute force is
> not the
> only other option.
Different threat models demand different solu
On Nov 13, 2014, at 10:23 AM, Michael Thomas wrote:
> Nor do
> I think that the obscurity of not having a DNS name provides much in the way
> of privacy.
> There's way too much that can go wrong to count on either of these properties.
Not having a DNS name just means you have to guess the IP add
On Nov 13, 2014, at 10:09 AM, Michael Richardson wrote:
> If we conclude that ULA will always be present in the home, then devices
> ought to only have a ULA by default, and need to enabled to have a GUA.
> That's one of my major reasons I always want ULA to be available.
How would we accomplish
On Nov 13, 2014, at 12:58 AM, Michael Richardson wrote:
> 4) you can't just fill the zone with all the names -- it won't be secure.
> (4A - things that don't want global reachability, perhaps, shouldn't
>have globally reachable addresses)
There is a privacy issue here. And if
On Nov 12, 2014, at 11:27 AM, Andrew Sullivan wrote:
> I guess the idea is to answer
> authoritatively without being in the NS RRset? Some resilience
> mechanisms will treat that as a ijacking attempt, but I suppose if
> validation passes they shouldn't.
Why does it need to answer authoritativel
On Nov 1, 2014, at 7:41 AM, Sheng Jiang wrote:
> But getting back to where we start the discussion, I still think in a large
> network, the requesting prefix may not always be /64. It is reasonable to
> have multiple distributed sources for prefix assignment, in a large network.
> Autonomic net
On Oct 31, 2014, at 3:25 PM, Brian E Carpenter
wrote:
> Well yes. That's exactly why in autonomic management of prefixes,
> we need peer to peer negotiation, as in "I need 3 /64s that I
> don't have, do you have any spare ones for me?" Maybe it's
> badly explained but that is the whole point of o
On Oct 31, 2014, at 1:14 PM, Alexandre Petrescu
wrote:
> At which point one wonders whether Router Renumbering RFC2894 may need some
> updates.
I don't think that's the right approach. Renumbering makes sense when it's
needed, but renumbering whenever you need to balance the routing hierarch
On Oct 31, 2014, at 10:55 AM, Sheng Jiang wrote:
> The current general mechanism are too general to work for the use case of
> hierarchical prefix delegation. But if we add hierarchical topology and no
> bypass requests as constraint conditions, we may be able to make hierarchical
> prefix dele
On Oct 31, 2014, at 8:54 AM, Sheng Jiang wrote:
> Are you talking about assigning prefix for homenet? I thought we were talking
> about auto prefix management in a large network, which is ANIMA use case.
In either case, it's important to make the distinction between prefix
assignment and prefix
On Oct 31, 2014, at 1:53 AM, Sheng Jiang wrote:
> a) the requesting router knows the prefix length it should request;
It should always request a single /64.
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
On Oct 30, 2014, at 9:15 AM, Ole Troan wrote:
> the "flow-through" model as far as I can recall suffers from DHCP's general
> problem of dealing with multiple sources of information (think multihoming
> with separate CE routers), in addition you either need to build what's
> essentially a spann
On Oct 30, 2014, at 8:08 AM, Markus Stenberg wrote:
> What does flow-through PD mean? Do you have any reference on that?
It means that the edge router has the delegation, and then sub-delegates
individual /64s from the pool of /64s it was delegated by the ISP, rather than
splitting its delegati
On Oct 30, 2014, at 5:08 AM, Markus Stenberg wrote:
> I would personally rather drop prefix management. At least, the current
> proposed solution is DHCPv6 PD plus lot of marketing plus one extra thing
> (role) minus tons of existing functionality. I would rather stick the role
> into PD, than
On Oct 22, 2014, at 5:00 PM, James Woodyatt wrote:
> My point is that it doesn't need to be done that way unless HOMENET forces
> that design choice.
The scenario you are describing sounds like it's secondary. Yes, it's a valid
use case, but homenets working right is a use case that will see
On Oct 22, 2014, at 2:46 PM, James Woodyatt wrote:
> They may often be the only *default* routers, but there can be— and
> absolutely definitely will be in the vast majority of cases— overlay networks
> that route ULA prefixes to, from and most likely *between* home networks over
> tunnels. We
On Oct 22, 2014, at 2:04 PM, Michael Richardson wrote:
> Sure, people might not do that; sure there might be
> some people confusion when 5 friends get together for a "LAN" party ("hey,
> why are there three servers called 'quake'? Which one is "quake-1"?"), but I
> don't think that will be any sy
On Oct 21, 2014, at 2:55 PM, STARK, BARBARA H wrote:
> FYI. I made sure they were aware of IETF mif and homenet activities in this
> area. I intend to try to prevent having to track efforts that try to do the
> same thing in two different ways. But some of the BBF effort may be focused
> on wha
This work in the Broadband Forum might be worth paying attention to.
Begin forwarded message:
> From: Liaison Statement Management Tool
> Subject: New Liaison Statement, "Broadband Forum Work on “Hybrid Access for
> Broadband Networks” (WT-348)"
> Date: October 21, 2014 at 12:06:52 PM GMT-4
> T
On Oct 20, 2014, at 4:52 PM, James Woodyatt wrote:
> I did read what you wrote, and I do not agree that you are taking into
> account my concerns. Nevertheless, I shall stop arguing my case, and I will
> accept that I've lost it.
I persist in thinking that we are failing to communicate, but i
On Oct 20, 2014, at 4:24 PM, James Woodyatt wrote:
> Did you respond to my previous criticism of this idea? If so, then I missed
> it. It's not a good idea to commission a new standalone network with the same
> ULA as a previously commissioned network, because it destroys the main
> property of
On Oct 20, 2014, at 2:00 PM, James Woodyatt wrote:
> Okay... except it seems you're admitting that my scenario where a simple
> reconfiguration of a network topology, e.g. one caused by an intermittent RF
> interference on an unlicensed band of the radio spectrum, would result in a
> fully regu
On Oct 18, 2014, at 7:57 AM, Ted Lemon wrote:
> To clarify, yes, when the ULA is generated you have to do this, but you may
> revisit the decision subsequently, prior to partition. You don't know when
> partition happens, but that doesn't preclude making new choices later
On Oct 17, 2014, at 11:25 PM, Brian E Carpenter
wrote:
>> I did explain how to do that: before the network partitions,
>
> That seems to imply that you know in advance that the network
> will partition. I assume that it will usually be a surprise.
> Normally there is no human manager, although
On Oct 17, 2014, at 5:16 PM, James Woodyatt wrote:
> p1. It looks like you agree that locally generate ULA prefixes should be
> allowed to expire. What I don't see is any conceptual outline for deciding,
> in a distributed methodology, which prefixes to renew and which to release
> when their v
On Oct 17, 2014, at 4:41 PM, James Woodyatt wrote:
> I explained why you must generate a new ULA prefix every time you commission
> a new network.
Yes, you did, and I believe the mechanism I proposed for handling network
splits addressed the problem you described. If you think it didn't, can
On Oct 17, 2014, at 3:08 PM, Don Sturek wrote:
> Maybe this would be covered by the splits/joins topic but it does seem
> like ULA propagation changes in addition to the renumbering of the devices
> in the home using ULA prefixes.
I already covered both of those scenarios in a previous message.
On Oct 17, 2014, at 2:56 PM, Don Sturek wrote:
> How would a router know the boundary for dissemination of ULA prefixes?
Isn't that the same boundary as the homenet boundary? I think we already
solve that problem.
___
homenet mailing list
homenet@i
On Oct 17, 2014, at 2:49 PM, James Woodyatt wrote:
> As I recall, the proposals in your response were less than concrete and
> didn't solve the problems. In particular, I remain curious about how to
> expire the locally generated ULA prefixes that accumulate over repeated
> network joins and sp
On Oct 17, 2014, at 10:54 AM, Michael Richardson wrote:
> I will go back and read James' message about joins and splits.
> It seems that we have this problem with GUAs as well, and it seems that
> the whole address selection issue exists without ULAs, as long as one has
> multiple ISPs.
The issue
On Oct 17, 2014, at 10:45 AM, Michael Richardson wrote:
> In my mind, the kind of reason for a CPE device *NOT* to offer a ULA is
> because
> the administrator typed in their own (provider independant) GUA over the ULA.
Good point.
___
homenet mailing
On Oct 17, 2014, at 9:50 AM, Lorenzo Colitti wrote:
> But you're saying you want ULAs because you want to continue to do what you
> were doing yesterday: persistent connections, like SSH and X-windows. I think
> you're trying to fix the problem at the wrong layer. But I don't expect we'll
> agr
On Oct 17, 2014, at 8:46 AM, Lorenzo Colitti wrote:
> Yes (but again, it won't be killed by the renumbering; it will be killed
> *when its source address expires*). But I really doubt that real users have
> long-lived connections from apps that don't reconnect on failure. Geeks like
> us might,
On Oct 17, 2014, at 1:35 AM, Lorenzo Colitti wrote:
> You keep mentioning this, but you're incorrect. Even if the ISP
> flash-renumbers, hosts will not lower the lifetime of their IP addresses
> below 2 hours, per RFC 4862.
You are technically correct, and I will admit to having gone slightly i
On Oct 16, 2014, at 11:39 AM, STARK, BARBARA H wrote:
> I think support for receiving more specific routes in RA messages (RFC 4191)
> would be easier to get hosts to implement than DHCPv6.
This wouldn't help, because there's nothing to differentiate the GUA from the
ULA.
> In any case, I thin
On Oct 16, 2014, at 9:18 AM, Lorenzo Colitti wrote:
> So every time a new prefix comes in, hosts should restart DHCPv6? That seems
> pretty dubious (and expensive). I don't think any DHCP implementation works
> that way.
How do they work, then? And why would you describe this as expensive?
On Oct 16, 2014, at 9:08 AM, Lorenzo Colitti wrote:
> Um, no? Why would it?
Because that's an indication that there is new information to be had.
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
On Oct 16, 2014, at 8:43 AM, Lorenzo Colitti wrote:
> And when your ISP renumbers you, or a new ULA joins the network, you're going
> to tell the hosts about the new prefix policy using what type of packet?
> There's no reconfigure in stateless DHCPv6.
Wouldn't the host do a DHCP Information Re
s better avoided.
> On Thu, Oct 16, 2014 at 1:28 AM, Ted Lemon wrote:
>> My point was that homenets should have ULAs, and should not use GUAs for
>> local communication, because GUAs can be flash renumbered,
>>
> Actually, they can't.
Yes they can, as you just
On Oct 16, 2014, at 2:14 AM, Mikael Abrahamsson wrote:
> What I most worry about is for instance SSH.
Mikael, I think we have strayed sufficiently far off the topic that it is
harmful for us to continue discussing it on the homenet mailing list. I agree
with you that better presentation layer
On Oct 15, 2014, at 6:15 PM, Michael Thomas wrote:
> I'm talking about the server, not the client. ULA == unreachable on my
> neighbor's wifi.
> Don't want assumptions that servers on my home network will only be reachable
> by ULA's.
If a GUA is being advertised on your homenet, presumably you
On Oct 15, 2014, at 5:57 PM, Michael Thomas wrote:
> If I use a GUA to my jukebox, the routing will just work regardless of which
> AP I'm currently connected to. With ULA's, not so much. That's hardly a
> non-sequitur.
You appear to have some misconceptions both about how IP routing works and h
On Oct 15, 2014, at 3:01 PM, Michael Thomas wrote:
> See, I don't find that ideal at all. If I'm swinging around on my backyard
> trapeze watching
> the flying wallendas instructional video from my home jukebox, I really don't
> want to have
> my network break connectivity because I happened to
On Oct 15, 2014, at 1:34 PM, Michael Thomas wrote:
> I'm just pushing back that ULA's aren't necessarily without problems. It's
> easy to see how they
> can cause weird connectivity breaks across administrative domains. Though
> it's obviously not
> just homenets, wandering back and forth betwee
On Oct 15, 2014, at 11:35 AM, Michael Thomas wrote:
> What about when my device is wandering back and forth between my ap and my
> neighbor's?
I don't think that's a problem that we're scoped to solve, unless your and your
neighbors' homenets are a single homenet, in which case life is good.
_
On Oct 15, 2014, at 10:48 AM, Gert Doering wrote:
> Could you remind me what your point was?
My point was that homenets should have ULAs, and should not use GUAs for local
communication, because GUAs can be flash renumbered, and the use of them on the
local wire has the potential to cause disru
On Oct 15, 2014, at 10:04 AM, Gert Doering wrote:
> I explained my reasoning. Multiple times. Here and on other lists. Again
> and again.
When you repeat yourself again and again, people stop listening to you. There
was a consensus call done on this, and the architecture document contains t
> On 15.10.2014, at 7.58, Mikael Abrahamsson wrote:
>> Just to be clear, I am against flash renumbering, I want to see renumbering
>> done with 30-60 minute overlap at least. I however do see that we really
>> really need to support renumbering. One way of making sure that support
>> works is t
On Oct 14, 2014, at 7:09 PM, James Woodyatt wrote:
> Consider a hypothetical router that has the regular automatic default
> behavior of commissioning a new standalone network while discovering any
> existing networks that it already possesses the credentials to join. Now
> consider what happen
On Oct 14, 2014, at 6:05 PM, James Woodyatt wrote:
> p2. I do think a locally generated ULA prefix should not be renewed, i.e. it
> should be allowed to expire, when there is *any* prefix delegated [GUA or
> ULA]. Also when additional locally generated ULA prefixes are present after
> a networ
On Oct 14, 2014, at 5:14 PM, James Woodyatt wrote:
> But there is a problem with only deprecating prefixes without expiring them.
> If they never expire, then they accumulate without limit within existing
> networks as they join with newly commissioned networks over the course of
> their lifeti
On Oct 14, 2014, at 4:40 PM, James Woodyatt wrote:
> Naturally, you deprecate one of them, but my concern is that they never
> expire if the objective is for a ULA prefix to be invariant. So how many
> times can a network join with others before it runs out of space for
> deprecated and redunda
On Oct 14, 2014, at 4:31 PM, James Woodyatt wrote:
> There is also the exception that arises when two networks with different ULA
> prefixes are joined— now you have one network, with two ULA prefixes, neither
> of which can ever be allowed to expire.)
When we talked about this previously, I th
On Oct 14, 2014, at 2:19 PM, James Woodyatt wrote:
> On the topic of the original question, if I were to editorialize here, then I
> would want to see something like this:
I get that you have an opinion on this, but you haven't actually stated any
argument to support what you think we should do
On Oct 14, 2014, at 1:44 PM, Mikael Abrahamsson wrote:
> I know providers that cycle their PPPoE sessions once per day to give
> customers new IPv4 GUA once per day.
Right. This is IPv4. In IPv4 we typically use a NAT on the local wire, so we
get the effect we are trying to achieve either by
On Oct 14, 2014, at 11:22 AM, Sander Steffann wrote:
> One thing that does worry me is every application developer having to
> re-invent the code for all of this (find labels, actually implement the
> networking code correctly etc). I think a standard API should be available
> for all of this.
On Oct 14, 2014, at 10:46 AM, Gert Doering wrote:
> Application developers MUST handle changing addresses, for example by not
> doing silly things like "at startup, do some DNS resolving and socket
> binding to a fixed address, and assume that the addresses you receive
> are not changing".
This h
On Oct 14, 2014, at 10:46 AM, Gert Doering wrote:
> In the end, at some point in time, the old prefix goes away, however
> you phase it. So if the application stubbornly clings to it, it will stop
> working.
This is correct, but if you have a preferred and a deprecated prefix, the stack
will au
On Oct 14, 2014, at 10:41 AM, Gert Doering wrote:
> That reply doesn't surprise me the least, it's the standard answer from
> every geek who has not spent a few weeks thinking about this :-)
This isn't a helpful response, Gert. If you are right, you can explain the
reason that you are right.
On Oct 14, 2014, at 10:34 AM, Wuyts Carl wrote:
> I can confirm that. We have a customer handing out a new prefix every 4 days.
But let's be clear: is your customer doing flash renumbering, or gracefully
renumbering? If they are flash renumbering, are they doing it because they
had a choice,
On Oct 14, 2014, at 9:59 AM, Gert Doering wrote:
>> Indeed. The question is, should we increase the number of instances in
>> which they are forced to handle it, or no?
>
> Because this is the only way that application developers will learn to
> handle it.
Application developers _can't_ handl
On Oct 14, 2014, at 9:27 AM, Gert Doering wrote:
> "flash renumber is a problem" is pretty much a non-argument, as flash
> renumbering *will* happen, and devices in the home *will* have to handle it.
Indeed. The question is, should we increase the number of instances in which
they are forced
On Oct 14, 2014, at 3:12 AM, Erik Kline wrote:
> Among other things, if my home edge router losing it's upstream it (in
> theory) doesn't have to deprecate the global prefix in the home, just
> the default route. Since I can't get to the Internet anyway, all I
> need is (almost) any prefix, and t
You guys are debating points that are long-since decided.
On Oct 8, 2014, at 8:29 AM, Alexandru Petrescu
wrote:
> Le 08/10/2014 14:15, Pierre Pfister a écrit :
>>
>> Le 8 oct. 2014 à 13:58, Alexandru Petrescu
>> a écrit :
>>
>>> Hi Pierre,
>>>
>>> Le 08/10/2014 13:28, Pierre Pfister a écrit
On Oct 1, 2014, at 8:41 PM, Ted Lemon wrote:
> The ANIMA BoF (Autonomous Network Integrated Model and Approach) appears to
> relate to the work being done on HNCP, so Dave Thaler suggested, and I agree,
> that it would be helpful for Homenet participants to look at the BoF agenda
&g
The ANIMA BoF (Autonomous Network Integrated Model and Approach) appears to
relate to the work being done on HNCP, so Dave Thaler suggested, and I agree,
that it would be helpful for Homenet participants to look at the BoF agenda and
think about whether or not there is synergy or conflict here.
On Sep 29, 2014, at 9:16 AM, Stephen Farrell wrote:
> If, OTOH, you can say that you would in fact also require
> origin authentication, then that is also of interest. (It'd
> mean that your use case could not be met by the initially
> chartered work for DICE, and that factoid could be helpful
> i
On Sep 29, 2014, at 3:50 AM, Stephen Farrell wrote:
> Sooner would be much better than later for that as the DICE
> WG are right now in the process of (re-)considering whether
> they can in fact meet their chartered goals on this topic.
Unfortunately I think at this point we are distracted by a d
On Sep 24, 2014, at 10:00 AM, Steven Barth wrote:
> Maybe adding that we should try to use an existing and well-tested mechanism
> unless there is a very good reason not to.
I don't think there is one, but if you think there is you should tell us! :)
__
401 - 500 of 767 matches
Mail list logo
