Hello Dave and all:
So far I have not seen how the MAC randomization deals with:
- DAD - the chances of duplication seem much higher than for IPv6; maybe we can
help by doing DAD with something like RFC 8505 on the first hop switch / AP.
- differentiated environments - the preferred behavior
octobre 2019 15:39
To: Pascal Thubert (pthubert)
Cc: Michael Richardson ; 6MAN <6...@ietf.org>;
homenet@ietf.org
Subject: Re: [homenet] Support for RFC 7084 on shipping devices...
On Oct 7, 2019, at 10:58 AM, Pascal Thubert (pthubert)
mailto:pthub...@cisco.com>> wrote:
As you indica
Hello Michael
The order of order of 10^6 (hopefully 10^7) are the total deployed not a single
mesh. This makes RPL quite a well-deployed protocol.
As you indicate, a single mesh can approach 10^4. A depth can be al lot more
than the 10 hops that we imagined initially. Yet it keeps working.
Hello Ted :
The reason why we opted for ND proxy is not the lack of a homenet solution. It
is rather the fact that the wireless node keeps moving from a mesh to the next
and if they are different subnets then it needs to renumber, which we did not
know how to do efficiently – think dhcp or
operation in DC routing to inject virtual machines / containers addresses in
RIFT. It should work with other IGPs as well, and even BGP/eVPN, why not?
All the best
Pascal
From: Ted Lemon
Sent: lundi 7 octobre 2019 15:27
To: Pascal Thubert (pthubert)
Cc: Ole Troan ; Markus Stenberg ; 6MAN
&l
Hello Ole and Ted:
>
>>> Sounds like you need to set it up as a NAT.
>>
>> I really hope you are just making a funny joke here. But it’s not very
>> funny. What I want is something that’s operationally simple, not something
>> with lots of moving parts that have to be kept track of.
or decreasing Rank), a packet along a micro-loop is
detected and eliminated immediately.
Cheers,
Pascal
-Original Message-
From: Juliusz Chroboczek [mailto:j...@pps.univ-paris-diderot.fr]
Sent: mardi 11 août 2015 23:02
To: Pascal Thubert (pthubert) pthub...@cisco.com
Cc: Alia Atlas
RPL enables non-equal cost multipath, Alia. That's the reasonable thing (a MUST
if you ask me) to do with wireless connectivity when delivery is statistical
and metrics can only provide a limited approximation of transmission chances.
Any DV can do that easily so we should be able to do it with
From what I read below, one way out of this is the IETF making a
clear
statement that multicast is an integral part of IP networking, and if
a medium doesn't support delivering multicast frames in a similarily
reliable fashion to unicast, it's not suited to carrying IP based
protocols
(England)
Registered Office: Pipers Way, Swindon SN3 1RJ VAT No: 860 2173 47
-Original Message-
From: ieee-ietf-coord [mailto:ieee-ietf-coord-boun...@ietf.org] On
Behalf Of Mikael Abrahamsson
Sent: 10 August 2015 08:32
To: Stephens, Adrian P
Cc: Pascal Thubert (pthubert); Pat
-Original Message-
From: Mikael Abrahamsson [mailto:swm...@swm.pp.se]
Sent: lundi 10 août 2015 13:03
To: Pascal Thubert (pthubert) pthub...@cisco.com
Cc: ieee-ietf-co...@ietf.org; Dan Romascanu (droma...@avaya.com)
droma...@avaya.com; Stephens, Adrian P
adrian.p.steph...@intel.com
Mikael is correct;
IPv6 mechanisms are different.
SLAAC adds broadcasts that are not present in IPv4, MLD report then NS DAD
then, sometimes and though it is not required by the spec, NA(O).
IPv6 nodes tend to create multiple addresses, many of which are temporary for
privacy reasons. So the
I could not agree more.
It is simply unfair from the IETF to use Wi-Fi as if it was Ethernet and then
complain to IEEE that in fact it is not.
IPv6 over Ethernet makes heavy use of multicast over Ethernet, which for the
lack of a highly scalable Multicast service always ends up broadcasted
Hello Ted:
Seems that there's more work than what we can expect from a DT. Otherwise we'd
be all set by now.
What about forming a flash WG in routing area to see if:
- we can extract requirements for home
- there's such a thing as a one size fits all homes routing protocol
- provide
Certainly, Margaret...
... but then you have to differentiate the capability of any new proposed
protocol from what current IETF protocols already do to get that work chartered.
We are having an interesting chat on MANET and ROLL where the differences (and
core similarities) between BABEL and
Yes to both.
RPL had to address multiple IOT GWs from the start, say one for the power
utility, one for cloud access, etc...
to address this is that it creates multiple instances which are as many logical
topologies. By selecting the instance applied to a packet, the source or the
first RPL
6LoWPAN is not that specific and if every home usage needs a special
gateway, we're designing against the end to end principle.
Take the stereo / home theater. This is prone to become an ad hoc
network where infrared and cable connections will be replaced by various
flavors of 802.15, e.g.
Hello David
[David] Now, in reviewing this thread, I was disappointed to see that my ipv6
routing protocol of choice (babel) has not been discussed so far to any extent.
While this protocol is somewhat new, an rfc and working code both exist, and
working code has existed for several years.
+1
-Original Message-
From: homenet-boun...@ietf.org [mailto:homenet-boun...@ietf.org] On
Behalf Of Michael Richardson
Sent: jeudi 13 octobre 2011 02:42
To: homenet@ietf.org
Subject: Re: [homenet] Does ND Proxy useful for homenet?
Victor == Victor Kuarsingh victor.kuarsi...@gmail.com
nodes and all routers, and a
support for a multicast tree along the RPL DAG for generic multicast.
Cheers,
Pascal
On Oct 10, 2011, at 9:33 , Pascal Thubert (pthubert) wrote:
Hi Ole:
I think you're getting closer and closer to the models that were
discussed in RPL, 6LoWPAN and Autoconf
Looks obvious, but is it?
In one hand, we want the capability to reach anywhere we're allowed to from
home. OTOH, if anything in my home is reachable from anywhere, we are back to
the firewall paradigm.
There is an alternate model based on L3 overlays that was presented in various
places
Hi James;
As Ralph indicates, RFC4944 describes a L2.5 fragmentation mechanism and
recommends a MTU of 1280 on 802.15.4 links.
That fragmentation mechanism does not allow forwarding at L3 (each L3
hop needs to reassemble). It is also sensitive to frame loss, which
sadly is frequent in 802.15.4
22 matches
Mail list logo
