Subject: [babel] Unicast Hellos

From: Juliusz Chroboczek <[email-masked]>
Date: Mon, 03 Apr 2017 03:50:13 -0500

Dear all,

[This message is crossposted between both mailing lists, followups to
babel@ietf, please.]

I think there are at least four people interested in making a unicast-only
version of Babel, and that requires adding support to the protocol for
sending Hellos over unicast.  We had a discussion on this subject with
David Schinazi on Friday, let's please continue on the list.

Background
==========

Babel was designed so that the choice between sending a given TLV over
unicast or multicast is purely an implementation decision: all TLVs can be
sent over either, and have exactly the same meaning whether they are sent
over unicast or multicast.  There is however one limitation to that:
Hellos carry a per-interface sequence number, and unless they are sent to
all neighbours on a given interface, the seqnos will get out of synch.
More on that below.

At the time, it didn't seem important to be able to send unicast Hellos.
After all, Hellos are used for both neighbour discovery and neighbourship
maintenance, and discovery can only happen over multicast.  However, once
a neighbour has been discovered (either through multicast Hellos or
through means exterior to the protocol), then unicast Hellos can be used
to maintain the neighbour relationship.

People have found good reasons to use unicast for Hellos:

  1. Toke and Dave have a passionate hatred of multicast, and want to
     avoid it whenever possible;
  2. others want to protect Babel with DTLS or IPSec, and these protocols
     only work for unicast;
  3. Margaret is using Babel over a non-broadcast network, where multicast
     is not supported at all.

All of these are legitimate applications, and as I mentioned in Chicago,
it would be a terrible wasted opportunity if we didn't get unicast Hellos
into the spec in time for Prague.

The issue
=========

Every Hello contains two pieces of information: the Interval, a 16-bit
number of centiseconds (ranging from 10ms to 11 minutes), and a 16-bit
Seqno, which is an integer modulo 2^16.  The Interval is a promise to send
another Hello within a given time; babeld uses it to derive a hold time
(3*Interval, if memory serves).  The Seqno is incremented with each Hello,
and allows for reliable accounting of packet loss.

A Babel speaker maintains a single Hello Seqno per interface, which is
incremented whenever a (multicast) Hello is sent.  If a Hello is sent over
multicast to a single neighbour, the expected Seqno will become
desynchronised between the various neighbours, which will cause spurious
detection of packet loss.

A Hello also carries a 16-bit Reserved field, which currently must be zero
on transmission, and is silently ignored on reception.  David suggests
that this field could be repurposed as a flags field.

Possible solutions
==================

It is my opinion that it is allowable to add an incompatible extension as
long as it does not break existing networks and does not require a flag
day.  If a unicast-only speaker fails to establish an adjacency with
a legacy speaker, that's fine with me, as long as it does not break the
rest of the network.  Given that constraint, David and I see the following
ways to add unicast Hellos.

Allow unicast, no other protocol changes
****************************************

Margaret suggests that we should allow unicast Hellos, but require that
the same number of Hellos be sent to all neighbours on a given interface.
In other words, whenever a Hello is sent, it is either sent over
multicast, or the same Hello is sent to all neighbours over unicast.

This is tempting, since it doesn't require any changes to the protocol,
just minor editorial changes.  While it meets Margaret's use case, it
might not be flexible enough for all the uses of unicast Hellos.  I also
dislike the fact that the receiver cannot distinguish unicast from
multicast without checking the destination address -- this would be the
only place in the protocol where the destination address is needed.

Make the Hello counter per-neighbour
************************************

No protocol changes, just require that the Hello counter be per-neighbour.
This means that an implementation must either send all Hellos over
multicast, so all per-neighbour counters are equal, or all Hellos over
unicast.  Once a Hello has been sent over unicast and the counters have
become unsynchronised, it is impossible to send a Hello over multicast.

This is not acceptable to me, since sending Hellos over multicast is the
only in-band way to perform neighbour discovery.

Two kinds of Hellos, distinguished using a flag
***********************************************

David suggests that we have two Seqno counters: a per-interface and
a per-neighbour counter.  The two kinds of counters run independently.
A flag in the Hello packet's Reserved field serves to distinguish the two.

This is simple, elegant, and require few protocol changes.  Unfortunately,
legacy implementations that don't parse the Reserved field will get
confused, and spuriously tear down neighbour associations when they see
discontinuities in the seqno.  However, no flag day is necessary: we first
deploy implementations that understand the Reserved field, but don't send
any unicast Hellos.  At a later date, when legacy implementations have
disappeared, we start sending unicast Hellos.

This is currently my preferred solution.

Two kinds of Hellos, using different TLV types
**********************************************

My suggestion was to have two Seqno counters, just like in David's
proposal, but use a new TLV number for Unicast hellos.  This avoids the
compatibility issue -- unicast Hellos will be ignored by legacy
implementations, so unless an implementation periodically sends multicast
Hellos, it will be ignored by legacy implementations.

This used to be my preferred solution.  David has convinced me to use
a flag, but I'm willing to reconsider.

Use empty packets
*****************

Russ suggested that we interpret every Babel packet as a Hello.  This way,
sending an empty packet (just the packet header) will play the role of
a Hello.  This has two significant flaws:

  - there is no seqno or interval in the Babel header;
  - there is no way to attach a sub-TLV to an empty packet, most notably
    a timestamp.

This is not acceptable to me.

Something else?
***************

Other ideas?

Other issues
============

What does Interval mean?
************************

Currently, the Interval field of a (multicast) Hello is a promise to send
another (multicast) Hello within the given time.  If we switch to having
two kinds of Hello, what does Interval mean?  Is it a promise to send any
kind of Hello in the given interval, or a promise to send the same kind of
Hello within the given interval.  The former makes more sense to me, but
I'm willing to be convinced otherwise.

How is link quality estimated?
******************************

Most implementations of Babel use Hello history to derive a link quality
for each neighbourship association; this is described in Appendix A of
RFC 6126.  How is link quality computed in the presence of two kinds of
Hellos?  Please consider that at least in 802.11, unicast is protected by
ARQ while multicast isn't.

---

From: David Schinazi <[email-masked]>
Date: Mon, 03 Apr 2017 10:11:46 -0700

Hi Juliusz, thanks for writing this up!

I agree with your problem statement and preferred solution using a flag,
and I like the 2-step deployment plan. It has the advantage that
further down the road we won't have to explain to our grandchildren
why we have a separate TLV for unicast Hellos.

I can volunteer to write draft text towards adding this to the document,
if there is consensus on the list.

Thanks,
David

> On Apr 3, 2017, at 01:50, Juliusz Chroboczek <[email-masked]> wrote:
> 
> Dear all,
> 
> _______________________________________________
> Babel-users mailing list
> [email-masked]
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users

---

From: Dave Taht <[email-masked]>
Date: Mon, 3 Apr 2017 10:39:13 -0700

On Mon, Apr 3, 2017 at 1:50 AM, Juliusz Chroboczek <[email-masked]> wrote:
> maintenance, and discovery can only happen over multicast.

In the case of a p2p tunnel I could see explicitly identifying each end, thus
eliminating the need to use multicast for discovery.

> However, once

Well, I do hope we get around to making at least one wifi chipset
queue and drop multicast more sanely sometime this year.

>   2. others want to protect Babel with DTLS or IPSec, and these protocols

I would like to be able to run babel over wireguard one day, as it evolves.

> that this field could be repurposed as a flags field.

I hope nobody has flag days as difficult as mine, which involve
climbing a lot of trees!

> Two kinds of Hellos, using different TLV types

I lean towards a new unicast type, but can probably be convinced otherwise.

> Use empty packets

To me, this is the bigger problem, in general. the quantity of control
traffic is very sparse and thus difficult to get a more reliable
signal out of. In the case of unicast and ARQ, we don't (generally)
get any packet loss at all, just delay, except in the case where the
network has completely severed connectivity.

You elided the rtt estimation extension from the above discussion, and
I tend to think that that is part of a way out, and must be part of
the unicast hello.

There are other options regarding transfers that might provide more
"signal" as to the quality of the link - notably doing a unicast route
transfer and  observing how long it took, (or observing this more
generally by periodically sending another message and asking for a
response).

or (in the known unreliable cases) asking the receiver how many routes
it got via multicast vs how many were sent. I kind of like bits of
this latter option, a router advertising that it "had default routes"
or "had lots of routes", but it's way outside the current scope of the
protocol.

> babel mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/babel

-- 
Dave Täht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org

---

From: Dave Taht <[email-masked]>
Date: Mon, 3 Apr 2017 10:58:56 -0700

> Make the Hello counter per-neighbour

There is another possibility here. On startup both unicast and
multicast hellos are sent with the same seqno (what does babel do
presently with duplicate packets?). If a unicast IHU comes in
response, the receiver has proven itself capable of taking unicast
hello.

If all the connections on that interface prove unicast capable, we
switch to unicast consistently throughout that interface, otherwise we
stick with multicast.

(I don't regard the overhead of checking the dest address inside the
hello routine as all that much)

---

From: Juliusz Chroboczek <[email-masked]>
Date: Tue, 04 Apr 2017 01:37:11 +0200

> I tend to think that that is part of a way out, and must be part of

Of course, we want any sub-RTT of Hello to apply to unicast Hello.  This
applies to the RTT extension, and hence makes it possible to use
unicast Hello, unicast IHU, and RTT all in the same packet.

This happens automatically if unicast Hello is just a variant of Hello.
If there's a new TLV, it requires just a minor update to the RTT extension.

-- Juliusz

---

From: Juliusz Chroboczek <[email-masked]>
Date: Tue, 04 Apr 2017 01:38:16 +0200

> if there is consensus on the list.

Noted, thanks.  But let's have an implementation first.

-- Juliusz

---

From: Juliusz Chroboczek <[email-masked]>
Date: Tue, 04 Apr 2017 04:14:54 +0200

> response, the receiver has proven itself capable of taking unicast

Babel doesn't currently do negotiation: every Babel TLV is designed so
that it can be silently ignored if it is not understood.  I'm rather keen
on it staying that way.

If there is consensus that negotiation is the way to go for unicast Hellos,
then we should rename the Reserved field of Hello to "Capabilities".  Or
add a new Capabilities sub-TLV, but at any rate make the negotiation
explicit.

> hello routine as all that much)

No, it's not a lot of work, but it makes Babel dependent on yet another
API which might or might not be available on your platform.  For the
record, here's what it looks like for Sockets:

  https://github.com/jech/shncpd/blob/master/shncpd.c#L666

-- Juliusz

---

From: David Schinazi <[email-masked]>
Date: Mon, 03 Apr 2017 19:20:20 -0700

I'd rather keep Babel free of capability negotiation if we can,
and unicast hellos can be safely deployed without them.

David

> On Apr 3, 2017, at 19:14, Juliusz Chroboczek <[email-masked]> wrote:
>

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Tue, 04 Apr 2017 12:04:25 +0200

David Schinazi <[email-masked]> writes:

> I agree with your problem statement and preferred solution using a
> flag, and I like the 2-step deployment plan. It has the advantage that

I like the "two different types of Hellos" approach; I think a flag is
probably the simpler approach, but don't have strong opinions either
way.

-Toke

---

From: james woodyatt <[email-masked]>
Date: Tue, 4 Apr 2017 17:30:08 -0700

> Something else?

I want to explore the idea of finding the minimum possible change to the protocol to make the necessary refinement and still permit multicast Hello for in-band neighbor acquisition.

Without any changes to the protocol, I’m not sure it’s strictly true that it’s impossible to multicast a Hello after unicasting with different intervals and desynchronized Hello seqno progressions to two or more different neighbours. Yes, the reverse reachability detection logic says that when a Babel speaker receives a Hello, when it can determine that a previous Hello seqno was not received, it recomputes the association cost and recommences the route selection procedure. Accordingly, it could be prohibitively costly to force a discontinuity in the Hello seqno at every periodic multicast in any system where, except for neighbor acquisition, speakers normally send only unicast Hello messages, so judiciously redefining the 16-bit reserved field in the Hello message to help with that problem may be warranted.

One approach is to define a (D)ISCONTINUITY flag for use only in unicast Hello messages, which a Babel speaker would use to signal to its neighbours that a Hello seqno discontinuity SHOULD be expected in processing this message, therefore recomputing the association cost and recommencing the route selection procedure is NOT RECOMMENDED. Instead neighbours would update their history information in the Neighbor Table entry for the speaker to disregard the discontinuity and make no adjustment to the rxcost.

Babel speakers that can send both unicast and multicast Hello messages would immediately precede every multicast (interval=T, seqno=N) by unicasting (D=1, interval=T, seqno=N-1) to each neighbour that was most previously unicast a Hello other than (seqno=N-1). Speakers SHOULD choose N to minimize the number of independent unicasts preceding a multicast. The interval MUST be the same in all the unicasts and the multicast, so every neighbour will store the correct interval value in their Neighbour Table for use in recomputing the association cost, which happens for each neighbour as one of three possible cases: 1) the unicast message with (D=1, seqno=N-1) is lost and the multicast (D=0, seqno=N) is received and N is recognized as discontinuous, adjusting rxcost to account for the loss of one unicast Hello packet, 2) the multicast message with (D=0, seqno=N) is lost, the unicast (D=0, seqno=N+1) in the succeeding message is received, and N+1 is then recognized as discontinuous, adjusting rxcost to account for the loss of one multicast Hello packet, or 3) both unicast and multicast messages are lost, in which case the discontinuity will be recognized and rxcost adjusted by at least two messages (except in the rare case that the most recently sent Hello seqno for the neighbor is N, when the next delivered unicast will be seqno=N+1, and no adjustment to rxcost will be made, despite the loss of two packets).

In any Babel system where unicast or multicast are used exclusively, no Hello messages need the D=1 signal. In any Babel system with two or fewer speakers, no Hello messages need the D=1 signal. In any Babel system where every speaker sends the same number Hello messages to every neighbour it acquires, no Hello messages need the D=1 signal. The D=1 signal is only required in a Babel system where 1) a speaker has two or more neighbours, 2) it unicasts Hello to two or more of them with different interval and Hello seqno progressions, then 3) it later needs to multicast a Hello without forcing all but one of the neighbors to recompute their association costs and recommence their route selection procedure.

Admittedly, I haven’t yet implemented my own Babel speaker, so I’m not sure this idea is well-formed. I think this proposal works even in the case where no multicast is used at all and neighbour discovery proceeds out of band.

--james woodyatt <[email-masked] <mailto:[email-masked]>>

---

From: David Schinazi <[email-masked]>
Date: Wed, 05 Apr 2017 21:50:02 -0700

Hi James,

I'm not sure this will work, especially if a speaker sends unicast and multicast at similar frequencies.
Having two seqno counters is simpler, and allows speakers to know the drop rate on both unicast and multicast.
I'm also not sure your proposal is a smaller change to the protocol.

David

> On Apr 4, 2017, at 17:30, james woodyatt <[email-masked]> wrote:
> 
> On Apr 3, 2017, at 01:50, Juliusz Chroboczek <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Something else?
>> ***************
>> 
>> Other ideas?
>

---

From: james woodyatt <[email-masked]>
Date: Thu, 6 Apr 2017 11:26:34 -0700

> I'm not sure this will work, especially if a speaker sends unicast and multicast at similar frequencies.

I thought pretty hard about that problem, and I don’t think I see why it shouldn’t work. Please elaborate.

> I'm also not sure your proposal is a smaller change to the protocol.

So I tried pretty hard to keep from having to make major changes to the data structures in section 3.2. In particular, this is why I didn’t propose adding flags to the IHU message to invite neighbours to send unicasts potentially with D=1. I wanted to be confident that existing implementations could receive unicast Hello messages and everything would still work despite them ignoring the D=1 signal. I agree that it would be nice for Babel speakers to have two separate rxcost metrics, one for unicast and another for multicast, but it doesn’t right now, and I thought proposals to add that would be too much of a departure. Even proposing to change the structure of the Neighbour Table entry to add a second type of Hello seqno seemed like a big change with serous interoperability considerations.

Can you be more specific about what you think my proposal will break?

---

From: Markus Stenberg <[email-masked]>
Date: Fri, 7 Apr 2017 00:49:46 +0300

On 3 Apr 2017, at 11.50, Juliusz Chroboczek <[email-masked]> wrote:
> a flag, but I’m willing to reconsider.

In general having both unicast and multicast hellos seems worthwhile just to estimate both types of payloads’ characteristics on the link. 

This is my preference of the listed options. Flag based correct behavior feels bit dangerous.

I am not sure I am entirely happy with any of the listed options though. I have considered slightly different scheme treating unicast and multicast as separate logical links for hello purposes (=> disjoint sequence number spaces) but that leads to issues in mixed environments with both legacy implementations and ones supporting unicast hello spec. If writing v2 version of protocol without backwards compatibility requirements, I would probably lean that way (on the wire, hellos would look same, but sequence # spaces would work bit differently based on uni<>multicast).

Cheers,

-Markus

---

From: Juliusz Chroboczek <[email-masked]>
Date: Fri, 07 Apr 2017 03:20:54 +0200

Yeah, unicast Hellos are surprisingly tricky -- I thought about them when
I initially designed Babel, and decided they're not worth the complexity.
Unfortunately I was wrong.

> shouldn’t work. Please elaborate.

If the sender alternates unicast/multicast, then every single packet will
be discontinuous, in effect making seqnos useless.  This is similar to
a proposal I had, which consisted in removing the seqno from Hellos
altogether.

I'm also worried about what happens if the D=1 indication is lost.

>     rate on both unicast and multicast.

For the sender, no changes are needed -- it remains perfectly legal to
never send a unicast Hello.  If a peer wants to send Unicast Hellos, it
must maintain, in addition to the global Seqno, a per-peer Seqno.

The receiver, on the other hand, must maintain some form of unicast Hello
history, in addition to the current multicast history.  What I'm planning
to do in the reference implementation is the following:

  - for wired links, 2/3 link sensing for both multicast and unicast, an
    association is up if either is good;
  - for wifi links, ETX for multicast and 2/3 for unicast, if ETX yields
    infinity but 2/3 is good, assume an abysmally bad but usable link.

I don't think the extra complexity is prohibitive.

>     I'm also not sure your proposal is a smaller change to the protocol.

It is a smaller change since it requires no new data structures.  However,
I don't think the extra complexity of having an extra history is prohibitive.

-- Juliusz

---

From: Juliusz Chroboczek <[email-masked]>
Date: Fri, 07 Apr 2017 03:25:54 +0200

> This is my preference of the listed options. Flag based correct behavior

Can you clarify please?

> I am not sure I am entirely happy with any of the listed options
> though. I have considered slightly different scheme treating unicast and
> multicast as separate logical links for hello purposes (=> disjoint
> sequence number spaces) but that leads to issues in mixed environments
> with both legacy implementations and ones supporting unicast hello
> spec.

I think the plan is to have disjoint seqno spaces.  What else do you
envision?

> If writing v2 version of protocol without backwards compatibility
> requirements, I would probably lean that way (on the wire, hellos would
> look same, but sequence # spaces would work bit differently based on
> uni<>multicast).

Could you please clarify?

By using a different TLV, a unicast-unaware node will simply fail to route
through a unicast-only node.

If using a flag, a unicast unaware node will have completely crazy link
cost, which means that it will not route through a unicast-sending cost.

Since sending unicast remains optional, I don't think either compatibility
issue is prohibitive -- our implementations just refrain from sending
unicasts by default for a couple of years.

-- Juliusz

---

From: Markus Stenberg <[email-masked]>
Date: Fri, 7 Apr 2017 08:51:47 +0300

>> This is my preference of the listed options. Flag based correct behavior

Well, given default in RFC6126 is ignore, backwards compatibility with that means that the flag is ignored by those nodes. What are we exactly getting out of sending the flag only to the ’new, enlightened’ peers? Anything not already embedded in the IP header?

> I think the plan is to have disjoint seqno spaces.  What else do you

If we can enable the functionality only with new peers present, there is no value in the flag itself as currently the unicast+hello is not currently specified and if we assume all new implementations, they can just note it’s unicast and move on with that. 

-> having bit OR TLV is redundant _if_ you are willing to live with the anomalies you note.

The bit leads to same anomalies (legacy receiver not understanding the bit will misbehave). TLV does not.

> unicasts by default for a couple of years.

For disjoint seqno spaces, I see 3 options:

- TLV on the wire
- reserved bit on the wire
- detect by dst (no encoding change in payload)

In terms of ‘legacy’ compatibility, bit-in-reserved and detect-by-dst are equivalent. I am not fond of the anomalies involved with it, but I assume you are willing to live with it if your current favourite option is the reserved bit one.  ‘jurassic socket APIs’ is valid concern but I think anything modern has to have way of getting datagram destination address, as e.g. DTLS does not work without it.

Cheers,

-Markus

---

From: David Schinazi <[email-masked]>
Date: Fri, 07 Apr 2017 09:09:54 -0700

I agree that reserved bit is equivalent to checking dst address.
My implementation checks the address so it can live with both,
but I don't mind burning one bit of the 16 we have if it makes
some other implementer's life easier.

David

> On Apr 6, 2017, at 22:51, Markus Stenberg <[email-masked]> wrote:
> 
> On 7 Apr 2017, at 4.25, Juliusz Chroboczek <[email-masked] <mailto:[email-masked]>> wrote:
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/babel <https://www.ietf.org/mailman/listinfo/babel>

---

From: james woodyatt <[email-masked]>
Date: Fri, 7 Apr 2017 14:54:20 -0700

> Unfortunately I was wrong.

It was good of you to try.

> be discontinuous, in effect making seqnos useless.

Only at Babel speakers that are ignoring the D=1 flag, which is designed to allow retaining the utility of the Hello seqno by marking the ones that are intentionally discontinuous.

> This is similar to

The same thing that happens at legacy Babel speakers that ignore the D=1 indication. They see the discontinuity as a signal to recompute the association cost and recommence the route selection procedure.

> […]

I don’t either, but in a constrained node [RFC 7228], the extra unicast history present in every Neighbour Table entry will carry some cost in additional RAM. Not prohibitive, but significant.

> I don't think the extra complexity of having an extra history is prohibitive.

I’m glad I was able to offer an alternative for comparison. Always good to have multiple options on the table from which to choose.

---

From: Juliusz Chroboczek <[email-masked]>
Date: Sat, 08 Apr 2017 00:16:52 +0200

> Only at Babel speakers that are ignoring the D=1 flag, which is designed to
> allow retaining the utility of the Hello seqno by marking the ones that are
> intentionally discontinuous.

I'm a little confused.  If the sender alternates M/U, then every Hello
will carry D=1, right?  So the receiver cannot use any of the sequence
numbers, right?

> The same thing that happens at legacy Babel speakers that ignore the D=1
> indication. They see the discontinuity as a signal to recompute the association
> cost and recommence the route selection procedure.

Right.

> I don’t either, but in a constrained node [RFC 7228], the extra unicast history
> present in every Neighbour Table entry will carry some cost in additional RAM.

That's 2 bytes per neighbour.

(James, if you're working on Babel for constrained nodes, and are allowed
to tell me about it, then I'd really like to hear about the hardware
you're considering -- amount of RAM, kind of CPU, etc.)

-- Juliusz

---

From: Juliusz Chroboczek <[email-masked]>
Date: Sat, 08 Apr 2017 00:19:34 +0200

> That's 2 bytes per neighbour.

Er, 8.  (2 byte expected seqno, 16 bit hello history, 4 byte timestamp.)

---

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 12 Apr 2017 00:16:28 +0200

> Then put the corresponding Hello TLV where you want.  For compatibility
> purposes, you should send a unicast Hello with the Multicast Hello
> Interval sub-TLV attached.  Use the last Interval value used in
> a (really) multicast Hello as Interval.

> The two reserved bytes of the legacy Hello will just cover the type and
> length of the multicast TLV.  A legacy implementation will see nothing
> but a just well formed legacy 8-bytes-Hello TLV.

Way too clever, Matthieu, and I don't see what problem it solves -- it has
just the same compatibility issues as David's proposal, while creating
a much more complex encoding.

I'm also at a loss how to specify that.  How should a node react to
a Hello TLV with no sub-TLV?  If the intent is that the proposed Hello TLV
MUST be accompanied with exactly one of the two proposed sub-TLVs, then
this is the first time that we'll define a mandatory sub-TLV in Babel.

Unless it actually solves a real problem, I'd rather we avoid this kind of
complexity.

-- Juliusz

---

From: David Schinazi <[email-masked]>
Date: Tue, 11 Apr 2017 18:16:46 -0700

I agree with Juliusz, the same result can be achieved with less complexity.

David

> On Apr 11, 2017, at 15:16, Juliusz Chroboczek <[email-masked]> wrote:
>

---

From: Matthieu Boutier <[email-masked]>
Date: Mon, 10 Apr 2017 23:47:38 +0200

Hi,

> Something else?

Perhaps.  Let the new Hello be:

 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 = 4    |    Length     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

And define 2 new sub-TLVs:

1. Unicast Hello Interval

 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 = X    |    Length     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Seqno             |            Interval           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

2. Multicast Hello Interval

 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 = Y    |    Length     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Seqno             |            Interval           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Then put the corresponding Hello TLV where you want.  For compatibility purposes, you should send a unicast Hello with the Multicast Hello Interval sub-TLV attached.  Use the last Interval value used in a (really) multicast Hello as Interval.

The two reserved bytes of the legacy Hello will just cover the type and length of the multicast TLV.  A legacy implementation will see nothing but a just well formed legacy 8-bytes-Hello TLV.

Matthieu