that this 'easy/smart' technique is a thing
of the past... Or, am I missing something ?
I doubt STB or ATA box will do MAC address randomization. Why would they?
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
homenet mailing list
homenet@ietf.org
https
address in a portal and
depending on this MAC address, your HGW will either receive IPv4 GUA or
end up behind CGN. So this differentiation is done on MAC address. Don't
know if you consider this "part of DHCP request" or not.
--
Mikael Abrahams
be to use DHCPv6-PD, turning sub-router WAN firewall off
and enabling service discovery proxies, as I outlined in previous email.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
reachability to
its LAN IPv6 prefix (either GUA+ULA if PD is available, otherwise just
ULA). I have never seen RA guard or similar functions in residential
equipment, so I would expect this to work.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
__
(I've had the same IPv6 prefix now
for a year).
The conclusion is that we need to create solutions that handle both these
cases.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman
le routers within the home.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
on the platforms they have
available to them. Nothing wrong with that and the results are great, it's
just not applicable to a lot of equipment out there that it should be
applicable to.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
homenet
ds
itself better for implementation in existing hardware, or hardware with
small modification.
Sometimes it's better to accept non-perfect more easily implementable
solutions that solves most of the problem space, instead of aiming for the
"perfect one" and getting nothing.
-
the bufferbloat movement has gravitated
towards, but I still feel what I said wasn't really accepted and "taken
in".
--
Mikael Abrahamssonemail: swm...@swm.pp.se___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
actual transport payload speeds of upwards of 1 gigabit/s
on wifi isn't uncommon. We're also now seeing devices with even higher
port speeds than 1GE, but that might take a bit longer to reach wider
adoption.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
at can be used there or the other way around?
--
Mikael Abrahamssonemail: swm...@swm.pp.se___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
very.
From a user perspective, there are a few problems:
When an interface goes down and then up again, it's renumbered. This
includes reboots. Since we still do not have session continuity across
address changes, this is hard. Same with the separate routing domains
between APs.
--
Mikael Abrah
.
So while I do not see this as an immediate homenet concern (homenet should
for now focus on getting the automatic plug-and-play functions correct),
going forward I do think it would be good to look into these issues.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
http://domainincite.com/20911-are-mail-home-and-corp-safe-to-launch-applicants-think-so
"All three were put on hold indefinitely. ICANN said it would ask the IETF
to consider making them officially reserved strings."
So a resounding YES to "make .home reserved"?
-
ound after
operational experience with the protocols and that them not knowing
anything about each other caused operational problems and outages.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
homenet mailing list
homenet@ietf.org
https://ww
-hoc use seems to be exactly the
same use as RFC7788 uses it for.
Why not formalise it?
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
On Mon, 18 Jul 2016, Ted Lemon wrote:
Zero. See the discussion in draft-tldr-sutld-02 on this topic (search
for .home).
I guess you mean https://tools.ietf.org/html/draft-tldr-sutld-ps-02 ?
I can't find any mention of .home in it.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
On Mon, 18 Jul 2016, Mikael Abrahamsson wrote:
The option 4 mentioned updating RFC7788. It's not clear to me what this
update would be.
.HOME has not been handed out by ICANN yet, what's the odds that RFC6761
process reserving .HOME for special use would succeed?
Let me just clarify
The option 4 mentioned updating RFC7788. It's not clear to me what this
update would be.
.HOME has not been handed out by ICANN yet, what's the odds that RFC6761
process reserving .HOME for special use would succeed?
--
Mikael Abrahamssonemail: swm...@swm.pp.se
.
So while this was a problem 10-20 years ago, I'd say it isn't now.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
he routing protocol at all, right? It just sets
up the landscape so the routing protocol can come and survey it and
communicate the contents.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
homenet mailing list
homenet@ietf.org
https://www.ietf.o
t have a lot of them), you just keep state for a single /64 <->
MAC mapping (still network wide).
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
?
I have 3x WDR4900,2x WNDR3800 and 2x WRT1200AC to play with. If someone
has code, I can do tests.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
can do make-before-break? A quick search
seems to indicate that 802.11 roaming is strictly break-before-make?
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
charter).
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
switche to you. If not, run HNCP /64 algo and tell everybody else.
You still have to sync all information between all HNCP speakers anyway in
order to facilitate fast handover, both for /128 and /64 solution.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
On Mon, 30 Nov 2015, Steven Barth wrote:
On 30.11.2015 13:24, Mikael Abrahamsson wrote:
You still have to sync all information between all HNCP speakers anyway
in order to facilitate fast handover, both for /128 and /64 solution.
That's not correct. If you read the draft, in the /128 case
ould require routing
protocol participation as well, I'd imagine.
If 802.11 can assure L2 handover in 1 second (I don't know how long the
handover time is, just guessing), how much are we willing to add in time
because of L3 mechanisms added on top of this, before packet flows are up
and runnin
to be solved where (IETF/IEEE).
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
should add in
/etc/config/babeld:
config general
option diversity true
What does that do?
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
changed anything,
right?
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
On Fri, 23 Oct 2015, Mikael Abrahamsson wrote:
uploading it to Youtube now. https://youtu.be/VXE5_cOcTvw (it's still
https://youtu.be/j3-651rmClc instead, Youtube didn't do what I expected it
to do... It'll still processing the higher resolution videos, it's
unreadable in 360p.x
--
Mikael
ast mode now and see if there are some obvious differences,
I don't believe there will be since my radio environment is not extremely
crowded and they're mostly used for point-to-point link.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
homenet mailing l
to be much multicast loss
because 2.4GHz isn't hugely congested where I live.
Now that I have a better feel for the setup and most of the bugs worked
out (I hope), on monday I'll do quite a few more tests and I also intend
to use babel and try a few similar test cases with it and compare.
loss.
I could for instance make a screen shot video of 10 minutes of testing
with all the values scrolling, on the screen including the homenet web
"bubble" diagram in the corner somewhere, and "ip monitor" running so the
metrics can be seen continously.
Suggestions for t
be informative if we actually finally had the discussion on
what kind of Homenet we're actually aiming for. We still have no concensus
on that as far as I can tell.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
homenet mailing list
homenet@ietf.org
, or
are you implementing random features so you can tick a box in your marketing
litterature?
Could you please link to experimental testing you have done so we can
understand what kind of testing you're expecting to happen, and what data
to come out of it?
--
Mikael Abrahamssonemail: swm
a homenet looks like, does
anyone believe that this test is worthless, or does it at least give some
valuable data?
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
said would be there. So please LINK (not drop google search
terms) to the data that you think is relevant for homenet.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo
DME file.
-Christian
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
homenet mailing list
homenet@ietf.o
to decide not to use a bad link if
there are no other alternatives available? Bad links should be avoided if
there are better available, but if this is the only one available it
should be used anyway?
--
Mikael Abrahamssonemail: swm...@swm.pp.se
wise), nothing is done as long
as HNCP is up.
One way of solving this would be to create fate-sharing between HNCP and
the routing protocol. Ie, HNCP wouldn't do anything unless there is a
valid routing protocol adjacency with that neighbor (=fate sharing).
--
Mikael Abrahamssonemail: swm
think the homenet routing protocol should
support ECMP on wired links that are between two directly connected
devices with identical link speeds. I'm fine to leave the radio interface
ECMP as a future research project.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
On Tue, 25 Aug 2015, Ray Bellis wrote:
On 25/08/2015 19:38, Mikael Abrahamsson wrote:
So my previous opinion stands, I think the homenet routing protocol
should support ECMP on wired links that are between two directly
connected devices with identical link speeds. I'm fine to leave the
radio
. Why is this needed? Where
do the duplicates come from?
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
consulted routing tables.
So it takes whatever metric it came up with and sets the metric as kernel
priority? So if there is a shorter prefix that has a lower metric, this
will be chosen over a longer prefix with higher metric?
--
Mikael Abrahamssonemail: swm...@swm.pp.se
Link would keep all kinds of state between them (for
instance DHCP leases), and while this would be nice, I see this as a huge
complication that is probably not worth doing?
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
homenet mailing list
and choose that NH.
--
Mikael Abrahamssonemail: swm...@swm.pp.se___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
as they discover two paths with identical metrics.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
the L2 network so that devices can't talk directly to each
other, and you want to make the L3 configuration reflect this so you don't
have to do magic tricks like local-proxy-arp (whatever that would be
called in IPv6)).
--
Mikael Abrahamssonemail: swm...@swm.pp.se
correct.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
multicast packets to the AP in L2 unicast so the AP can then send it as
multicast using above mechanism, including queuing it for multiple
delivery.
Thoughts?
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
homenet mailing list
homenet@ietf.org
https
counts. Which should
of course not prevent us from experimenting, quite the opposite.
I wouldn't want to do ECMP across widely different mediums and make it
super advanced with unequal load balancing etc, but if I hook up two wired
GIGE between two homenet routers, why not use it?
--
Mikael
-path_routing
So basically:
A--B
| |
C--D-E
If metrics of ABDE and ACDE is the same, then program FIB to split L4
flows between these two paths by means of for instance hashing.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
homenet mailing list
homenet
things break.
--
Mikael Abrahamssonemail: swm...@swm.pp.se___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
think
homenet really should have taken off), this is going to be a lot more
common. So ruling out ECMP right now seems short sighted.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org
to figure out, how do we handle these IA_NAs and IA_PDs that are not
within an on-link RA being sent for that prefix.
This is definitely not a configuration error, it's perfectly valid to hand
out single address using DHCPv6 IA_NA that isn't covered by an off-link or
on-link prefix.
--
Mikael
-hardware/comcasts-2-gigabit-service-will-cost-300-plus-1000-for-installation-and-activation.html
So if this is now the case, why would I not want to be able to put 2x1GE
between my homenet routers to actually make use of this bandwidth?
--
Mikael Abrahamssonemail: swm...@swm.pp.se
on-link PIO from A for the on-link ABCD DHCPv6 IA_NA prefix
/64 RIO (?) from D for its DE /64
/64 RIO (?) from B for its BF /64
Or do we want above RIOs to be off-link PIOs instead?
--
Mikael Abrahamssonemail: swm...@swm.pp.se___
homenet mailing list
connction. A lot
of short-lived traffic could be handled like that. However, this wouldn't
solve real time communictation, there the protocol itself would need to
tell other end to start using another address for continued communication.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
that does what I want.
I come with my laptop with an ongoing mosh/ssh session, I plug in my
laptop, I see it connect to the wired network, 3 seconds later I disable
my wifi, and my mosh session still works. I wish all protocols worked like
this.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
and
IA_PD, if the same kind of behaviour can work there somehow. This is out
of scope for homenet though.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
IP for 802.11, is for 802.11 networks to
deliver broadcast and multicast packets with around 0.1% packet loss (or
less) as a design goal for normal operations.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
homenet mailing list
homenet@ietf.org
thought were obvious (I believe).
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
hasn't historically said I'll
handle Internet traffic for source addresses within all prefixes that I
announce, both offlink and on-link. Perhaps we can say that it does, but
it's not obvious to me that there are no corner cases for this that'll
break things.
--
Mikael Abrahamssonemail: swm
On Mon, 10 Aug 2015, Henning Rogge wrote:
On Mon, Aug 10, 2015 at 9:32 AM, Mikael Abrahamsson swm...@swm.pp.se wrote:
IETF standards generally assume that multicast and unicast are delivered
with a similar level of packetloss (which is low).
Not all 802.11 implementations have the multicast
] On Behalf Of
Mikael Abrahamsson
Sent: 10 August 2015 08:32
To: Stephens, Adrian P
Cc: Pascal Thubert (pthubert); Pat (Patricia) Thaler; ieee-ietf-co...@ietf.org;
Dan Romascanu (droma...@avaya.com); Glenn Parsons; Homenet; Eric Gray
Subject: Re: [ieee-ietf-coord] [homenet] Despair
On Mon, 10 Aug 2015
we achieve this?
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
it's been said regarding security and encryption. I have little
problem with this approach as long as we have consensus that this is the
way things should be done.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
homenet mailing list
homenet
?
Does the operating system need to support it as well?
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
battery powered devices and wired devices in the same place?
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
On Mon, 10 Aug 2015, Pascal Thubert (pthubert) wrote:
Unsure about your profile, Mikael. Ethernet would be a #2 by now, only
things like sat-links could still be #1s. So the work would really be to
I don't agree, wired ethernet is still #1 if you ask me.
figure out what to do with the
protocols but not for IPv6.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
members that if
they don't implement assured multicast replication, IP doesn't work
properly. Then they can decide what should be done in the short term,
because changing IP will take quite a while.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
development isn't there yet I believe.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
range? Can you
give an example of a sub-100USD residential consumer wifi-router/AP that
implements this?
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
what is required, and this
was never written down either.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
to minimum, or work that will
make multicast as reliable as unicast. Are you really now saying it's not
that bad from your experience at battlemesh? How much IPv6 do you do at
battlemesh anyway?
--
Mikael Abrahamssonemail: swm...@swm.pp.se
that people who are saying it *has* to be babel
isn't a very vocal minority as well?
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
) compared to IPv4. This is still
now 20 years later a mindset seen widely throughout the IETF because
nobody (as far as I know) has clearly said otherwise.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
homenet mailing list
homenet@ietf.org
https
(as far as I can see) any dialogue
with 802.11 to be a non-optimal way of solving the problems we're seeing.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
.
What probably needs to happen is that over time, the IETF should try to
use less multicast, but on the other hand, 802.11 really needs to make
sure that multicast works a lot better than it does today.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
.
In short: I largely agree with Ted, but I see the WIFI backbone use case
as a killer differentiator for Homenet (regardless of the final choice
of routing protocol). If IS IS can't deliver on that, then it's a real
miss.
It can.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
a commercial grade
test suite with 1000+ test cases to check that the implementation does
what it should. How will future implementors of babel test their
implementations against what's in the standards?
--
Mikael Abrahamssonemail: swm...@swm.pp.se
this is better than what the IETF does, but
others do not.
we keep waiting for that we never get anything done. Do we want a
'perfect' protocol in years or do we want a good solution today? We have
what we need: let's move on...
That's your opinion.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
/hnetd configured address+prefix on
interfaces which is then picked up by the routing protocol when it looks
at what addresses/prefixes are available on what interfaces. Am I wrong?
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
homenet mailing list
On Wed, 5 Aug 2015, Teco Boot wrote:
PS. It could be a tough job to get bursty multicast frames in AC_VO. At
least it needs a shaper for xx% of airtime.
Why multicast?
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
homenet mailing list
and a retransmit scheme in case of packet
loss. For relayed messages, a jitter mechanism SHOULD be used
to desynchronize for collision avoidance.
Why does the L3 layer need to do collision avoidance? I thought this was
up to L2 to do.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
and broadcast work on wifi
because most L3 protocols rely on it, including IPv4 and IPv6.
I don't know what happened after that, I didn't hear anything back. I
asked multiple times.
I pinged them again just now, replying to the previous ping email on
this issue from March 2015.
--
Mikael Abrahamsson
commercially available ISIS compliancy testing suites, and there will be
two implementations written in two different programming languages both
passing these tests.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
homenet mailing list
homenet
On Thu, 23 Jul 2015, Alejandro Acosta wrote:
Hello,
I wonder if this side meeting was recorded? Is there a way to watch it
offline?
No, it was not recorded. The slides will be made available though, at
least that was discussed during the meeting.
--
Mikael Abrahamssonemail: swm
routing. In this case we're saying
HNCP/hnetd sets up prefixes, but it doesn't set up metrics. This
clarification would be good to have somewhere.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
homenet mailing list
homenet@ietf.org
https
a routing protocol
doesn't autoconfigure its metrics, but I now realise that this is probably
what babel does? I thought the mechanism of configuring the metrics was
separated logically, but I now realise this isn't how it has been done in
babel?
--
Mikael Abrahamssonemail: swm...@swm.pp.se
that the
routing protocol is self configurable, so I guess this is why we have
differing views on what things are up to the routing protocol and what is
up to the rest of the architecture to set up and influence.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
that this is intended to be a protocol that's being
implemented and run by a lot of different vendors who do not have a great
track record of writing and maintaining excellent software (to put it
mildly). Any help given to them to get their implementations right is very
valuable.
--
Mikael Abrahamssonemail
be reading the document trying to understand what's
going on, why things are done the way they are, etc.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
and that both code bases will be “production
grade” code.
We hope this will address the major concerns about IS-IS being not
suitable for homenet use because of its use of multicast and that it
doesn’t run over IPv6, and also that the Erlang codebase is too big.
--
Mikael Abrahamssonemail: swm
On Wed, 15 Apr 2015, Lorenzo Colitti wrote:
On Wed, Apr 15, 2015 at 11:07 PM, Mikael Abrahamsson swm...@swm.pp.se
wrote:
Coming from the ISP side, I also question OSPF being mentioned as IGP
while totally excluding ISIS. I dare to say that a majority of the larger
ISP networks of today
1 - 100 of 199 matches
Mail list logo
