[1] https://github.com/fingon/hnet has 'super-repository' which
has custom NetKit version, OpenWRT AA github link and everything
else to get it running on a Linux desktop for playing with
(with OpenWRT UML images running in a NetKit lab).
[2] https://github.com/fingon/hnet-openwrt-feed
If you're actually doing source-specific routing, please show me how
you speak to the kernel.
Most of that code is in Lua, and while I could have included
C extension module that did similar things as ip -6 does, I didn't
bother.
We're doing pretty the same in our prototype code (saying
---BeginMessage---
Dear all,
Here is a small demo of source-specific routing in babeld in a multihomed IPv6
environment:
http://www.pps.univ-paris-diderot.fr/~boutier/source-specific-routing.html
This page will be updated with our experiments with MPTCP. Currently, it seems
to work
Excellent. Could we please have a look at the source code ? (It was
already promised in Berlin, if memory serves.)
We will make it public after testing it in live networks
Ah, I see.
If you want, I can send you the current version privately at this moment.
I'd much prefer a public
Ok, we will make it public in this week.
The page for the project is here: https://github.com/t-routing/
traffic-class-routing-system-based-on-OSPFv3
Thanks, but could you please point us at your code? That's a full
Quagga tree merged with a full Click tree, with no development history.
Hi Ole,
We need to decide, if we want prefix assignment and distribution of other
configuration information integrated in a routing protocol.
There's two orthogonal decisions.
One is whether to make the configuration protocol a subprotocol of the
routing protocol. (I have mentioned earlier
You (and others) who speak of a Homenet Configuration Protocol
seem to be making an assumption [...] that config parameters in
a homenet will come in some sense top-down
I don't think we are. (But you're right, this deserves stating explicitly.)
I think that most of us have in mind a
Also, since we already have to bootstrap an auto-configuring routing
protocol, why not leverage this work to distribute other information?
As usual, it's a tradeoff, and the choice of tradeoff is dependent on
one's background.
Those of us who come from the Free Software chaos will prefer
Despite the protests, I detect hints of top-downness in many of the
messages on this thread.
Yes, it's an easy mistake to make. You're right, we should be very
vigilant about that.
-- Juliusz
___
homenet mailing list
homenet@ietf.org
---BeginMessage---
Hi,
We wrote a conference paper on source-sensitive routing, which you will found
there:
http://hal-univ-diderot.archives-ouvertes.fr/hal-00947234
http://fr.arxiv.org/abs/1403.0445
Matthieu
___
Babel-users mailing list
Hi,
During this morning's session, I mentioned how much I like the HCNP
protocol, and that I'm looking into abandoning AHCP for a hacked-up
HCNP. I made the following points this morning:
0. As far as I'm concerned, this is not The Homenet Configuration
Protocol, this is a configuration
We are soliciting reviews for this SUNSET4 draft:
http://tools.ietf.org/html/draft-ietf-sunset4-noipv4-00
In a nutshell, it defines DHCPv6 and RA options indicating to the host
that IPv4 is not available.
It seems to me that options relating to IPv4 don't belong in RA/DHCPv6
-- they belong
Having a degenerate DHCPv4 server that just NAKs every request
would appear to solve all of the problems in Section 3.
Actually no, this would create packet storms.
My bad -- I didn't actually check.
So either an empty OFFER, as suggested by Markus, or an OFFER with
a new *DHCPv4* option.
I'm only saying that from my perspective, changing DHCPv4 is the best
technical solution.
Right, but you haven't given a technical argument to support that.
You're being somewhat disingeneous here, Ted.
We're arguing that information about IPv4 availability should not be
carried by IPv6
slowly I've gotten to understand the numerous layer-2 and layer-3
savings by not having to have the whole DHCPv4 relay and broadcast
processing occuring.
Could you please explain that? Perhaps with some examples, or even
actual empirical data?
-- Juliusz
slowly I've gotten to understand the numerous layer-2 and layer-3
savings by not having to have the whole DHCPv4 relay and broadcast
processing occuring.
Could you please explain that?
let me see what I recall...
That's interesting, especially the FTTH case. Thanks for the info.
--
ISIS is great for ISP environments, but does not nicely adapt to a unix
environment where the kernel has no idea about ISO/OSI protocols and
you have to do everything via raw sockets.
This is actually a feature, the fact that ISIS doesn't require IPv6 to be
up and running before it can get
[...] IPv6, where routers communicate using link-local addresses. For
what it's worth, Babel is quite able to establish adjacencies before
addressing is up as well as in pure IPv4 networks.
I've received a few questions about this by private mail, so please let me
lecture a little. The
This sounds _way_ too specific to me.
If you are just going to laugh,
Laugh with us, Ted -- it /is/ rather funny.
(I especially liked the linear sum touch. What's a non-linear sum?)
This statement should be inclusive of whatever routing protocols the
working group is inclined to consider,
I was involved in this discussion
I'm genuinely sorry to hear that, Acee.
the statement was merely an attempt to capture the fact that the
existing unicast IGP routing protocols would meet the homenet
requirements [...] while BGP would not be precluded, BGP's rich routing
policy is not
But what is the routing supposed to accomplish?
Good point.
The role of the routing protocol is to provide good enough end-to-end
connectivity often enough, where good/often enough is defined by user
expectations.
Rapid convergence has been mentioned.
That's an implementation technique for
So LLNs are customers of whatever connectivity the homenet routers
provide, and are not themselves homenet routers.
Ah, I see. This does not preclude an LLN router from implementing support
for Homenet, just makes it explicit that Homenet makes no such requirement
on LLN routers, and makes no
Is a specific update address preferred?
[my view] The routing protocol should support both use of unicast and
multicast updates.
Please clarify. Are you saying that the routing protocol must be able to
run over link layers that don't support link-local multicast? AFAIK,
link-local
path selection in a homenet needs to be more refined than minimising
hop count.
{BABEL, EIGRP, full IS-IS .} might be preferred over {OSPFv3}
To be fair, there's nothing *in principle* preventing an implementation of
OSPFv3 from encoding interesting stuff within its metric --
Source-specific routing
===
We've found a problem with interoperability between source-specific Babel
and plain Babel. I don't think the current implementation has the
problem, but the current packet format does in principle allow encodings
that plain Babel will mis-parse.
Thanks for your answer, Daniel.
If I understand it properly, the use case you consider: 1) you set up
a web server in your homenet, 2) you want it to be accessed from the
outside so you register your domain name and register the IP address to
the zone. Note that In this case, the
I'd like to understand why the device needs to go through the middleman
rather than speaking directly to the authoritative DNS server.
You may find some useful background in RFC 5625.
I'm increasingly confused. RFC 5625 is about proxying DNS requests from
the LAN. Daniel's draft is about
The main idea is that the CPE builds the zone for the whole home network.
Thanks for the clarification.
Daniel, perhaps I'm still misunderstanding something -- but I'm afraid that
right now I'm strongly opposed to this protocol. I hold no opinion yet on
whether proxying is necessary (although
- The architecture document
[draft-mglt-homenet-front-end-naming-delegation] in NOT CPE specific.
- The DHCP Options document
[draft-mglt-homenet-naming-architecture-dhc-options] is currently CPE
specific.
Ah, I see. That definitely needs to be clarified.
- a) Explicitly mention
I assume you mean that we need to recommend a default policy and also
document the range of other policies that the end user might choose to
use.
No, I just mean that Markus not wanting anything published in DNS is
policy, and that's completely independent of whether we want to define
a
RJ,
If I understand you right, you're pushing for an approach where we don't
say anything about the routing protocol, and wait for the market to
converge on RIPng, thus ensuring interoperability. Please correct me if
I've misunderstood you.
(My personal opinion right now (subject to change) is
requirement for HNCP to support a stub network with a gateway that
doesn't have sufficient resources to run a routing protocol.
Could someone describe what sort of resources these gateways (nest, I
assume) actually have? - What OS they run, how much ram and flash is
on them, is there virtual
In the impromptu meeting on Thursday, I believe that James Woodyatt said
that his nodes have 64K of ram and that code executes-in-place out of
ROM. He didn't say how much of that 64K is currently used for data for
other parts of the system.
A box with that little RAM should definitely be
Since the assumption is that the device runs HNCP anyway, the intent is to
use that for the stub-only routing.
I'm probably just being slow, but I have trouble understanding how that's
supposed to work.
At some point, the stub network needs to be redistributed into the routing
protocol. Who
While we didn¹t spend a lot of time on it in Thursday¹s meeting, it was
proposed that the IoT device domain would never be used for transit so it
only needed to get a default (or other aggregate) and inject a prefix and
the HNCP could be made to satisfy this requirement.
Could you please
I've thought about it some more this morning, and I've changed my mind:
I think it's actually not a bad idea, and if done right it might even work.
1) pure peering
- homenet - LLN ::/0
- LLN - homenet more specifics for LLN routes and cloud service prefixes
Ok. What I'm still not clear about
If the latter, I can see some opportunities for transient routing loops
if not done carefully. (And you certainly don't want a routing loop on
a link with low-power nodes.)
That’s interesting. Could you try explaining what could happen ?
I hope I'm just being paranoid, since I rather like
Something of an aside to this conversation, but there is a similar
problem in dealing with an external gateway that does not speak the
routing protocol either.
Aye.
The ¨babel-pinger¨ mechanism
http://lists.alioth.debian.org/pipermail/babel-users/2008-September/000160.html
would have
Isn't the Nest pinger just a shortcut for reducing the intervals and
validity times of the information transfer between the Nest-node and
the true-Homenet-node?
If I understand Dave right, the idea is to switch things around: instead
of having the Nest node speak a stub version of a Homenet
http://www.tinyos.net/
http://blog.antoine.li/files/2011/09/babel_paper.pdf
I don't think they ever finished their implementation. (But at least
I got to visit Lucerne.)
-- Juliusz
___
homenet mailing list
homenet@ietf.org
What feature of babel keeps traffic from looping during re-convergence?
Please see
http://www.pps.univ-paris-diderot.fr/~jch/software/babel/babel-20140311.pdf
slides 7 and 11-17. I'll be more than happy to clarify anything that's
not obvious from the slides.
-- Juliusz
[This is cross-posted between babel-users and Homenet@IETF, please choose
your followups wisely.]
You might remember the stub-only implementation of Babel that I published
last week-end:
https://github.com/jech/sbabeld
After playing some more with it, I've come to the conclusion that it
I think I understand. If there is the potential for a loop (advertised
distance = babel router’s former distance), babel will wait for the
next sequenced route from the source.
Exactly.
So, the loop-free guarantee is at the expense of potentially faster
convergence.
In principle, yes.
I do note that the default 4 sec update interval bugs me.
It's probably the Hello interval that's biting you, not the Update
interval.
crank up the update interval by a factor of, say, 1, to see what
happens.
You cannot, Babel won't go below 10ms. (Hard-wired in the on-wire
encoding,
Dear all,
Following some friendly bullying by Markus and others, Matthieu Boutier
and I finally finished writing up the source-specific extensions to the
Babel protocol.
http://tools.ietf.org/html/draft-boutier-babel-source-specific-00
It's a -00, but we've done our best to ensure that it is
it seems likely we may face transition from one generation of [routing]
protocol to another, possibly sooner than we would like. Similarly,
HNCP may need a revision,
In my (biased) opinion, this is the important bit of your mail.
I think we've already avoided the largest pitfall -- HNCP and
sbabeld doesn't speak to the kernel itself, it execs the ip utility
instead. That makes error handling somewhat random,
Steven has fixed that -- sbabeld's error handling should be reasonably
reliable now. (And it's also slightly smaller.)
-- Juliusz
a method to delegate reverse [DNS] zones to CPE devices
Is this actually desired by the operators?
I'm a little ashamed to admit that I don't understand the purpose of
reverse DNS.
To my naive eyes, if you already know the IP of a host, then you should be
able to ask the host directly for its
Shouldn't we reduce the amount of cross-posting at some point?
mptcp, I'm told, is likely to show up in Apple and Google products and
infrastructure, and my idea (and many others) is that you don't always have
to pick the perfect address for the SYN, just one that works, but rather one
can
The ideal scenario is where the host app picks the best address for
each connection type, and I am a little vague on what actually
happens. What my backbrain (but not RFC 3484 - is there a later rfc
for what gai.conf should do?)
With ordinary next-hop routing, routing policy is entirely in
Sounds interesting. In the ideal world, that would be a pluggable
policy algorithm. Lowest RTT may not always be the best choice.
It is, in our particular context. That's the nice thing about working at
the application layer -- you are the application, so you have a pretty
good idea of what
You might also need to combine the features of the gateway with the
metric(s) of the path to the gateway.
I do end-to-end measurements in my mosh implementation, so we should
not have the problem.
Does this really scale well?
How well do we need it to scale? Three addresses per host? A
Probe results should probably [be] interpreted per-prefix not per-address.
Hmm. Interesting idea.
I can imagine some scenarios where it could break -- Ethernet bridged with
Wifi (OpenWRT style), mesh networks, or simply a congested, bufferbloated
interface. I'm not sure how common such
I can imagine some scenarios where it could break -- Ethernet bridged with
Wifi (OpenWRT style),
If you have two hosts connected to an OpenWRT router, one over Wifi and
one over Ethernet, they could have very different performance
characteristics while being on the same prefix.
expound?
- create one of more additional software loopback interfaces that are
always up and used as source and destination for binding for all
(legacy) apps.
- a software interface would have one single /64 prefix from each
delegated Homenet prefix, reducing the number of potential sources and
If people want to choose babel because it works well facing adverse radio
conditions in a mesh-networking environment (that I know nothing about),
I think this is misrepresenting the argument somewhat.
We want a routing protocol that works well in an unadministered network
that consists of a
A marginal link is simply one that has a measurable amount of packet loss.
Ok, re-reading this exchange, it looks like I may have wrongly assumed
that people are aware of background. I'll need to put that into the
routing comparison document, this is as good a place as any to draft my
text.
There is also the really bad case of wifi links without packet loss
which are stable at 6 Mbit/s... stable but incredible slow.
If you have a combination of two 450 Mbit/s links you can use instead,
you want to do it...
Absolutely. Just to clarify -- Henning is referring to the modulation
Also, currently most routers consists of mostly L2 high speed forwarding,
with some L3 thrown in between two ports (the WAN port, and the 5th
internal port to the 5 port switch chip with 4 external ports). With
homenet, all this changes. Now all ports need to be L3.
I'm possibly missing
Well, ethernet runs at different speeds and there is no abstraction
for that in babel...
Why not?
Switches.
Most home routers have their (on-chip) Ethernet interface behind an
internal switch. That is how they provide 5 or more Ethernet ports using
a single-NIC SoC.
That has the
HNCP contains the same thing as a link-state protocol to find out
topology. HNCP could theoretically use the ISIS topology instead of its
own, but it couldn't rely on Babel to do the same job, right?
Correct.
-- Juliusz
___
homenet mailing list
Just the fact that you need src/dst routing means most current
mid/higher end hardware won't work at all (or will require significant
microcode update to work).
I'd like to point out that one of the conclusions of the work of Matthieu
is that source-specific routing can be easily implemented
If ISIS is chosen, I am sure we'll see additional implementations of this
in C or similar programming language. I know some rudimentary
implementations in Python as well, that people wrote in very little time.
The Python implementation I'm aware of is not just rudimentary, it's not
done (as in
I think it would be equally interesting to see a specification of that
homenet-variant/subset of IS-IS. The comparison draft is very vague on
that front
You mean what the TLVs look like exactly for the src/dst extensions to
ISIS?
No, I don't think that's what Steve means.
Sections 12 and
For Babel I can read: RFC 6126 and draft-boutier-babel-source-specific
about 50-60 pages and that seems to be it.
What's the equivalent of that for the homenet IS-IS variant?
Check. In the meantime, could we get confirmation that your above that
seems to be it assumption is true for babel?
create blackholes; IS-IS will collapse during reconvergence;
Collapse?
Okay. I'll reformulate that.
I am not aware of any results in the open litterature that describe the
behaviour of single-area IS-IS during reconvergence.
I am not aware of any results in the open litterature that
I also think there should also be more explicit links back into the
Homenet Architecture document
[...]
Perhaps a table with complies does not comply or partially complies
per paragraph or phrase?
Good point. Here's a quick reading of Section 3.5 of RFC 7368:
- border discovery: out of
Please find the new version of the Outsourcing Home Network Authoritative
Naming Service.
We believed we addressed all comments we received through the list and off
list.
I'm a little confused. One of the comments was about how the draft binds
the role of the authoritative hidden master to
- Babel will avoid creating loops even when reconverging, but might
create blackholes; IS-IS will collapse during reconvergence;
I would say the IS-IS will create micro-loops and blackholes during
reconvergence. I wouldn¹t say it would ³collapse². Note that these issues
have been addressed
I'd also be interested in reading about the practicality of my smartphone
being able to participate as a (stub) Homenet router.
Babel has been ported to Android, but most of the Android work is being
done with OLSR, notably within the Commotion Wireless project.
Basically a device has been sold with a certain amount of features, and
this featureset hasn't changed over time, thus there is no need to
future-proof. I see this changing.
What are the indicators you see ?
I suspect that the two of you may be making different assumptions. Mikael
is
Actually one might even argue in the opposite direction that unless the
IGP offers some fancy dynamic metrics based on e.g. bandwidth or
reliablity etc., what would be the point of combining HNCP with
a single-area LSP if you might as well do a simple graph traversal on the
HNCP topology to
I'm possibly missing something, but I see no requirement to perform L3
routing between the LAN ports.
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.
Ah, I see.
I was focusing on avoiding
Babel solves this particular issue by a combination of three mechanisms:
(1) automatically assigning a high metric to a marginal link, (2) using
How is a marginal link defined/detected?
The current implementation uses ETX (MobiCom 2003), which is not very good
but relatively easy to implement
smart rate limiting.
ISIS already has these kinds of rate-limiting of how things are
happening. In modern core routers this is often tuned
If you need to tune it, it's not smart enough.
-- Juliusz
___
homenet mailing list
homenet@ietf.org
Seems like ³marginal link² is associated with the IGP behavior
No. A marginal link is simply one that has a measurable amount of packet
loss.
On a properly functioning wired network, you don't have any marginal
links: a link is either up or down, and a link that is up has negligible
amount of
Babel has an open mailing list, and has been made aware of Margaret's draft.
If you want to jump in and ask any questions there, of course feel free:
babel-us...@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/babel-users
Working with Chris Hopps and Juliusz Chroboczek, Margaret just posted
draft-mrw-homenet-rtg-comparison-01.txt.
This is on
https://tools.ietf.org/html/draft-mrw-homenet-rtg-comparison
As Mark mentioned, we didn't attempt to reach consensus with this
document -- we tried to produce
wrt. Algorithm Comparison
Loop-Avoiding Distance Vector [...] scales badly in extremely dense
deployments, where a single node has thousands of direct neighbours
Are thousands of direct neighbors relevant for the homenet usecase?
It's not relevant to any reasonable use case. There is no
The sections in the document started from a list of routing
features/properties that were discussed in the WG meeting. There was
quite a bit of discussion of scaling. In particular, there was a lot of
discussion of how these protocols will scale on Wi-Fi.
Performance and scaling on WiFi is
I'd be a bit curious to know what people are using for test hardware.
The WNDR3800/WNDR3700v2 is still my favourite. I've still got a couple
Asus 500GP v1, and they're just fine if you don't need 802.11n and can
fit in the slightly more limited flash.
Both models:
- are well supported by
If HNCP renumbers on a partition, then existing TCP connections would
drop.
Numbering the loopback avoids this. Also there is the solution used
in the 1990s by ISPs which you trimmed from my email, but requires
installing host routes.
I've trimmed it because I fully agree with it:
While
But now I don't see what's to stop a home user from buying a more
general-purpose router which happens to have a ZigBee port or something,
and plugging it in such a way that it *should* behave as a stub router.
How does it discover that and configure itself accordingly?
Disclaimer: I know
Another topic comes to mind. The topic is the partitioned bridged
network.
The first situation was informally described by R. Tomlinson as
a network partitioning problem in which a particular host, H in
network N, is reachable from one gateway attached to network N but not
Brian, ever the pessimist, expects things to go wrong whenever they
can. I happen to agree with Brian.
(Which, by the way, is the reason why I think that the way networks
containing both IS-IS and Homenet IS-IS will silently break is a major
f*ck up. Section 6.3. Yeah, I was too tired to
Or more generally, how does a stub router know that it's a stub router,
when there is no human to tell it so?
Yeah, it's not very clear. We were actually asked to describe the two
protocols' support for stub networks, and nobody never told us which of
the many definitions of stub network they
I think that you and Mikael expect that the ZigBee link will be designated
as stub, while Brian, ever the pessimist, expects things to go wrong
whenever they can. I happen to agree with Brian.
We can't prevent people from doing stupid things, but we can at least
give good advice.
I think
Homenet --- A -- B
||
||
C .. D
(ZigBee)
Why would you even autoconfigure a route at all between C and D?
I think that you and Mikael expect that the ZigBee link will be designated
as stub, while Brian, ever the pessimist, expects things to go wrong
whenever they
At todays meeting, the claim was made (at least twice) that adding
dynamically computed metrics to IS-IS is just a feature. I strongly
disagree with this assessment -- it's an open research problem, and
a difficult one at that.
I don't think it is likely to be a lot of work, though,
As far
Next item on my list of incorrect claims having been made this morning --
lend me your ears.
Somebody mentioned at the mic that some mesh routing protocols do not work
well on ordinary wired links. While this statement is vague enough to be
correct, the implication that this applies to Babel is
Evan,
If there were a solid specification
I'm a little confused about that. I have put a lot of care into RFC 6126,
and I've tried to make it as clear as possible. Looking at it with four
years' hindsight, there's little in it that I would write differently today.
It would be extremely
Before we lose this, let it be noted that we seemed to have arrived at
no for an answer to whether we want to deal with non-transitive
networks, *as part of this particular routing protocol discussion*.
This is what the protocol comparison draft has to say on the subject:
We believe that
It would be extremely helpful if you could take the time to explain to me
what it is exactly that you found confusing in RFC 6126.
I was not speaking for myself, but reflecting the statements made at the
working group meeting
I see, thanks for your answer.
-- Juliusz
The yak we are shaving here, is whether two inter-operable implementations
leveraging the same mit-licensed source code base (as in the base babeld
daemon and the quagga implementation) are acceptable to this wg.
Dave,
Alia is right -- there do not at the current time exist two independent
After a first read, it looks like a pretty complete implementation of
RFC 6126. I have't checked in detail, but it looks like you got both the
loop avoidance and the blackhole avoidance mechanisms right. You're also
doing bidirectional reachability detection and fairly reasonable route
Admittedly that is not really valid in terms of RFC6126 (strictly
interpreted), but I am intentionally maintaining separate set of selected
and full routes.
That's perfectly valid.
The data model in RFC 6126 is conceptual, and while it describes the set
of routes as a single set with a
Link quality estimation is in the informative appendix A.2.2.
This is more than a little bit problematic if we want router vendors to
be able to produce useful implementations: they generally are not
interested in doing research, and just ship whatever firmware their wifi
chip vendor tells
A stronger approach will be to consider combining the Layer 3 routing
protocol with the L2 IEEE 802.1Qca which provide SPB on multiple paths
(editor: janos.far...@ericsson.com).
Sorry if dumb question -- but since Qca appears to depend on SPB, could
you please clarify what is the relationship
My (perhaps mistaken) feeling is that whenever I mention an important
feature of Babel, there's a chorus of that could be done in IS-IS, we
just haven't done it yet. I've tried to explain that many of the
things that Babel is doing are difficult or outright impossible in IS-IS
it should be
As I said in the meeting, my concern is not because of the process
requirements - but because of the experience and improvements found during
the standardization and interoperability process.
This makes sense, and I'm quite open to discussing that in Prague.
However, I'd like to attract your
1 - 100 of 553 matches
Mail list logo
