Subject: [manet] Thoughts on draft-dlep-lid

From: Henning Rogge <[email-masked]>
Date: Thu, 7 Sep 2017 12:57:53 +0200

I had some time to look at draft-dlep-lid and there is one thing I am 
wondering about.

I wonder if leaving out the MAC TLV is a bit too tough on many DLEP 
implementations, we are talking about the "primary key" for the neighbors.

Whats about adding a "IP hops" TLV instead, which tells the router how 
many IP hops a neighbor is away?

Default value would be zero (briding distance), but routing radios would 
report something like 2 (two routers in between, one on each radio).

This value might also be useful later for "multihop routing" radios.

Henning Rogge
-- 
Diplom-Informatiker Henning Rogge , Fraunhofer-Institut für
Kommunikation, Informationsverarbeitung und Ergonomie FKIE
Kommunikationssysteme (KOM)
Zanderstrasse 5, 53177 Bonn, Germany
Telefon +49 228 50212-469
mailto:[email-masked] http://www.fkie.fraunhofer.de

---

From: Rick Taylor <[email-masked]>
Date: Fri, 8 Sep 2017 09:34:03 +0000

Hi Henning,

The LID draft is actually an amalgamation of a 2 rough drafts I was
working on to solve two different use-cases, and Stan correctly pointed
 out the solution was the same:

1) There is some backhaul network accessible via a radio, where the
upstream router does not really exist in DLEP terms, it certainly
doesn't have a reachable MAC, and won't perform any kind of routing
protocol peering.  But, there is definitely a link that can come and
go, and metrics about the link are valid.  An example could be 3G.  A
DLEP destination exists, it has routes and addresses, but no MAC.

2) Existing radio systems that mesh at layer-3.  These radio systems
can also supply valid DLEP information, but again, there are no MAC
addresses that make any sense. (This was the old Layer-3 DLEP
extension)

I tried for some time to keep the DLEP MAC address Data Item as the
'primary key', initially by having an extra data item: "This MAC is not
a MAC", but the end result is the same.  To support LIDs, somewhere in
your DLEP information base you need a field associated with your
Destination that specifies whether the ID is a MAC or not.

After extensive discussion with Stan and Keith Morgan (on list 31/5/17
onwards), I was convinced that a separate Data Item, replacing the MAC,
but of the same byte-length as the MAC was the most elegant solution. 
But I'm not fixed in my opinion,  if the WG wants to adopt this
extension, and the consensus is that an extra "Not-MAC" data item is
the better way to go, then so be it.

So in conclusion, the LID extension proposes loosening the definition
of the 'primary key' for your Destinations from 'They are Layer-2
addresses/MACs' to 'They are fixed length identifiers, some of which
are MACs'.  And the extension defines how a peer can differentiate
between them.

Cheers,

Rick

---

From: Henning Rogge <[email-masked]>
Date: Fri, 8 Sep 2017 11:39:06 +0200

> are MACs'.  And the extension defines how a peer can differentiate

In fact we do something similar here, "inventing" a (non-global) MAC
for transmitting metrics for IP destinations.

As I said in the other mail, I am just a bit worried about removing a
mandatory TLV from a message.

Henning

---

From: Rick Taylor <[email-masked]>
Date: Fri, 8 Sep 2017 09:57:20 +0000

> for transmitting metrics for IP destinations.

It seems to be the common work-around.

> mandatory TLV from a message.

And that could be a good reason for having the 'Not-MAC' data item
instead...

Rick

---

From: Stan Ratliff <[email-masked]>
Date: Fri, 8 Sep 2017 11:04:09 -0400

Hi everyone,

Some thoughts/observations inline. Some of these are "devil's advocate"
kind of responses, so please - don't throw your beer at me. ;-) Besides,
beer is expensive!

> And that could be a good reason for having the 'Not-MAC' data item
And I think the "Not-MAC" data item presents its own opportunity for
confusion, since the mandatory data item is a MAC. So, it's a MAC. Unless
it isn't. That's consistent... ;-)

Seems to me that there are two issues to be solved. The first is how to
signal to a router that this destination is somehow "special". In this
case, "special" = Rick's original point 1 above (no real DLEP peer, no
reachable MAC, but a path to a prefix or set of prefixes).

The second problem is how to tell the router to format L2 frames headed to
that "special" destination. In this case, the router should use the
*radio's MAC* as the D-MAC in frames wanting to go up the "special" link.

I think the existing LID draft covers both of the problems, although (IIRC)
the D-MAC for data packets is more inferred than signaled.

But it does occur to me:  We *could* signal this by using the MAC address
*of the radio itself*, followed by the LID TLV. That explicitly signals
both the MAC address to use on the data path, and the fact that this
destination is "special". Multiple LID indicators could be placed on the
Destination Up, indicating that the modem has more than 1 "special" pipe,
but in all cases, the router should use the signaled MAC for traffic to
those pipes.

Signaling multiple LIDs on a single Destination Up might have some
drawbacks, in that I don't readily see (without the use of container TLVs)
how to provide LID-specific initial metrics on Dest Up, and the same issue
exists with Destination Update to signal metric changes for a specific LID
(again, employ the container TLV concept?).

One way (possibly seen as "klunky") to handle metrics, adding, and deleting
is to consider (for purposes of the extension) the MAC/LID as a tuple -
each MAC/LID combination is a separate DLEP Destination, and the
requirement for things to be unique extends to the tuple in this case. The
radio could ONLY specify 1 MAC/LID tuple per Destination Up/Destination
Update/Destination Down. There are downsides there :
1. If the modem has 256 of these "special" links, then it'll take 256
Destination Up messages to get them all up & ready to go.
2. It's obviously tougher to parse - you can't just pick up a MAC address
and search internal structures to see if you already have this Destination.
There are probably other down-sides I'm not thinking of.

But on the up-side, it allows us to use the existing Destination Update
(which would also carry the MAC/LID tuple) for providing metrics on a
single LID, and adding or deleting prefixes for said LID.

And, at least in this case, a MAC is always a MAC... ;-)

Just a thought.

Regards,
Stan

---

From: Henning Rogge <[email-masked]>
Date: Mon, 11 Sep 2017 09:53:17 +0200

Hi,

lets get the ball rolling again after the weekend... all this "MAC is
not a MAC" thing got me thinking if we are trying to hard to keep the
original identifier.

I am not sure I like Stan's suggestion using the radio as
"destination" for all "multiple IP hops away" targets, but it could
work and it makes sense in terms of "this is the MAC you have to send
data to". You could use the MAC reported from DLEP to fill the ARP
table.

But maybe we should rethink making the LID 6 bytes just as the MAC...
IF we put it into a TLV of its own (as Rick suggested), maybe
extending the length to 128 bits would be better... this way we can
put things like an UUID into it and we have less confusion about MAC
versus PC \r\r LID.

What do you think?

Henning

On Fri, Sep 8, 2017 at 5:04 PM, Stan Ratliff <[email-masked]> wrote:
> Hi everyone,
>
> Some thoughts/observations inline. Some of these are "devil's advocate" kind
> of responses, so please - don't throw your beer at me. ;-) Besides, beer is
> expensive!
>
> confusion, since the mandatory data item is a MAC. So, it's a MAC. Unless it
> isn't. That's consistent... ;-)
>
> signal to a router that this destination is somehow "special". In this case,
> "special" = Rick's original point 1 above (no real DLEP peer, no reachable
> MAC, but a path to a prefix or set of prefixes).
>
> that "special" destination. In this case, the router should use the *radio's
> MAC* as the D-MAC in frames wanting to go up the "special" link.
>
> *of the radio itself*, followed by the LID TLV. That explicitly signals both
> the MAC address to use on the data path, and the fact that this destination
> is "special". Multiple LID indicators could be placed on the Destination Up,
> indicating that the modem has more than 1 "special" pipe, but in all cases,
> the router should use the signaled MAC for traffic to those pipes.
>
> is to consider (for purposes of the extension) the MAC/LID as a tuple - each
> MAC/LID combination is a separate DLEP Destination, and the requirement for
> things to be unique extends to the tuple in this case. The radio could ONLY
> specify 1 MAC/LID tuple per Destination Up/Destination Update/Destination
> Down. There are downsides there :
> (which would also carry the MAC/LID tuple) for providing metrics on a single
> LID, and adding or deleting prefixes for said LID.
>

---

From: Stan Ratliff <[email-masked]>
Date: Mon, 11 Sep 2017 10:44:31 -0400

Apologies, I responded directly to Henning with this. Adding Rick + MANET
list.

Regards,
Stan

---------- Forwarded message ----------
From: Stan Ratliff <[email-masked]>
Date: Mon, Sep 11, 2017 at 10:42 AM
Subject: Re: [manet] Thoughts on draft-dlep-lid
To: Henning Rogge <[email-masked]>

A couple of thoughts inline:

> data to". You could use the MAC reported from DLEP to fill the ARP

As I understand the rationale behind the LID extension, it assumes that
there's L3 forwarding occurring on the non-DLEP links. That being the case,
if you want the radio to forward traffic in this fashion, you have to send
said traffic to the radio's MAC. The radio is, by definition, the router's
next hop.

IIRC, the current LID draft assumes the router already has the radio's MAC,
since the router is in a DLEP/TCP session with the radio. Because of that,
I'll admit that my suggestion is a bit redundant, in that the radio sends
information the router already has. But this flow makes the LIDs fit in to
the parsing scheme easier (at least IMO, it's easier), and it's explicit as
to where the router must send the traffic at L2.

> put things like an UUID into it and we have less confusion about MAC

Again, IIRC, some of the initial discussions on-list talked about a LID
length that was variable. That is something I'm opposed to, as it makes
searching them less efficient. The main thing I like about the notion that
sizeof(LID) == sizeof(MAC) is that I can put them in the same searchable
data structure (in my case, an AVL tree), as long as they don't clash. I
can live with sizeof(LID) != sizeof(MAC), but I think that's sub-optimal.
What I see as really bad is the notion of a variable length LID.

Regards,
Stan

> kind
> case,
> *radio's
> both
> each
> single

---

From: Henning Rogge <[email-masked]>
Date: Mon, 11 Sep 2017 16:45:27 +0200

On Mon, Sep 11, 2017 at 4:42 PM, Stan Ratliff <[email-masked]> wrote:
> data structure (in my case, an AVL tree),

Yes, I thought so too, but you can easily have a single AVL tree with
different key lengths in it... just have the length field as the first
part of your "comparator" function.

> as long as they don't clash. I can
> live with sizeof(LID) != sizeof(MAC), but I think that's sub-optimal. What I
> see as really bad is the notion of a variable length LID.

I would suggest setting a fixed length for the LID too...

Henning

---

From: Stan Ratliff <[email-masked]>
Date: Mon, 11 Sep 2017 10:52:20 -0400

> part of your "comparator" function.

I'm most likely being dense here, but... I don't know of any way an AVL
tree can be simultaneously balanced against two different keys. Especially
keys of different lengths.

Regards,
Stan

---

From: Henning Rogge <[email-masked]>
Date: Mon, 11 Sep 2017 16:57:34 +0200

On Mon, Sep 11, 2017 at 4:52 PM, Stan Ratliff <[email-masked]> wrote:
> I'm most likely being dense here, but... I don't know of any way an AVL tree
> can be simultaneously balanced against two different keys. Especially keys
> of different lengths.

Each AVL tree needs ONE function that compares key A to key B and
tells you "smaller, equal, larger".

int comp_keys(key1, key2) {
    if len(key1) > len(key) {
        return larger;
    if len(key1) < len(key) {
        return smaller;

    /* these keys will have the same length */
    return cmp(key1, key2, len(key1));
}

The trick is to combine both factors into a single key to compare.

Henning

---

From: Rick Taylor <[email-masked]>
Date: Tue, 12 Sep 2017 09:35:06 +0000

Sorry, I was away from my machine yesterday,  comments inline...

> I would suggest setting a fixed length for the LID too...

Excellent, this mirrors the earlier discussion, where we concluded that
a fixed length LID is the best compromise.

What we also previously discussed was how does one negotiate the length
of a LID.  The options put forward were:

a) You don't: TLVs have a length field, so look at that.

b) LIDs MUST be an arbitrary 32bit unsigned int.

c) A 'LID Length Announce' Data Item used at Session Init.

d) LIDs MUST be the same length as the MACs used on the link carrying
the DLEP session.

After discussion, the conclusion was option d was the best compromise,
and is what is described in draft-dlep-lid-01 (which is an incorrect
name I could fix, but I'm hoping to rename as draft-manet-dlep-lid-00)

Cheers,

Rick

---

From: Henning Rogge <[email-masked]>
Date: Tue, 12 Sep 2017 13:35:50 +0200

> a fixed length LID is the best compromise.

Yes.

> name I could fix, but I'm hoping to rename as draft-manet-dlep-lid-00)

I was this opinion too, but I think there are disadvantages in
choosing the same length... including the problem of mixing them up
with MAC addresses (and the question if you are allowed to choose a
LID that is also be used as a MAC address).

Henning

---

From: Rick Taylor <[email-masked]>
Date: Tue, 12 Sep 2017 13:58:08 +0000

> LID that is also be used as a MAC address).

The draft says:

"...Router implementations MUST NOT assume that LIDs will not clash
with any MAC Address Data Items also in use during the DLEP session,
LIDs exist in a separate numbering space."

To avoid that hazard.  I couldn't think of any other way of pointing
out the difference.  Really, if you mix them up then you're not reading
the spec clearly, or it's a bug.

Rick

---

From: Stan Ratliff <[email-masked]>
Date: Tue, 12 Sep 2017 10:03:49 -0400

> LID that is also be used as a MAC address).

As for choosing a LID that is also a MAC - I'd say an emphatic no. One
scheme is to mark the LIDs as Locally Administered Addresses. They're
guaranteed not to clash with real MAC addresses.

Regards,
Stan

---

From: Henning Rogge <[email-masked]>
Date: Tue, 12 Sep 2017 16:04:55 +0200

> guaranteed not to clash with real MAC addresses.

What happens if one of my bridged routers uses a locally administrated
address as a MAC too?

Henning

---

From: Stan Ratliff <[email-masked]>
Date: Tue, 12 Sep 2017 10:08:39 -0400

> What happens if one of my bridged routers uses a locally administrated

A couple of questions there - first, why would the bridged router not use
the burned-in MAC? Secondly, if you're using randomly-generated suffixes
for the LAAs, then your chance of collision is very small.

Regards,
Stan

---

From: Henning Rogge <[email-masked]>
Date: Tue, 12 Sep 2017 16:12:21 +0200

On Tue, Sep 12, 2017 at 4:08 PM, Stan Ratliff <[email-masked]> wrote:
> the burned-in MAC? Secondly, if you're using randomly-generated suffixes for
> the LAAs, then your chance of collision is very small.

Either we should say "LID is a 'virtual MAC' and DLEP must make sure
not to collide"... or it is not a MAC and from a different namespace
and we should not care.

The same train of thoughts made me think about extending the LID to 16
bytes to make it really different (and make it easy to use all kind of
input including IPv6 addresses to generate them).

Henning

---

From: Stan Ratliff <[email-masked]>
Date: Tue, 12 Sep 2017 10:19:01 -0400

On Tue, Sep 12, 2017 at 10:12 AM, Henning Rogge <[email-masked]> wrote:

> for
> That's a fair observation. In that case, I'd lobby for the first option -
that is, a LID is a 'virtual MAC'.

My rationale is this:
A LID is a 'place where traffic goes'. It has metrics associated with it.
Almost by definition, it has subnets (or maybe just 1 subnet) attached to
it. Therefore, to me at least, it's a DLEP Destination.
Perhaps we could split hairs and call it a 'sub-destination', in that
multiple LIDs to the same radio will produce outgoing frames with the same
DMAC address, but for all intents and purposes, it's a destination.

Regards,
Stan

---

From: Rick Taylor <[email-masked]>
Date: Tue, 12 Sep 2017 16:45:26 +0000

On Tue, 2017-09-12 at 10:19 -0400, Stan Ratliff wrote:
> > > On Tue, Sep 12, 2017 at 10:04 AM, Henning Rogge <[email-masked]
> > > wrote:
> That's a fair observation. In that case, I'd lobby for the first
> option - that is, a LID is a 'virtual MAC'. 
> 
> My rationale is this:
> A LID is a 'place where traffic goes'. It has metrics associated with
> it. Almost by definition, it has subnets (or maybe just 1 subnet)
> attached to it. Therefore, to me at least, it's a DLEP Destination. 
> multiple LIDs to the same radio will produce outgoing frames with the
> same DMAC address, but for all intents and purposes, it's a
> destination.

I'm with Stan on this:  A LID is just an opaque identifier of
'somewhere with an IP address and subnet' that happens to be same
length as a MAC, purely for convenience.  Yes, it's a destination, it
just doesn't happen to have an 'other end' with a usable MAC address.

Given the amount of confusion making them look like MACs causes, I'm
thinking about changing to 1 capital letter [A-Z] only.  If you need
more that 26 LIDs per session then you're using the wrong technology.

The main advantage of using 6 or 8 octets for your ID is that you COULD
derive it from some internal link-layer MAC, or just start counting
from 1.

Rick

---

From: Rick Taylor <[email-masked]>
Date: Tue, 12 Sep 2017 16:48:42 +0000

On Tue, 2017-09-12 at 10:03 -0400, Stan Ratliff wrote:
> As for choosing a LID that is also a MAC - I'd say an emphatic no.
> One scheme is to mark the LIDs as Locally Administered Addresses.
> They're guaranteed not to clash with real MAC addresses.   

I'm opposed to making any sort of MAC-like comment, such as "Use the
Locally Administered bit" about LIDs as it implies that they are in
some unspecified way MACs, and they're not: just numbers in the range
[0..2^48)

Rick

---

From: Henning Rogge <[email-masked]>
Date: Thu, 14 Sep 2017 08:54:05 +0200

> some unspecified way MACs, and they're not: just numbers in the range

If they are totally independent from MACs, why not give them a few
more bytes... it will prevent people from making the (easy) mistake to
think they don't collide with the used MACs... and it is still trivial
to use MACs (or IPv4 or IPv6) as a source for the ID.

Henning

---

From: Henning Rogge <[email-masked]>
Date: Tue, 19 Sep 2017 08:48:02 +0200

I will try to summarize the 'three' solutions we had on this thread in
the last weeks:

1) make LID a 6/8 byte identifier independent from MAC addresses (they
can have the same binary value than an used MAC)

2) make LID a 6/8 byte identifier which MUST NOT collide with an used
MAC address

3) make LID a 16 byte identifier

In my opinion case 2) means that we call LIDs something like "virtual
MAC" or "local generated MAC"... if they use the same 'namespace' and
must not collide, we should make sure that the protocol designers and
protocol users know they are from the same namespace.

At the moment Rick proposes 1), Stan proposes 2) and I proposes 3)...

What shall we do?

Henning

---

From: Stan Ratliff <[email-masked]>
Date: Tue, 19 Sep 2017 10:12:13 -0400

Henning,

> At the moment Rick proposes 1), Stan proposes 2) and I proposes 3)...

What a router would need from the modem's specification of a LID is that
1. The LID is unique, at least within the context of a single modem, and
2. The next hop (the MAC address) for traffic going to the LID
3. Subnets that are accessible via the LID.

Any subnets attached to the LID would be inserted into the router's RIB
with the next hop address. The issue I had with the initial draft is that
the MAC address is inferred - it was just assumed that the MAC address used
for forwarding traffic to the LID was the same as the MAC address the modem
is using for the DLEP TCP session. I'd prefer it if the MAC address used
for data plane forwarding is explicitly defined via the existing TLV. I
understand that could create some issues - for instance, a modem announcing
the presence of 4 LIDs might (or might not) want to replicate the same MAC
address for all 4. We've currently created a protocol where MACs are
guaranteed to be unique, but I think we can craft some text essentially
saying "Well, yeah... but not in this case..."

Now, for the length. I admittedly made something of a leap, in that it
occurred to me that if LIDs are the same size as MAC addresses, and they
don't clash with existing MACs, an implementation could easily put them
into the existing DLEP information base, without much modification. But, I
can see an implementation that uses some arbitrary LID length working as
well - I just view that as more effort to implement. You'd need a "LID
information base" that's hung off of the DLEP Peer. That's why I said
earlier in the conversation that I can live with the notion that
sizeof(LID) != sizeof(MAC).

So, you could say that my proposal for sizeof(LID) == sizeof(MAC) is not a
passionately-held position. Where I start to get passionate is in my belief
that the MAC address used for traffic forwarding MUST be explicitly
specified by the modem, and not inferred.

Regards,
Stan