Dear all,
In order to get the extension protocol published, I need to define
a policy for allocating TLV numbers. The reviewer has suggested
First-Come-First-Served with public reference, but is also willing to
accept plain FCFS. IANA allocation policies are defined in RFC 5226:
SS Update
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 13 |Length | AE | Flags |
If the Flags field contains any flags, then the resulting parser state
will be different for original and source-specific implementations. This
will break interoperability.
Yes, there is a problem with the compression mechanism for the destination
prefix. The solutions are:
- no
- no compression,
What I'm suggesting is a little weaker. There's still compression, but
only non-specific updates can set the prefix. (It shouldn't matter much
in practice, though, I expect most SS-updates to be for the default
route.)
Not sure what to do about compression for source
What I'm suggesting is a little weaker. There's still compression, but
only non-specific updates can set the prefix. (It shouldn't matter much
in practice, though, I expect most SS-updates to be for the default
route.)
Not sure what to do about compression for source prefixes.
After
I do not mind if you break backward wire compatibility against
existing versions of babels, but do it soon, please, and warn people.
My users are
pretty tolerant of breakage, so long as they are warned
I would not mind a shim of some sort protecting against older babels's
format and newer...
switching to a new TLV number for the newer flag-less format and sending
warnings for receipt of the old (old style babels packet received,
please update babel on that machine) seems most comforting to me.
I feel your pain, Dave, but that's something that I have to take a firm
stand about, or
On Tue, Jul 1, 2014 at 11:20 AM, Juliusz Chroboczek
j...@pps.univ-paris-diderot.fr wrote:
switching to a new TLV number for the newer flag-less format and sending
warnings for receipt of the old (old style babels packet received,
please update babel on that machine) seems most comforting to me.
(I am concerned about mis-parsing stuff),
Don't worry too much, it's bad for your complexion. This is a distance
vector protocol, if we mis-parse something, you'll get an extra route in
your routing table, which will timeout within seconds.
A more serious potential problem is that when Babel
On Jul 1, 2014 3:31 PM, Juliusz Chroboczek j...@pps.univ-paris-diderot.fr
wrote:
(I am concerned about mis-parsing stuff),
Don't worry too much, it's bad for your complexion. This is a distance
vector protocol, if we mis-parse something, you'll get an extra route in
your routing table,
Hi,
I've put a very early draft of the Babel-RTT Internet-Draft (a draft of
a draft... what's the world coming to) on:
http://www.pps.univ-paris-diderot.fr/~jch/software/babel/draft-jonglez-chroboczek-babel-rtt-extension.html
Nits, flames, insults, all are welcome.
-- Juliusz
So I finally got my act together, and documented Babel-Z3:
http://www.pps.univ-paris-diderot.fr/~jch/software/babel/draft-chroboczek-babel-diversity-routing.html
It needs some more work, I think, but it should be fairly readable in the
current state.
-- Juliusz
speaking only for myself, I'd be happier if the latest batch of IDs
were all rolled into one.
I find myself asking questions about how z3 and rtt are supposed to coexist,
in the intersection of these documents.
On the other hand, as bite-size morsels they are quite easy to
digest, and perhaps
Hi,
Today was Canada Day, and I spent the morning in the basement flashing the
latest CeroWRT on the set of NetGear 3800s that I bought back in March of
2013. (My, how time flies)
My plan has been to setup a community mesh network as an experiment, to try
Babel on it, and later on try out RPL.
14 matches
Mail list logo
