Subject: Re: [manet] DLEP and modemLPA

From: Abdussalam Baryun <[email-masked]>
Date: Wed, 25 Apr 2012 17:17:16 +0200

Hi Henning and Teco,

Having some comments on below discussions, I maybe misunderstood (I
still reading the DLEP protocol !).

>IMHO unneeded functions.

>One man's unneeded function is another man's essential function. I
>think when there's a function one doesn't see a need for, it's time
>to ask why it's there before suggesting removing it.

AB> IMHO, this unneeded-function is only true in fixed state
conditions not in arbitrary. The DLEP solves slow process of
the-updating-functions (link state detection) which usually are
expected-stable by routing function for a certen time, but DLEP
reports the unexpected link factors, even though it may have some
limitations. IMHO all DLEP functions should be independent in this
first standard, in future we may think to adapt to other protocols'
works.

>I did not have any intention to remove functionality. I meant IETF
>has already protocols for functions DLEP also provides. We should try
>to use existing protocols as much as possible, before standardizing
>new ones. I suggested to split DLEP in what is needed and isn't in
>place (STD TRACK) and what can be done in some special cases
>(experimental). IMHO flow control and address resolving are unneeded
>and I asked why these are in DLEP. I did not get satisfying answers.

AB> I think it is better to solve the protocol advantages in its
use-case-problem, than to solve the full MANET problems. Then we may
look at all protocols equally and see which functions needs to be
taken apart and which should be satying as it is. If we follow the
evaluation process as in RFC2501, I think DLEP has interesting methods
which if we modify routing protocols to adapt to its rules will be
more reasonable, because the dynamic topology is the main problem in
MANET, and DLEP is reporting this change very closer than other MRPs.
However, I just want to mention that we can look in both sides either
modify/split DLEP functions or MRPs.

>I think they are in DLEP because there are already quite a few IP capable radios >who KNOW their own and their neighbors IP address because of their internal >protocol.

>If the radio has knowledge about this, it should be able to tell the router about it so >the router can set the right IP on his local interface.

AB> DLEP is for link dynamic behavior than it is about node's
behavior, so it is more important that it is reporting the link
change, the IP is an advantage alternative.

>But the DLEP-Service (radio) should only report whats already known, it should not >generate additional traffic.

AB> I don't think it is generating additional, it generated necessary
information for an arbitrary situation (unpredicted by routers),
Therefore, it is solving a problem that is not solved as mentioned in
the use-case discussions.

Abdussalam Baryun
University of Glamorgan, UK

---

From: Stan Ratliff <[email-masked]>
Date: Wed, 25 Apr 2012 12:57:49 -0400

>> and I asked why these are in DLEP. I did not get satisfying answers.

First off, splitting DLEP into multiple specs is a REALLY bad idea. If  
we did that, there wouldn't be ANY place where the protocol, in its  
entirety, is documented. IMO, that makes it more difficult to  
implement, and more difficult to ensure interoperability. Next, I've  
explained the reasoning behind the flow control on more than one  
occasion - it was put in due to *specific requests*, both on and off- 
list, by members of the WG. It's consistent with RFC 5578. And, IT IS  
OPTIONAL. Don't like it? Simple. Then DON'T IMPLEMENT IT. Same thing  
goes  for the addresses - as has been said before, reliance on other  
protocols like ARP slows down the process. It also makes the  
underlying assumption that *everything* one router/radio pair attaches  
to is in the same subnet - because IIRC, ARP gets discarded when  
subnets don't match. With this OPTIONAL (again, if you don't like it,  
then don't implement it) approach, the appropriate ARP caches can be  
populated when they're needed, irrespective of subnet masks. Provided,  
of course, the modem (radio) already has cognizance of the far-end's  
address(es).

Thus far, I've seen MULTIPLE requests to put flow control into the  
spec, and only ONE to remove it. Operating under the "Rough consensus  
and working code" model, I'd say that up to this juncture, we have  
"rough consensus" to KEEP flow control in the document.

Stan

>> I think they are in DLEP because there are already quite a few IP  
>> capable radios >who KNOW their own and their neighbors IP address  
>> because of their internal >protocol.
>
>> If the radio has knowledge about this, it should be able to tell  
>> the router about it so >the router can set the right IP on his  
>> local interface.
>
>> But the DLEP-Service (radio) should only report whats already  
>> known, it should not >generate additional traffic.
>
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet

---

From: Bo Berry <[email-masked]>
Date: Wed, 25 Apr 2012 13:20:58 -0400

Stan, All
I think the spec should remain intact, not split-up.  I also 
think the flow control should remain as this was added by 
requests.  We have had good experiences with it in other
protocols. 

While speaking up, I'm not a fan of forcing the DLEP addresses
into the Address TLV. If we really what to do so, then we need
to enhance RFC 5444. 

We spec'ed DLEP from our experiences with other related protocols,
a variety of radios, networks and applications.  I suspect as time
rolls on, more features and capabilities will be requested. 

We do appreciate the discussion. 

Thanks
-Bo

On Apr 25, 2012, at 12:57 PM, Stan Ratliff wrote:

> First off, splitting DLEP into multiple specs is a REALLY bad idea. If we did that, there wouldn't be ANY place where the protocol, in its entirety, is documented. IMO, that makes it more difficult to implement, and more difficult to ensure interoperability. Next, I've explained the reasoning behind the flow control on more than one occasion - it was put in due to *specific requests*, both on and off-list, by members of the WG. It's consistent with RFC 5578. And, IT IS OPTIONAL. Don't like it? Simple. Then DON'T IMPLEMENT IT. Same thing goes  for the addresses - as has been said before, reliance on other protocols like ARP slows down the process. It also makes the underlying assumption that *everything* one router/radio pair attaches to is in the same subnet - because IIRC, ARP gets discarded when subnets don't match. With this OPTIONAL (again, if you don't like it, then don't implement it) approach, the appropriate ARP caches can be populated when they're needed, irrespective of subnet masks. Provided, of course, the modem (radio) already has cognizance of the far-end's address(es).
> 
> Thus far, I've seen MULTIPLE requests to put flow control into the spec, and only ONE to remove it. Operating under the "Rough consensus and working code" model, I'd say that up to this juncture, we have "rough consensus" to KEEP flow control in the document.
> 
> Stan
> 
> 
> 

----
[email-masked]
This email may contain confidential and privileged material for the sole use of the intended recipient. This email may contain information that is protected by NDA. Any unauthorized review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message.

---

From: Henning Rogge <[email-masked]>
Date: Wed, 25 Apr 2012 20:59:10 +0200

> requests.  We have had good experiences with it in other

I agree with this... the flow control (and the link characteristics
request) might be a different "block of functionality" of DLEP, but it
mixes well in the concept of a Router-Interface communication
protocol.

> into the Address TLV. If we really what to do so, then we need

I think moving the MAC addresses into the address space of RFC 5444
makes a LOT of sense. It allows it to trivially formulate DLEP
messages that contain updates (both IP or metric) for multiple radio
neighbors by allowing to have TLVs for one and for multiple
neighbors/mac-addresses.

Putting the IPs (if they are available on the radio) into address-TLVs
on this MACs is just a natural extension of this.

It also allows the interface to identify itself by using the
originator-address (which will become also a 6 byte field in this
case).

> We do appreciate the discussion.

I would like to talk about the reason why you decided to split the
handshake between Interface and Router apart into that many "orders".
>From my point of view, this part of the protocol is very complex
without too much gain.

As I can see it, there are several things the handshake should be able to do:
(I am talking about the Peer Discovery (both), Peer Termination
(including ACK) orders and the bi-directional heartbeat order.)

- it should allow the router to auto-discover the DLEP-equipped radio
by just listening
- it should allow both the router and the radio to become aware of each other
- it should allow both the router and the radio to discover a loss of
connection between each other.

Did I missed something important?

Henning Rogge
-- 
Steven Hawkings about cosmic inflation: "An increase of billions of
billions of percent in a tiny fraction of a second. Of course, that
was before the present government."

---

From: Bo Berry <[email-masked]>
Date: Wed, 25 Apr 2012 15:10:41 -0400

Henning

> mixes well in the concept of a Router-Interface communication

concensus +1

> originator-address (which will become also a 6 byte field in this

From my perspective, mushing, obscuring multiple data types into 
single and yet diff data type (IPV6) is a bad idea.  

>> We do appreciate the discussion.

The router-radio peer layer facilitates management of the neighbors
beyond the radio.  For example, if the radio fails, routing can 
quickly cleanup.  We need both levels.  Complexity is relative,
its not so bad.

----
[email-masked]

---

From: Ulrich Herberg <[email-masked]>
Date: Wed, 25 Apr 2012 12:29:56 -0700

Bo,

On Wed, Apr 25, 2012 at 12:10 PM, Bo Berry <[email-masked]> wrote:
> > [...]

I thought that this idea has already been abandoned and replaced by
instead by a proposal to use 6-byte (MAC) address length and address
blocks, and to put IPv6 and IPv4 addresses into message TLVs? That
seems to be the logical approach, since DLEP is a layer 2 protocol
(and updating RFC5444 is difficult).

> [...]

Regards
Ulrich

---

From: Bo Berry <[email-masked]>
Date: Wed, 25 Apr 2012 15:35:19 -0400

> (and updating RFC5444 is difficult).

no, there was a lot of discussion by some, but no concensus, agree,
at least from me.

----
[email-masked]

---

From: Stan Ratliff <[email-masked]>
Date: Wed, 25 Apr 2012 15:41:28 -0400

Ulrich,

> (and updating RFC5444 is difficult).

I think that any attempt to force MAC addresses into 5444 address  
blocks for DLEP *only* (at least it's only DLEP at this time) is  
basically trying to ram a square peg into a round hole - with a  
sufficiently large sledge-hammer, "anything is possible". My concern  
all along with doing that is that we end up with a one-off, and I'm  
strongly opposed to that. IMO, the way to address it "properly" is  
with "RFC 5444 bis"., and I don't see any energy to do that.

Regards,
Stan

---

From: Henning Rogge <[email-masked]>
Date: Wed, 25 Apr 2012 22:17:44 +0200

> single and yet diff data type (IPV6) is a bad idea.

I only want to put mac-addresses (6 bytes) into the RFC 5444 defined
addresses. The IPs can stay in TLVs (address TLVs in my suggestion)
like its currently described in the DLEP-draft (if you ignore the
whole sub-tlv mess).

> quickly cleanup.  We need both levels.  Complexity is relative,

Is the management of the neighbors beyond the radio part of the Peer
Discovery (both), Peer Termination (including ACK) orders and the
bi-directional heartbeat order?

I thought this "tell about the neighbors" is mostly the neighbor updates.

Do not understand me wrong, I do not want to skip any of the described
features, I just try to grasp if I missed an important feature of the
router-radio handshake.

Henning

---

From: Teco Boot <[email-masked]>
Date: Wed, 25 Apr 2012 22:18:33 +0200

Stan,
If you SHOUT, what hat are you wearing?
Teco

---

From: Henning Rogge <[email-masked]>
Date: Wed, 25 Apr 2012 22:24:31 +0200

On Wed, Apr 25, 2012 at 21:41, Stan Ratliff <[email-masked]> wrote:
> I think that any attempt to force MAC addresses into 5444 address blocks for
> DLEP *only* (at least it's only DLEP at this time) is basically trying to
> ram a square peg into a round hole - with a sufficiently large
> sledge-hammer, "anything is possible". My concern all along with doing that
> is that we end up with a one-off, and I'm strongly opposed to that. IMO, the
> way to address it "properly" is with "RFC 5444 bis"., and I don't see any
> energy to do that.

It was an explicit design decission for RFC 5444 that it is not
restricted to IP as addresses, but just sees addresses as a binary
field of 1 to 16 bytes. So using a RFC 5444 message with 6 bytes
addresses for DLEP is fitting the round cylinder into the round hole.

Each radio (from the point of view of the IP router) has a mac
address, so its a natural way to describe radios by their mac address.

And then you can attach any kind of (optional) information you have
about the radios to these mac addresses.

I don't see where this doesn't fit the concept of RFC 5444.

Henning Rogge

---

From: Ulrich Herberg <[email-masked]>
Date: Wed, 25 Apr 2012 13:34:18 -0700

Stan,

> way to address it "properly" is with "RFC 5444 bis"., and I don't see any

I don't understand that. RFC5444 can be used for any address length.
Therefore, using 6 byte addresses is absolutely conform with RFC5444
and not DLEP *only*. There would be no need for a RFC5444 bis.

Ulrich

---

From: Teco Boot <[email-masked]>
Date: Wed, 25 Apr 2012 22:46:11 +0200

> address, so its a natural way to describe radios by their mac address.

I guess it is all about MAC addresses of far-en routers.
The local radio would have a MAC address, could be used as orig-addr.

There could be multiple local radio's, probably on same Ethernet segment.

On separate segments, MAC addresses may overlap. Applies to local radios
and remote routers.

Teco

---

From: Teco Boot <[email-masked]>
Date: Wed, 25 Apr 2012 22:54:11 +0200

Op 25 apr. 2012, om 22:34 heeft Ulrich Herberg het volgende geschreven:

>> DLEP *only* (at least it's only DLEP at this time)
There is OLSR at layer 2.something around. I guess it will use OLSRv2 
one time.

>>  is basically trying to
 +1.
Thanks to Henning.

Teco

---

From: Abdussalam Baryun <[email-masked]>
Date: Wed, 25 Apr 2012 23:14:58 +0200

Hi Henning,

> From my point of view, this part of the protocol is very complex

AB> IMHO the manet-dlep-02 needs more definitions about the DLEP
communication it referse to in pages 13, 15, 17, 57.

AB> in title says Dynamic Link Exchange for DLEP but in body say Data
Link Exchange.

However, I am still writting down the full-comments, however, it seems
difficult to understand the handshaking which I dought there is a
handshaking, it seems like interaction between server and clients and
neighbors, by sending messages, not full connection. I hope we get
some new describtions/definition about these relationship in the next
draft as in a terminology section and in some easier to read
paragraphs.

> Did I missed something important?

AB> I think I may misunderstood the DLEP but I think you may missed:-

- That DLEP is a stateful protocol and it is not having a connections
with server and client (both are DLEP adapted), the session is
initiated in the DLEP entity and bothe server (DLEP's router) and
client (radio) have not session between them.

-Niegbors are not L3 nor L2 neighbors (only server maybe L2 or L3, or
L4) they are L1 (PHY-layer, because clients are physical-modems)
neighbors. Each neighbor has a ID = MAC address which is the MAC of
the MANET interface.

- DLEP interface is not a MANET interface. the router abstract from
the DLEP but it exchanged specific messages (control messages) which
are out-bound from the data communication.

 Therefore DLEP faciltates a control path for the router to change
modem parameters, and in the same time it gets feedback of the events
of link changes.

AB> I am not sure what I have said is true but just I repeat what I
understood from the draft only.

Abdussalam Baryun

---

From: Bo Berry <[email-masked]>
Date: Wed, 25 Apr 2012 22:27:03 -0400

All
As defined, the DLEP IPv4 & IPV6 TLVs support an ADD/DROP
designation that complements the address.  I do not 
think this fits in the Address block. 

Still not seeing MAC addresses efficiently fitting into 
address block.  

Rather stay with the DLEP MAC, IPv4/6 TLVs.

Thanks
-Bo

""An address is specified as a sequence of address-length 
octets of the form Head:Mid:Tail.""

   <address-block> is defined by:

       <address-block> := <num-addr>
                          <addr-flags>
                          (<head-length><head>?)?
                          (<tail-length><tail>?)?
                          <mid>*
                          <prefix-length>*

----
[email-masked]

---

From: Ulrich Herberg <[email-masked]>
Date: Wed, 25 Apr 2012 19:49:05 -0700

Bo,

> Still not seeing MAC addresses efficiently fitting into

Why not? It may not be well compressible if using NICs from different
vendors, but at least it would fit well in the RFC5444 architecture and
maybe saves some bytes for the TLVs type and length for each address.

> Rather stay with the DLEP MAC, IPv4/6 TLVs.

My concern is that if we 1) don't use address blocks, but 2) use sub-TLVs
instead of TLVs, there is not much left of RFC5444. A completely new parser
has to be implemented, and one could just as well not use RFC5444 at all.
Maybe I just don't see your argument why using address blocks for the MAC
addresses (and for the originator address) is bad. To me, it seems the
natural way when using RFC5444 on L2. For IPv4/6, I agree that using TLVs
is probably the only option, since RFC5444 does not support mixed address
lengths (unless we issue an RFC5444bis, which could have compatibility
problems).

>       <address-block> := <num-addr>

In case the NICs are from different vendors, tail and head would be empty,
and all addresses would be in the mid. If NICs are from the same vendor,
<head> would likely contain the first three bytes of the vendor ID and
<mid> would contain the latter three bytes. <tail> would quite likely
always be empty.

Regards
Ulrich

> blocks for
> This email may contain confidential and privileged material for the sole
> use of the intended recipient. This email may contain information that is
> protected by NDA. Any unauthorized review, use, distribution or disclosure
> by others is strictly prohibited. If you are not the intended recipient (or
> authorized to receive for the recipient), please contact the sender by
> reply email and delete all copies of this message.
>
>
>
>

---

From: Bo Berry <[email-masked]>
Date: Wed, 25 Apr 2012 23:16:31 -0400

Ulrich
Thanks for the healthy discussion.  In-line.
-Bo

On Apr 25, 2012, at 10:49 PM, Ulrich Herberg wrote:

> Why not? It may not be well compressible if using NICs from different vendors, but at least it would fit well in the RFC5444 architecture and maybe saves some bytes for the TLVs type and length for each address.

I'm more concerned about it fitting into DLEP specification and functionality than mushing MACs into an Address block, for one MAC.  It is easy to parse the MAC TLV and other DLEP TLVs.  Given earlier guidance, we reduced DLEP's footprint on RFC 5444 to a single type.  As for what's left, DLEP continues to use the RFC 5444 message and TLV structures.  IMO, DLEP is heavily vetted in RFC 5444. 

> My concern is that if we 1) don't use address blocks, but 2) use sub-TLVs instead of TLVs, there is not much left of RFC5444. A completely new parser has to be implemented, and one could just as well not use RFC5444 at all.
> Maybe I just don't see your argument why using address blocks for the MAC addresses (and for the originator address) is bad. To me, it seems the natural way when using RFC5444 on L2. For IPv4/6, I agree that using TLVs is probably the only option, since RFC5444 does not support mixed address lengths (unless we issue an RFC5444bis, which could have compatibility problems).
>  
> 
> 
> In case the NICs are from different vendors, tail and head would be empty, and all addresses would be in the mid. If NICs are from the same vendor, <head> would likely contain the first three bytes of the vendor ID and <mid> would contain the latter three bytes. <tail> would quite likely always be empty.
> 
> Regards
> Ulrich
> 
>  
> 
> 

----
[email-masked]

---

From: Henning Rogge <[email-masked]>
Date: Thu, 26 Apr 2012 07:32:34 +0200

On 04/26/2012 04:27 AM, Bo Berry wrote:
> All
> As defined, the DLEP IPv4&  IPV6 TLVs support an ADD/DROP

Thats exactly whats NHDP is doing in the HELLO message.

It use a single address of a specific type for each node to identify (in 
the case of DLEP its MAC addresses).

The message contains a list of neighbor addresses, the status of the 
link to the neighbor (in form of a LINK_STATUS TLV) and additional 
optional information about the link like metrics (at least when used in 
OLSRv2).

> Still not seeing MAC addresses efficiently fitting into

I cannot see how putting them into address blocks can be less efficient 
and less straight forward (in terms of protocol design) than some 
special purpose DLEP only "subtlv".

Thats exactly what the address fields of RFC 5444 are about.

>         <address-block>  :=<num-addr>
>                            <addr-flags>
>                            (<head-length><head>?)?
>                            (<tail-length><tail>?)?
>                            <mid>*
>                            <prefix-length>*

Both head and tail can be length zero, if the specific bit in the 
addr-flags field is not set. In this case, you don't even need to store 
a head/tail length.

You also don't need a header for each of the addresses, you only need 
one for all the addresses (up to 255). They will share (optional) a 
single head and (optional too) a single tail, but each has its own "mid" 
part (which might be the whole address).

And if you use a bunch of radios of the same type and manufacturer, you 
might even have the case that all MAC addresses of the devices begin 
with the same head.

Henning Rogge

-- 
Diplom-Informatiker Henning Rogge , Fraunhofer-Institut für
Kommunikation, Informationsverarbeitung und Ergonomie FKIE
Kommunikationssysteme (KOM)
Neuenahrer Straße 20, 53343 Wachtberg, Germany
Telefon +49 228 9435-961,   Fax +49 228 9435 685
mailto:[email-masked] http://www.fkie.fraunhofer.de
GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0

---

From: Ulrich Herberg <[email-masked]>
Date: Wed, 25 Apr 2012 22:36:26 -0700

+1 (too all the arguments)

On Wed, Apr 25, 2012 at 10:32 PM, Henning Rogge <
[email-masked]> wrote:

> The message contains a list of neighbor addresses, the status of the link
> to the neighbor (in form of a LINK_STATUS TLV) and additional optional
> information about the link like metrics (at least when used in OLSRv2).
>
>
> and less straight forward (in terms of protocol design) than some special
> purpose DLEP only "subtlv".
>
> addr-flags field is not set. In this case, you don't even need to store a
> head/tail length.
>
> You also don't need a header for each of the addresses, you only need one
> for all the addresses (up to 255). They will share (optional) a single head
> and (optional too) a single tail, but each has its own "mid" part (which
> might be the whole address).
>
> might even have the case that all MAC addresses of the devices begin with
> the same head.
>
>
> Henning Rogge
>
> --
> mailto:henning.rogge@fkie.**fraunhofer.de<[email-masked]>
> http://www.fkie.fraunhofer.de

---

From: Henning Rogge <[email-masked]>
Date: Thu, 26 Apr 2012 08:22:36 +0200

> draft as in a terminology section and in some easier to read

Thats why I am asking for confirmation that I got the use behind this 
protocol parts right.

I am also not really happy with the names of the radio and the router 
part, both are called 'peer something', which can be quite confusing.

Calling them "radio/interface" and "router" would be more intuitive to 
understand.

> client (radio) have not session between them.

That exactly how I see it too. We have an active DLEP component (the 
radio) and a reactive one (the router). The whole session establishment 
is to get both sides known to each other in an easy, robust way and fast 
way.

> neighbors. Each neighbor has a ID = MAC address which is the MAC of

If each neighbor has a MAC address which is used as its ID, they are 
both layer-1 and layer-2 from DLEP point of view.

> are out-bound from the data communication.

DLEP is control-traffic agnostic, it should not care about how its 
transported between the router and the radio.

> modem parameters, and in the same time it gets feedback of the events

I was just asking questions about the "Session establishment" part of DLEP.

As I see it, the current draft describes five parts of DLEP.

- router-radio Session establishment (and teardown)
- transportation of known neighbors from radio to router (optional with 
known IP addresses)
- transportation of metric data from radio to router
- controlling the link characteristics of the radio by the router
- traffic shaping on the radio with a token scheme by the router

Henning Rogge

---

From: "Rick Taylor" <[email-masked]>
Date: Thu, 26 Apr 2012 10:25:49 +0100

Stan, Henning, et.al.

Concerning using MAC-addresses in RFC5444 Address-Block TLVs for DLEP
*neighbour* messages...

+1 

It's a good fit.  
Doesn't require RFC5444bis.  
Minimal changes to existing DLEP draft.  
Keeps in the 'spirit' of RFC5444.

IP Addresses in Address Blocks...

-1

IP addresses are secondary/optional information, and should not be used
as a 'key' field in messages.

Rick Taylor

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Henning Rogge
> Sent: 25 April 2012 21:25
> To: Stan Ratliff
> Cc: [email-masked]; Bo Berry; Abdussalam Baryun
> Subject: Re: [manet] DLEP and modemLPA
> 
blocks
> for
> > DLEP *only* (at least it's only DLEP at this time) is basically
trying
> to
> > sledge-hammer, "anything is possible". My concern all along with
doing
> that
> > is that we end up with a one-off, and I'm strongly opposed to that.
IMO,
> the
> > way to address it "properly" is with "RFC 5444 bis"., and I don't
see
> any

---

From: Henning Rogge <[email-masked]>
Date: Thu, 26 Apr 2012 11:33:39 +0200

> as a 'key' field in messages.

Just to make sure I understand you correctly...

You mean that you do not want to use IPs as DLEP messages addresses in 
Address Blocks, right?

Its still okay to carry them in Address-Block TLVs, to bind them to the 
corresponding MAC address?

Henning Rogge

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 26 Apr 2012 09:44:47 +0000

Stan
> sufficiently large sledge-hammer, "anything is possible".

I think that's a mischaracterisation. 5444 uses addresses, And all it
cares about is how many octets there are in an address.
A six byte address (which happens to be a MAC address) is just
another address type as far as 5444 is concerned. (You can thank
the IESG for that being so, that wasn't in the original packetbb
concept, but it is in 5444.)

I think it's clear that there is a superior way to present the information
using 5444 than the not nice sub-TLVs of the current proposal.
Unfortunately while I think it's clear, and so do several other people here,
Stan and Bo aren't in that group, and I'm not sure how to persuade them
of that. Note that I'm not saying all proposals for modified formats have
been good ones - the use of IPv6 addresses for all address types was one
idea that was thought of, played around with a bit, and discarded as not
a good idea. Bo seems to still think it's what's being proposed however.

To be clear, the suggestion (which I think I would say has "consensus
among those people who think the format should be changed, but not
consensus among all including the DLEP authors") is roughly
- That information which is local, and not associated with an address is
  put in the message TLV block.
- That information which is not local is associated with a MAC address.
  The MAC addresses are put in the address blocks, and other information
  associated with them is put in the following TLV block.
- One such piece of information is an IPv4 or IPv6 address, which uses a
  TLV, not an address block. Other information includes metrics etc.
- Metrics use one, or a small number, of TLV types, and the metric type
  uses the TLV type extension.

But what we need is a concrete example to be coded up in both ways.
No one seems willing to do this however.

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

---

From: "Rick Taylor" <[email-masked]>
Date: Thu, 26 Apr 2012 10:46:14 +0100

Henning,

> You mean that you do not want to use IPs as DLEP messages addresses in

Correct, I do not want to see them used there.
 
> corresponding MAC address?

Yes, as 'normal' TLVs, they can go wherever they are needed as currently
specified in draft-02.

As Teco says, layer 3 address TLVs should be optional.  

I agree with Stan that it is really useful to have Layer 3 addressing
delivered via DLEP when the modem knows it, but there are examples where
the modem does not know, but DLEP can still function.  

(I am using such a modem now, and I just ARP for the Layer 3 addresses,
it's possible, but a PITA, particularly as InARP is largely unsupported
in the real world).

Rick Taylor

---

From: "Rick Taylor" <[email-masked]>
Date: Thu, 26 Apr 2012 10:51:44 +0100

Chris,

>   uses the TLV type extension.

+1 your summary

>No one seems willing to do this however.

I did send out some ASCII-art message blocks describing what you
summarize to this mailing list a few weeks ago.

I'll dig them out and resend if it would help? Or are you suggesting a
'running code' example?

Rick Taylor

---

From: "Rick Taylor" <[email-masked]>
Date: Thu, 26 Apr 2012 10:59:43 +0100

Chris,

I just checked the archive.  I didn't send any ASCII art of
Address-Block TLVs, just a discovery packet as part of the metric TLV
discussion using a Message-Block.  I'll do a few today, probably for
NeighbourUp.

Anyone have any requests for the examples?

Rick Taylor

Of
> Rick Taylor
> Sent: 26 April 2012 10:52
> To: Dearlove, Christopher (UK); Stan Ratliff; Ulrich Herberg
> > - That information which is local, and not associated with an
address
> is
> > - One such piece of information is an IPv4 or IPv6 address, which
uses
> a

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 26 Apr 2012 10:00:56 +0000

Not that I think that a little more would hurt, it's possible to keep the DLEP allocation to being a single message type while restructuring it, by simply making all TLVs be allocated from that message specific TLV allocation.

As for the ease of parsing DLEP sub-TLVs, it's even easier to write the code to parse the proposed restructuring. I already have it, and so do several other people (their own versions).

-- 
Christopher Dearlove
Senior Principal Engineer, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 |  Fax: +44 1245 242124
[email-masked] | http://www.baesystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Bo Berry
Sent: 26 April 2012 04:17
To: Ulrich Herberg
Cc: [email-masked]; Abdussalam Baryun; Stan Ratliff
Subject: Re: [manet] DLEP and modemLPA

----------------------! WARNING ! ----------------------
This message originates from outside our organisation,
either from an external partner or from the internet.
Keep this in mind if you answer this message.
Follow the 'Report Suspicious Emails' link on IT matters
for instructions on reporting suspicious email messages.
--------------------------------------------------------

Ulrich

----
[email-masked]

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 26 Apr 2012 10:04:10 +0000

I'm suggesting a form of listing of what information is to be reported, to then be coded up each way (whether expressed as ASCII art or an octet listing isn't critical). It would need to be an example that includes all the critical features needed (e.g. local information, non-local information, some, but not all, IP addresses etc.)

-----Original Message-----
From: Rick Taylor [mailto:[email-masked]] 
Sent: 26 April 2012 10:52
To: Dearlove, Christopher (UK); Stan Ratliff; Ulrich Herberg
Cc: [email-masked]; Bo Berry; Abdussalam Baryun
Subject: RE: [manet] DLEP and modemLPA

Chris,

+1 your summary

Rick Taylor

---

From: Henning Rogge <[email-masked]>
Date: Thu, 26 Apr 2012 12:26:43 +0200

+1

I think thats a correct and good description of the current suggestion.

> No one seems willing to do this however.

Would a "Neighbor Address Update" or "Neighbor Update" DLEP order okay 
for this? And should the result contain the structure of the 
packet/message, the binary content or both?

Henning Rogge

---

From: "Rick Taylor" <[email-masked]>
Date: Thu, 26 Apr 2012 11:29:07 +0100

Chris,

> I'm suggesting a form of listing of what information is to be
reported, to
> then be coded up each way (whether expressed as ASCII art or an octet
> listing isn't critical). It would need to be an example that includes
all
> the critical features needed (e.g. local information, non-local
> information, some, but not all, IP addresses etc.)

Agreed.  

I include a cut'n'paste of my previous mail with my breakdown of
draft-02 messages into parts.  I have updated the metrics to collapse
them into 2 ranges, 'standard' (mandatory) and a space for optional
values.

I did some ID assignment to try to keep common TLVs with common
type-ids. I'm not sure how relevant the actual ID assignment is, but I
have tried to keep to 1 top-level TLV-type (DLEP_MESSAGE).  My use of
extension-types to indicate optional TLVs may not be appropriate, but
their use with metrics seems popular.

I have described every piece of data from draft-02, but I suggest
checking with the draft for actual TLV lengths and meanings.

I have also made Version and Status mandatory whenever specified.

Rick Taylor

KEY:
  0xXX   - TLV type 0xXX+128, no extension (DLEP_MESSAGE specific type)
  0xXXYY - Optional TLV type 0xXX+128, extension 0xYY

All address-block-TLVs use a <address-len> of 6 and the MAC address of
the neighbour.

Please note the encoding of the extension types, i.e. the extension-id
is constant, just the type-id changes (sort of covering the sub-TLV
concept)

Attached Peer Discovery Message (message-block-TLVs)
  0x01 TYPE: Attached_Peer_Discovery + Identification + Version
  0x0101 Peer Type
  0x0102 Heartbeat Interval
  0x0103 Heartbeat Threshold
  0x0104 Link Characteristics ACK Timer
  0x0180..0x019F (Standard metrics)
  0x01A0..0x01FF (Vendor-Extension metrics)

Detached Peer Discovery Message (message-block-TLVs)
  0x02 TYPE: Detached_Peer_Discovery + Identification + Version
  0x0201 Peer Type
  0x0202 Heartbeat Interval
  0x0203 Heartbeat Threshold
  0x0204 Link Characteristics ACK Timer
  0x0280..0x029F (Standard metrics)
  0x02A0..0x02FF (Vendor-Extension metrics)

Peer Offer Message (message-block-TLVs)
  0x03 TYPE: Peer_Offer + Identification + Version + Status
  0x0301 Peer Type
  0x0302 Heartbeat Interval
  0x0303 Heartbeat Threshold
  0x0304 Link Characteristics ACK Timer
  0x0380..0x039F (Standard metrics)
  0x03A0..0x03FF (Vendor-Extension metrics)

Peer Update Message (message-block-TLVs)
  0x04 TYPE: Peer_Update + Identification + Version
  0x0401 Peer Type
  0x0411 IPv4 Address
  0x0412 IPv6 Address
  0x0480..0x049F (Standard metrics)
  0x04A0..0x04FF (Vendor-Extension metrics)
  
Peer Update ACK Message (message-block-TLVs)
  0x05 TYPE: Peer_Update_ACK + Identification + Status

Peer Termination Message (message-block-TLVs)
  0x06 TYPE: Peer_Termination + Identification + Status

Peer Termination ACK Message (message-block-TLVs)
  0x07 TYPE: Peer_Termination_ACK + Identification + Status

Peer Heartbeat Message (message-block-TLVs)
  0x08 TYPE: Peer_Heartbeat + Identification

Neighbour Up Message (address-block-TLVs)
  0x01 TYPE: Neighbour_Up + Identification
  0x0101 Credit Window Status
  0x0111 IPv4 Address
  0x0112 IPv6 Address
  0x0180..0x019F (Standard metrics)
  0x01A0..0x01FF (Vendor-Extension metrics)

Neighbour Up ACK Message (address-block-TLVs)
  0x02 TYPE: Neighbour_Up_ACK + Identification + Status
  0x0201 Credit Window Status
  
Neighbour Down Message (address-block-TLVs)
  0x03 TYPE: Neighbour_Down + Identification + Status

Neighbour Down ACK Message (address-block-TLVs)
  0x04 TYPE: Neighbour_Down_ACK + Identification + Status

Neighbour Update Message (address-block-TLVs)
  0x05 TYPE: Neighbour_Update + Identification
  0x0501 Credit Window Status
  0x0502 Credit Grant
  0x0503 Credit Request
  0x0580..0x059F (Standard metrics)
  0x05A0..0x05FF (Vendor-Extension metrics)

Neighbour Address Update Message (address-block-TLVs)
  0x07 TYPE: Neighbour_Address_Update + Identification
  0x0711 IPv4 Address
  0x0712 IPv6 Address

Neighbour Address Update ACK Message (address-block-TLVs)
  0x08 TYPE: Neighbour_Address_Update_ACK + Identification + Status

Link Characteristics Request Message (address-block-TLVs)
  0x09 TYPE: Link_Characteristics_Request + Identification
  0x0980..0x099F (Standard metrics)
  0x09A0..0x09FF (Vendor-Extension metrics)

Link Characteristics ACK Message (address-block-TLVs)
  0x0A TYPE: Link_Characteristics_ACK + Identification
  0x0A80..0x0A9F (Standard metrics)
  0x0AA0..0x0AFF (Vendor-Extension metrics)

---

From: Henning Rogge <[email-masked]>
Date: Thu, 26 Apr 2012 12:29:25 +0200

> Yes, as 'normal' TLVs, they can go wherever they are needed as currently

The current draft specifies all of them as "subtlvs"... but the 
definition of normal TLVs (either message or address TLVs) would be 
quite similar.

> As Teco says, layer 3 address TLVs should be optional.

Yes.

> the modem does not know, but DLEP can still function.

I think it will even be the normal case that the modem/radio does not 
know the layer-3 address. But if its known, DLEP should contain a way to 
deliver that information to the router.

Henning Rogge

---

From: "Rick Taylor" <[email-masked]>
Date: Thu, 26 Apr 2012 11:32:09 +0100

Henning,

> packet/message, the binary content or both?

I would just outline "Neighbour Address Update", as it will describe
clearly how the address TLV's and the MAC address-blocks suggested
encodings would work.

(Given the addresses are just TLVs, I have yet to see why the two
messages can't be collapsed into one...)

Rick Taylor

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 26 Apr 2012 10:44:22 +0000

I'm afraid I'm not going to be able to comment on this immediately, but thanks to Rick for this.

-----Original Message-----
From: Rick Taylor [mailto:[email-masked]] 
Sent: 26 April 2012 11:29
To: Dearlove, Christopher (UK); Stan Ratliff; Ulrich Herberg
Cc: [email-masked]; Bo Berry
Subject: [manet] DLEP and TLV breakdown

Chris,

reported, to
all

Agreed.  

Rick Taylor

KEY:

---

From: Abdussalam Baryun <[email-masked]>
Date: Thu, 26 Apr 2012 13:26:01 +0200

Hi Stan,

I agree that we should not force the 5444 on DLEP as the draft-authors
think, so we can solve important and simple problems first. However, I
need to be sure of your position on the below views, so I can get
progress in reading manet-dlep-02.

HR>As I see it, the current draft describes five parts of DLEP.
- router-radio Session establishment (and teardown).
- transportation of known neighbors from radio to router (optional
with known IP. addresses) - transportation of metric data from radio
to router.
- controlling the link characteristics of the radio by the router.
- traffic shaping on the radio with a token scheme by the router.

AB> yes, I feel that I understood the same

UH>I thought that this idea has already been abandoned and replaced by

AB> IMO it is easy to update to make 5444 become more welcoming of
more scenarios, but difficult to get focused drafts that solve an
important-scenario while being depending on specifc standards. that is
why we can leave this update after solving small problems first (i.e.
making DLEP work in its use-scenarion independently of other standards
as much as possible).

>I think that any attempt to force MAC addresses into 5444 address blocks for >DLEP *only* (at least it's only DLEP at this time) is basically trying to ram a >square peg into a round hole - with a sufficiently large sledge-hammer, "anything is >possible". My concern all along with doing that is that we end up with a one-off, >and I'm strongly opposed to that. IMO, the way to address it "properly" is >with "RFC 5444 bis"., and I don't see any energy to do that.

AB> IMO we should not mix between the draft ideas and RFC5444 only if
necessary to solve the specific-picture-problem, for now I don't see
any necessary reason only the attempt to solve the big picture
problem. Furthermore, 5444 is for messages for controlling distributed
entities of peer to peer routing standards/protocols, not messages for
controlling modems by upper-layer entities standards/protocols.

Abdussalam Baryun,

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 26 Apr 2012 11:30:04 +0000

Abdussalam Baryun <[email-masked]>
> 5444 is for messages for controlling distributed

5444 is for anyone who wants to use it. 5498 mandates its use on the manet UDP port or IP protocol, but otherwise it's a take it or leave it thing.

---

From: Henning Rogge <[email-masked]>
Date: Thu, 26 Apr 2012 13:40:23 +0200

> - traffic shaping on the radio with a token scheme by the router.

Good.

I still think we can do all of this with RFC 5444, and even do it in a 
less complex manner than the current draft describes without loosing any 
functionality or feature.

(I am working on an example RFC 5444 Neighbor Update message at the moment)

Henning Rogge

---

From: Teco Boot <[email-masked]>
Date: Thu, 26 Apr 2012 14:16:37 +0200

> it's possible, but a PITA, particularly as InARP is largely unsupported

The .!!!!-problem is mainly caused by address resolving on non-transit links.
On transit links, a good router populates forwarding tables when there is
a data path set up. ARP/NDP is enough for this and additional time required 
for it is minor related to routing protocol convergence in many cases.

Teco

---

From: Henning Rogge <[email-masked]>
Date: Thu, 26 Apr 2012 14:45:30 +0200

> messages can't be collapsed into one...)

I tried to write down an example for a "neighbor update" event in DLEP, 
with both address, neighbor and metric changes. Please view this message 
with a constant width font, otherwise you will not see the structure.

Its a neighbor update from radio 01:00:00:00:00:01 about neighbor 1
(02:00:00:00:00:01) and neighbor 2 (02:00:00:00:00:02).

Neighbor 1 has the IP address 10.0.0.1, lost the IP address 10.0.0.2
and the current outgoing link speed is 1 mbit/s.
Neighbor 2 dropped of the network since the last neighbor update.

=======================================
"RFC 5444 compatible" logical structure
=======================================

Packet
|
+ Message (type DLEP, 6 byte addresses,
   |        originator 01:00:00:00:00:01, sequence number 1234)
   + DLEP_ORDER_TLV (ext-type: "neighbor update")
   |
   + Address Block (2 addresses, no head/tail/prefix
     |
     + Address 1 (mid: 02:00:00:00:00:01)
     | |
     | + LINK_STATUS TLV (value "heard")
     | |
     | + ADDRESS_TLV (value "10.0.0.1")
     | |
     | + ADDRESS_TLV (ext-type: "lost", value "10.0.0.1")
     | |
     | + RAW_METRIC_TLV (ext-type: "tx bitrate", value 1000000)
     |
     + Address 2 (mid: 02:00:00:00:00:02)
       |
       + LINK_STATUS_TLV (value "lost")

======================================
"RFC 5444 compatible" binary structure
======================================

packet header:
00               version 0, no sequence number, no TLVs

message header:
66               message type DLEP
                  (assumption: DLEP-message type = 0x66)
95               address length 6, has originator and sequence number
0044             size of message including header: 68 bytes
010000000001     originator of message: 01:00:00:00:00:01
1234             sequence number 1234

tlv-block:
0003             message TLV block length excluding header = 3

tlv:
c0               TLV type DLEP_ORDER_TLV
                  (assumption: DLEP_ORDER_TLV = 0xc0)
80               has value
77               type extension ORDER_NEIGHBOR_UPDATE
                  (assumption: ORDER_NEIGHBOR_UPDATE = 0x77)

address-block:
02               2 addresses
00               no special flags, no compression
020000000001     address 1: 02:00:00:00:00:01
020000000002     address 2: 02:00:00:00:00:02

tlv-block:
0023             address TLV block length excluding header = 35

tlv:
03               TLV type LINK_STATUS (see RFC 6130)
14               has value, has multivalue
02               TLV length 2 (1 for each value
02               TLV value for address 1: LOST (see RFC 6130)
00               TLV value for address 2: HEARD (see RFC 6130)

tlv:
c1               TLV type ADDRESS_TLV
                  (assumption: ADDRESS_TLV = 0xc1)
50               has single index, has value
01               TLV index 1
04               TLV length 4
10000001         TLV value 10.0.0.1

tlv:
c1               TLV type ADDRESS_TLV
                  (assumption: ADDRESS_TLV = 0xc1)
D0               has extension type, has single index, has value
01               Extension type: LOST
                  (assumption: LOST exttype = 0x01)
01               TLV index 1
04               TLV length 4
10000002         TLV value 10.0.0.2

tlv:
c2               TLV type RAW_METRIC_TLV
D0               has extension type, has single index, has value
01               Extension type: TX_BITRATE
                  (assumption: TX_BITRATE exttype = 0x01)
01               TLV index 1
08               TLV length 8
00000000000f4240 TLV value 1000000

===============================
DLEP-draft-02 logical structure
===============================

The current drafts seems to specifiy that a DLEP message
ontains one order (The protocol messages consist of a DLEP
order, encoded in the 'tlv-type' field in the message TLV
block, with the 'value' field of the TLV block containing
a collection (1 or more) DLEP sub-TLVs).

The current draft also specifies that the order of SubTLVs has
to follow some rules (Identification Sub-TLV must come first).

Packet
|
+ Message (type DLEP, 1 byte addresses)
| |
| + DLEP_NEIGHBOR_UPDATE_TLV
|   |
|   + Idenfification Sub-TLV
|   |
|   + MAC Address Sub-TLV: 02:00:00:00:00:01
|   |
|   + Current Data Rate Sub-TLV: 1000000
|
+ Message (type DLEP, 1 byte addresses)
| |
| + DLEP_NEIGHBOR_UP_TLV
|   |
|   + Identification Sub-TLV
|   |
|   + MAC Address Sub-TLV: 02:00:00:00:00:01
|   |
|   + IPv4 Address Sub-TLV: existing, 10.0.0.1
|   |
|   + IPv4 Address Sub-TLV: lost, 10.0.0.2
|
+ Message (type DLEP, 1 byte addresses)
   |
   + DLEP_NEIGHBOR_DOWN_TLV
     |
     + Identification Sub-TLV
     |
     + MAC Address Sub-TLV: 02:00:00:00:00:02

==============================
DLEP-draft-02 binary structure
==============================

packet header:
00               version 0, no sequence number, no TLVs

message header:
66               message type DLEP
                  (assumption: DLEP-message type = 0x66)
10               address length 0+1=1, has sequence number
002a             size of message including header 42
1234             sequence number 1234

tlv-block:
0022             message TLV block length excluding header = 34

tlv:
c0               TLV type DLEP_NEIGHBOR_UPDATE_TLV
                  (assumption: DLEP_NEIGHBOR_UPDATE_TLV = 0xc0)
10               has value
1f               TLV length 31

sub-tlv:
01               Subtlv type Identification
                  (assumption Identification = 0x01)
10               has length
08               Subtlv length 8
xxxxxxxx         Server ID xxxxxxxx
yyyyyyyy         Client ID yyyyyyyy

subtlv:
02               Subtlv type Mac Address
                  (assumption Mac Address = 0x02)
10               has length
06               Subtlv length 6
020000000001     Value: 02:00:00:00:00:01

subtlv:
03               Subtlv type Current Data Rate
                  (assumption Current Data Rate = 0x03)
10               has length
08               Subtlv length 8
00000000000f4240 Value: 1000000

message header:
66               message type DLEP
                  (assumption: DLEP-message type = 0x66)
10               address length 0+1=1, has sequence number
002f             size of message including header = 47
1235             sequence number 1235

tlv-block:
0027             message TLV block length excluding header = 39

tlv:
c1               TLV type DLEP_NEIGHBOR_UP_TLV
                  (assumption: DLEP_NEIGHBOR_UP_TLV = 0xc1)
10               has value
24               TLV length 36

sub-tlv:
01               Subtlv type Identification
                  (assumption Identification = 0x01)
10               has length
08               Subtlv length 8
xxxxxxxx         Server ID xxxxxxxx
yyyyyyyy         Client ID yyyyyyyy

subtlv:
02               Subtlv type Mac Address
                  (assumption Mac Address = 0x02)
10               has length
06               Subtlv length 6
020000000001     Value: 02:00:00:00:00:01

subtlv:
04               Subtlv type IPv4 Address
                  (assumption IPv4 Address = 0x04)
10               has length
05               Subtlv length 5
01               Existing(new) address
10000001         10.0.0.1

subtlv:
04               Subtlv type IPv4 Address
                  (assumption IPv4 Address = 0x04)
10               has length
05               Subtlv length 5
02               Lost address
10000002         10.0.0.2

message header:
66               message type DLEP
                  (assumption: DLEP-message type = 0x66)
10               address length 0+1=1, has sequence number
001f             size of message including header = 31
1236             sequence number 1236

tlv-block:
0017             message TLV block length excluding header = 23

tlv:
c2               TLV type DLEP_NEIGHBOR_DOWN_TLV
                  (assumption: DLEP_NEIGHBOR_UP_TLV = 0xc2)
10               has value
14               TLV length 20

sub-tlv:
01               Subtlv type Identification
                  (assumption Identification = 0x01)
10               has length
08               Subtlv length 8
xxxxxxxx         Server ID xxxxxxxx
yyyyyyyy         Client ID yyyyyyyy

subtlv:
02               Subtlv type Mac Address
                  (assumption Mac Address = 0x02)
10               has length
06               Subtlv length 6
020000000001     Value: 02:00:00:00:00:01

Henning Rogge

---

From: Bo Berry <[email-masked]>
Date: Thu, 26 Apr 2012 08:46:42 -0400

> 5444 is for anyone who wants to use it. 5498 mandates its use on the manet UDP port or IP protocol, but otherwise it's a take it or leave it thing.
and I believe that applies to the method and adoption of the various concepts defined by RFC 5444.

---

From: Henning Rogge <[email-masked]>
Date: Thu, 26 Apr 2012 14:52:57 +0200

Sorry,

found a bug in the description seconds after I sent it to the list (and 
after reading through it three times!).

Packet
|
     | + ADDRESS_TLV (ext-type: "lost", value "10.0.0.2")

packet header:

message header:
66               message type DLEP

tlv-block:

tlv:

address-block:
02               2 addresses

tlv-block:

tlv:
03               TLV type LINK_STATUS (see RFC 6130)
14               has value, has multivalue
02               TLV length 2 (1 for each value)
02               TLV value for address 1: HEARD (see RFC 6130)
00               TLV value for address 2: LOST (see RFC 6130)

tlv:
c1               TLV type ADDRESS_TLV

tlv:
c1               TLV type ADDRESS_TLV

tlv:

Packet
|

packet header:

message header:
66               message type DLEP

tlv-block:

tlv:

sub-tlv:

subtlv:

subtlv:

message header:
66               message type DLEP

tlv-block:

tlv:

sub-tlv:

subtlv:

subtlv:

subtlv:

message header:
66               message type DLEP

tlv-block:

tlv:

sub-tlv:

subtlv:

---

From: Abdussalam Baryun <[email-masked]>
Date: Thu, 26 Apr 2012 15:14:39 +0200

Hi Chris,

I thank you for your suggestions, I am new in the manet discussion not
sure about the rules. I am just trying to understand by adding the
below comments

>5444 is for anyone who wants to use it. 5498 mandates its use on the manet UDP >port or IP protocol, but otherwise it's a take it or leave it thing.

AB> I agree with the above only if the DLEP protocol is a P2P
communication protocol, but it is not exactly, it discovers
peer-neighbor-modems. From my reading the DLEP does not exchange
messages within UDP/IP stack, DLEP has its separate message
exchange-channel between entities-endpoints, and it may need a
separate UDP/IP port than 5498. I am not sure of this last two lines
:(

5444>page 3>This document specifies the syntax of a packet format designed for
>carrying multiple routing protocol messages for information exchange
>between MANET (Mobile Ad hoc NETwork) routers. Messages consist of a
>Message Header, which is designed for control of message
>dissemination, and a Message Body, which contains protocol
>information.

AB> therefore, RFC5444 is specified to messages-format for exchange
between routers. Therefore, if DLEP-neighbors are routers and they
want to exchange messages, then they must use 5444 format.

AB> IMO from the authors' discussions,  using 5444 is a way to help in
future work. However, the draft may leave it by not mentioning the
5444 format and still use it as DLEP message-format (e.g. used
DLEP-message-format in section 11), because in some formats it deals
with DLEP-server, and DLEP-client IDs, but it is not as 5444 dealing
with router-neighbour-peers' IDs.

CD>To be clear, the suggestion (which I think I would say has "consensus

HR>I think thats a correct and good description of the current suggestion.
>Would a "Neighbor Address Update" or "Neighbor Update" DLEP order okay for >this? And should the result contain the structure of the packet/message, the >binary content or both?

AB> I agree with your both points as long as it does not affect the
DLEP functions (not sure!). we need comments from draft's authors.

Abdussalam Baryun

---

From: Stan Ratliff <[email-masked]>
Date: Thu, 26 Apr 2012 09:42:34 -0400

Rick,

This shows one of the problems I'm having with "restructuring". Looks  
to me that "Credit WIndow Status" has at least 3 definitions:
  0x0101 Credit Window Status

>  0x0501 Credit Window Status

This is easier?

Regards,
Stan

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 26 Apr 2012 13:43:13 +0000

Not quite sure what you mean by that, and therefore don't know whether I agree or disagree with you.

---

From: Stan Ratliff <[email-masked]>
Date: Thu, 26 Apr 2012 09:47:46 -0400

On Apr 26, 2012, at 6:29 AM, Henning Rogge wrote:

> I think it will even be the normal case that the modem/radio does  
> not know the layer-3 address. But if its known, DLEP should contain  
> a way to deliver that information to the router.
>

And that's precisely why the address TLV's are part of "Peer Offer" -  
what we envisioned goes something like:
1. Modem sends Peer Discovery
2. Router responds with Peer Offer, *with* its (the router's) addresses.
3. Modem could strip out those TLV's, and treat them as opaque data -  
no cognizance of what they are, just knowledge that "when I get TLV  
blah, I need to save that info".
4. As part of radio synchronization, two radios exchange their opaque  
data.
5. A radio receiving such opaque data inserts it into a Neighbor  
Up..... and now you have end-to-end Layer 3 knowledge, without the  
radio needing to know very much at all.
6. If addresses change on the router (via configuration), the router  
sends Peer Update to its radio, when then re-transmits the opaque data  
to radio peers. That opaque data is inserted into Neighbor Update.

Regards,
Stan

---

From: Stan Ratliff <[email-masked]>
Date: Thu, 26 Apr 2012 09:51:09 -0400

> for it is minor related to routing protocol convergence in many cases.

Except that you inherently force a MANET into a single subnet in order  
for that to work. That's not the case in the networks I deploy.

Stan

---

From: Henning Rogge <[email-masked]>
Date: Thu, 26 Apr 2012 15:55:40 +0200

On 04/26/2012 03:42 PM, Stan Ratliff wrote:
> Rick,
>
> This shows one of the problems I'm having with "restructuring". Looks to
> me that "Credit WIndow Status" has at least 3 definitions:

No, it is not.

And it is also not necessary, neither for subtlvs nor for real ones. One 
TLV-type (some of them with extension) for each type of data should be 
enough.

 > sends Peer Update to its radio, when then re-transmits the opaque
 > data to radio peers. That opaque data is inserted into Neighbor
 > Update.

Okay, that is something that wasn't clear to me from your draft.

I would disagree that this information is totally opaque for the Modem, 
because it has to know which TLV it has to parse/synchronize. But 
putting address fields into the "Peer Offer" message is an interesting idea.

Thats why I am 'drilling' a lot for this 'why is the usecase behind X' 
things. Because without knowing this details, a lot protocol design 
decisions seem to be pointless.

Henning Rogge

---

From: Stan Ratliff <[email-masked]>
Date: Thu, 26 Apr 2012 10:02:23 -0400

On Apr 26, 2012, at 9:55 AM, Henning Rogge wrote:

> And it is also not necessary, neither for subtlvs nor for real ones.  
> One TLV-type (some of them with extension) for each type of data  
> should be enough.
>
> I would disagree that this information is totally opaque for the  
> Modem, because it has to know which TLV it has to parse/synchronize.  
> But putting address fields into the "Peer Offer" message is an  
> interesting idea.

Not really. It just has to know that TLV '0x54' is something to be  
cached, and what the overall length of it is. then than '0x54' TLV  
gets lobbed at the radio partner, who knows to insert it into a  
Neighbor Up (or Update).... no Layer 3 address parsing/cognizance  
expressed or implied.

>
> Thats why I am 'drilling' a lot for this 'why is the usecase behind  
> X' things. Because without knowing this details, a lot protocol  
> design decisions seem to be pointless.
>

And the reason I'm reluctant to spell out some of these things is that  
I get requests to make them *part of the draft*. This is some of the  
innovation behind DLEP. I think we have to walk a very fine line here  
- enough in the spec to guarantee interoperability between modems and  
routers, but not so much that we stifle innovation. So while I'm OK  
with explaining what the motivation was, I'm going to be extremely  
reluctant to insert that into the draft - again, I think the mode  
should be that DLEP specifies what data is transferred between modem  
and router, and how it's formatted. What is actually *done* with the  
data once received is out of scope.

Stan

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 26 Apr 2012 14:05:28 +0000

You could present the motivation as an example of use. Example should make it clear it's not the only option.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Stan Ratliff
Sent: 26 April 2012 15:02
To: Henning Rogge
Cc: [email-masked]
Subject: Re: [manet] DLEP and TLV breakdown

Stan

---

From: "Rick Taylor" <[email-masked]>
Date: Thu, 26 Apr 2012 15:28:45 +0100

Stan,

> From: Stan Ratliff [mailto:[email-masked]]
> 

I'm afraid I am doing bit-twiddling here: Hi-byte = Message Type,
Lo-Byte is always 0x01 = Credit Window Status.

TLV type indicates message (what Henning calls his Type TLV)
Extension types (lo-bytes) give Stan's Sub-TLV.  This is a more
efficient representation than Henning's, but carries the same
information.

All I was trying to do was map Stan's Sub-TLV model into RFC5444 by
using extension types.

Rick Taylor

---

From: Stan Ratliff <[email-masked]>
Date: Thu, 26 Apr 2012 10:47:46 -0400

I thought that would have been intuitively obvious to even the casual  
observer... But since you asked, I speak as a co-author and editor of  
the DLEP draft.

Stan

On Apr 25, 2012, at 4:18 PM, Teco Boot wrote:

>> First off, splitting DLEP into multiple specs is a REALLY bad idea.  
>> If we did that, there wouldn't be ANY place where the protocol, in  
>> its entirety, is documented. IMO, that makes it more difficult to  
>> implement, and more difficult to ensure interoperability. Next,  
>> I've explained the reasoning behind the flow control on more than  
>> one occasion - it was put in due to *specific requests*, both on  
>> and off-list, by members of the WG. It's consistent with RFC 5578.  
>> And, IT IS OPTIONAL. Don't like it? Simple. Then DON'T IMPLEMENT  
>> IT. Same thing goes  for the addresses - as has been said before,  
>> reliance on other protocols like ARP slows down the process. It  
>> also makes the underlying assumption that *everything* one router/ 
>> radio pair attaches to is in the same subnet - because IIRC, ARP  
>> gets discarded when subnets don't match. With this OPTIONAL (again,  
>> if you don't like it, then don't implement it) approach, the  
>> appropriate ARP caches can be populated when they're needed,  
>> irrespective of subnet masks. Provided, of course, the modem  
>> (radio) already has cognizance of the far-end's address(es).
>>
>> spec, and only ONE to remove it. Operating under the "Rough  
>> consensus and working code" model, I'd say that up to this  
>> juncture, we have "rough consensus" to KEEP flow control in the  
>> document.
>>
>> Stan
>>
>>
>>

---

From: Stan Ratliff <[email-masked]>
Date: Thu, 26 Apr 2012 10:52:39 -0400

> efficient representation than Henning's, but carries the same

Since the protocol is intended to *only* traverse the local (typically  
Ethernet) link between modem and local router, I admit that efficiency/ 
compression wasn't one of the goals. As for simplicity, it seems  
easier to me to just pick the Type value up and directly feed it into  
state machinery instead of needing to perform some sort of "bit-level  
gymnastics" on it prior.

Regards,
Stan

---

From: Henning Rogge <[email-masked]>
Date: Thu, 26 Apr 2012 16:54:14 +0200

Even for links that are bandwidth constraint, using the context of the
message to see what the TLV is about is a better choice. Repeating the
order-number over and over for each TLV is just bad.

Henning Rogge

On Thu, Apr 26, 2012 at 16:52, Stan Ratliff <[email-masked]> wrote:
> Ethernet) link between modem and local router, I admit that
> efficiency/compression wasn't one of the goals. As for simplicity, it seems
> easier to me to just pick the Type value up and directly feed it into state
> machinery instead of needing to perform some sort of "bit-level gymnastics"
> on it prior.
>
> Regards,
> Stan
>
>

---

From: Stan Ratliff <[email-masked]>
Date: Thu, 26 Apr 2012 11:01:07 -0400

And in those cases, it's easy to fall prey to the notion that a  
certain piece of data (e.g. Maximum Data Rate) winds up being  
allocated from multiple number spaces. And that's a bad thing.

Stan

---

From: "Rick Taylor" <[email-masked]>
Date: Thu, 26 Apr 2012 16:03:59 +0100

All,

Having read and digested Henning's suggestion, may I propose a hybrid
between his and my model:

As before:

"I tried to write down an example for a "neighbor update" event in DLEP,

Neighbor 1 has the IP address 10.0.0.1, lost the IP address 10.0.0.2
and the current outgoing link speed is 1 mbit/s.
Neighbor 2 dropped of the network since the last neighbor update."

Packet
|
+ Message (type DLEP, 6 byte addresses,
   |        originator 01:00:00:00:00:01, sequence number 1234)
   |
   + Message Block 
   | |
   | + IDENT_TLV (value "server_id, client_id")
   |
   + Address Block (2 addresses, no head/tail/prefix
     |
     + Address 1 (mid: 02:00:00:00:00:01)
     | |
     | + ADDRESS_DROP_TLV (ext-type: "IPv4",
     | |                   value "10.0.0.2")
     | |
     | + METRIC_TLV (ext-type: "CDR",
     |               value 1000000)
     |
     + Address 2 (mid: 02:00:00:00:00:02)
       |
       + NEIGHBOUR_DOWN_TLV ()

=======================================
And now a Peer Offer message. This demonstrates the use of extension
types to connect optional TLVs to their 'parent' TLV, much like Stan's
Sub-TLV concept, but using the ext-type instead.

Packet
|
+ Message (type DLEP, 6 byte addresses,
   |        originator 01:00:00:00:00:01, sequence number 1234)
   |
   | (No Address Blocks!)
   |
   + Message Block 
     |
     + IDENT_TLV (value "server_id, client_id")
     |
     + PEER_OFFER_TLV (value "server_id, version")
     |
     + PEER_OFFER_EX_TLV (type: PEER_OFFER_TLV,
     |                    ext-type: PEER_TYPE_SUBTLV,
     |                    value: "Fancy DLEP Modem")
     |
     + PEER_OFFER_EX_TLV (type: PEER_OFFER_TLV,
     |                    ext-type: HBEAT_INTERVAL_SUBTLV,
     |                    value: "3")
     |
     + PEER_OFFER_EX_TLV (type: PEER_OFFER_TLV,
     |                    ext-type: HBEAT_THRESHOLD_SUBTLV,
     |                    value: "5")
     |
     + PEER_OFFER_EX_TLV (type: PEER_OFFER_TLV,
                          ext-type: METRICS_MDR_SUBTLV,
                          value: "5000000")

Rick Taylor

---

From: "Rick Taylor" <[email-masked]>
Date: Thu, 26 Apr 2012 16:12:25 +0100

Stan,

> allocated from multiple number spaces. And that's a bad thing.

That's exactly what I was trying to avoid.  I'm basically suggesting
using the <ext-type> as the draft-02 <Sub-TLV-type>, and the <type> as
Henning's Order-Number TLV value.

I agree that compression is largely a pointless exercise, unless these
packets are broadcast as 'opaque' blobs by the radios as per your
previous example.

I was just hoping to avoid a situation where it is decided that DLEP
needs to fit RFC5444 "better", and the final result ends up being too
unusual/weird/complex.

Rick Taylor

---

From: Henning Rogge <[email-masked]>
Date: Thu, 26 Apr 2012 17:12:49 +0200

Thats why a "raw metric TLV" from the global namespace (both message
and address TLV) might be a good thing. It gives other protocols the
standardized tools to work with too.

Henning Rogge

On Thu, Apr 26, 2012 at 17:01, Stan Ratliff <[email-masked]> wrote:
> And in those cases, it's easy to fall prey to the notion that a certain
> piece of data (e.g. Maximum Data Rate) winds up being allocated from
> multiple number spaces. And that's a bad thing.
>
> Stan
>
>
>>> state

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 26 Apr 2012 15:15:11 +0000

I suggest first working out what the TLVs you want are, then considering whether to make them message specific or global later.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Henning Rogge
Sent: 26 April 2012 16:13
To: Stan Ratliff
Cc: Dearlove, Christopher (UK); [email-masked]; Bo Berry
Subject: Re: [manet] DLEP and TLV breakdown

Henning Rogge

---

From: Henning Rogge <[email-masked]>
Date: Thu, 26 Apr 2012 17:14:57 +0200

> Henning's Order-Number TLV value.

The question is WHY?

Just skip the order TLV id in the other TLVs. Its enough to store the
order TLV at one place in the message (for example the order TLV I
suggested). Thats enough to understand the rest of the message.

Henning

---

From: Henning Rogge <[email-masked]>
Date: Thu, 26 Apr 2012 17:23:05 +0200

I think TX/RX current and maximum datarate are examples for "raw
metrics" as opposed to the "dimensionless metric" TLV from OLSRv2.

Other things I would like to have are Signal Strength, Radio Frequency
(especially to reuse the TLV for the Request Link Characteristics
order!) and maybe some layer-2 statistics that are
difficult/impossible to get from the router.

Henning

---

From: "Rick Taylor" <[email-masked]>
Date: Thu, 26 Apr 2012 16:25:08 +0100

> From: Henning Rogge [mailto:[email-masked]]
> 

I was trying to allow more than 1 order per message.  But on reflection, one could just use more than 1 message per packet.

So, you are suggesting:

1) In the message-block and/or each address-block in the DLEP message, there is 1 ORDER_TLV.  (Is this right for Address-Blocks?)
2) Every other TLV in the block refers to the order described by the ORDER_TLV.
3) If there is no ORDER_TLV, or more than 1 ORDER_TLV, the block is discarded.

I think you might be convincing me... 

Rick Taylor

---

From: Henning Rogge <[email-masked]>
Date: Thu, 26 Apr 2012 17:27:55 +0200

> 1) In the message-block and/or each address-block in the DLEP message, there is 1 ORDER_TLV.  (Is this right for Address-Blocks?)
The order TLV will be a Message-TLV... and there will be only one of
them in a DLEP message.

> 2) Every other TLV in the block refers to the order described by the ORDER_TLV.
Every other TLV in the message (both message TLVs and address TLVs
refers to the order described in the Order TLV.

> 3) If there is no ORDER_TLV, or more than 1 ORDER_TLV, the block is discarded.
the message is discarded.

Henning Rogge

---

From: "Rick Taylor" <[email-masked]>
Date: Thu, 26 Apr 2012 16:29:13 +0100

The current draft specifies:

* Current Data Rate,
* Maximum Data Rate,
* Latency,
* Expected Transmission Time,

And some slightly 'fluffy' values:
* Relative Link Quality
* Resources

I can understand how some DLEP consumers like having a dimensionless metric 'Relative Link Quality', but I am against having more than 1 dimensionless 'soft' metric to choose from.

Rick Taylor

> Sent: 26 April 2012 16:23
> Cc: [email-masked]; Bo Berry; Stan Ratliff
> > I suggest first working out what the TLVs you want are, then considering
> whether to make them message specific or global later.
> >
> > --
> > Christopher Dearlove
> Of Henning Rogge

---

From: Teco Boot <[email-masked]>
Date: Thu, 26 Apr 2012 17:32:02 +0200

Op 26 apr. 2012, om 15:51 heeft Stan Ratliff het volgende geschreven:

> Except that you inherently force a MANET into a single subnet in order for that to work. That's not the case in the networks I deploy.

With IPv6 NDP this is not a problem.
With ARP, AFAIK Cisco routers do not permit address resolving over different subnets. It is not a limitation of the ARP spec. But yes, there are problems here. It was discussed in Autoconf. How is it solved when not using DLEP?

Teco

---

From: Henning Rogge <[email-masked]>
Date: Thu, 26 Apr 2012 17:32:19 +0200

> The current draft specifies:
Both are okay... but they are not necessarily the same for
transmission and reception.

And there might be an interest in the multicast data rate too.

> * Expected Transmission Time,

Not sure what is even the difference between this two.

> And some slightly 'fluffy' values:
This is already in the OLSRv2 draft as a dimensionless metric value.
We should reuse the TLV concept.

> * Resources

I can see the reason behind this, this might fit the "raw metric"
better... because it has a defined meaning, its about how long your
device will still operate until it goes offline.

> I can understand how some DLEP consumers like having a dimensionless metric 'Relative Link Quality', but I am against having more than 1 dimensionless 'soft' metric to choose from.

Yes, having multiple dimensionless metrics could be a crazy thing.

Henning Rogge

---

From: "Rick Taylor" <[email-masked]>
Date: Thu, 26 Apr 2012 16:34:28 +0100

> > 1) In the message-block and/or each address-block in the DLEP message,
> there is 1 ORDER_TLV.  (Is this right for Address-Blocks?)

+1  

I'm sold on this.  Forget my bit-twiddling suggestions, this is much simpler.

Rick Taylor

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 26 Apr 2012 15:34:35 +0000

The way that 5444 allocation is defined, it's natural to pick a TLV type, which automatically requires you get IANA to set up a registry for all 256 type extensions. Define some, let a few be private/experimental at the end of the range, and pick a policy for allocation of the rest. Expert Review may be good there, maintains some control (so they aren't all frivolously allocated) but doesn't require even an ID, let alone an RFC or full IESG approval. Then the initial DLEP specification can have a set you can get consensus that they are a good idea.

Note that there are radios that are used to carry IP packets that span half a dozen orders of magnitude of user data rate. You might want more than one type extension there, and possibly elsewhere.

-----Original Message-----
From: Henning Rogge [mailto:[email-masked]] 
Sent: 26 April 2012 16:23
To: Dearlove, Christopher (UK)
Cc: Stan Ratliff; [email-masked]; Bo Berry
Subject: Re: [manet] DLEP and TLV breakdown

Henning

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 26 Apr 2012 15:41:14 +0000

If you are using DLEP under the multiplexing model defined in 5444 Appendix A (non-normative there, but required by 5498 on manet port/protocol - which I'm not clear if you are using) then DLEP doesn't own packets, and doesn't own the delivery of messages from the packet handler. What that means is that it would be strongly advisable (at the least) for separate messages to be able to be handled independently. Which may well be the case.

Note that you do have the option of multiple address blocks, and nothing in 5444 mandates anything about ordering. So it would be 5444 compatible (but I'm not recommending it) to have N copies of a certain TLV in the message TLV block and say the first copy relates to the first address block, the second copy relates to the second address block etc. (If I'm not recommending it, why am I mentioning it? Mainly just to point out that there is quite a lot of freedom in 5444.)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Rick Taylor
Sent: 26 April 2012 16:25
To: Henning Rogge
Cc: Dearlove, Christopher (UK); [email-masked]; Bo Berry; Stan Ratliff
Subject: Re: [manet] DLEP and TLV breakdown

So, you are suggesting:

Rick Taylor

---

From: Henning Rogge <[email-masked]>
Date: Thu, 26 Apr 2012 17:43:19 +0200

The RFC5444 writer API I am using is splitting up address blocks if it
gets you a more compact compression. Doing it by hand can be difficult
to tune...

Henning

---

From: Stan Ratliff <[email-masked]>
Date: Thu, 26 Apr 2012 11:43:59 -0400

On Apr 26, 2012, at 11:32 AM, Teco Boot wrote:

>>>>> Its still okay to carry them in Address-Block TLVs, to bind them  
>>>>> to
>>>> the
>> Except that you inherently force a MANET into a single subnet in  
>> order for that to work. That's not the case in the networks I deploy.
>
> With ARP, AFAIK Cisco routers do not permit address resolving over  
> different subnets. It is not a limitation of the ARP spec. But yes,  
> there are problems here. It was discussed in Autoconf. How is it  
> solved when not using DLEP?
>

WIthout DLEP, it's *not* solved. That is the point. Or rather, the  
point of including the address TLV's.

Stan

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 26 Apr 2012 16:13:49 +0000

The intelligence of your 5444 formatter is a potential quality of implementation differentiator. I concentrate more on intelligent ordering than intelligent splitting (including whether to use single or multi value TLVs - or both) but as you note, splitting can help . However if you know that you'll never have more than 255 addresses in one "message" and you aren't that fussed about efficiency, then you could split for other reasons. Just to be clear, neither NHDP nor OLSRv2 use splitting (or ordering) to carry information.

-----Original Message-----
From: Henning Rogge [mailto:[email-masked]] 
Sent: 26 April 2012 16:43
To: Dearlove, Christopher (UK)
Cc: Rick Taylor; [email-masked]; Bo Berry; Stan Ratliff
Subject: Re: [manet] DLEP and TLV breakdown

Henning

---

From: Henning Rogge <[email-masked]>
Date: Thu, 26 Apr 2012 18:18:24 +0200

I don't think any sane protocol should use address block splitting to
define a syntax. Its just a tool to allow for more flexible ways to
write the addresses.

My implementation does not switch the order of the TLVs (I assume that
the implementation has most likely insider knowledge how to order
them) and it does the whole splitting (and reading in the parser) in a
transparent way. You never see it in the code.

Henning

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 26 Apr 2012 16:28:59 +0000

I would regard address block splitting to define information as poor, but better than separate messages with linkages between them (which is a lot worse than poor). Separate but independent messages is OK.

-----Original Message-----
From: Henning Rogge [mailto:[email-masked]] 
Sent: 26 April 2012 17:18
To: Dearlove, Christopher (UK)
Cc: Rick Taylor; [email-masked]; Bo Berry; Stan Ratliff
Subject: Re: [manet] DLEP and TLV breakdown

Henning

---

From: Henning Rogge <[email-masked]>
Date: Thu, 26 Apr 2012 18:31:05 +0200

I totally agree.

Henning

---

From: Stan Ratliff <[email-masked]>
Date: Thu, 26 Apr 2012 14:10:47 -0400

I'm glad *some of us* are sold... ;-)

I still can't get past the notion that this approach requires the  
allocation of a TLV into TWO number spaces. All of the address and  
metric TLV's can currently exist at the Peer (radio-wide) level, AND  
for an individual neighbor. As I understand the proposal, Peer level  
traffic (Peer Discovery, Peer Offer, Peer Update) would be encoded as  
5444 message TLV's. Neighbor-specific traffic (Neighbor Up, Neighbor  
Update, Neighbor Down) would be referencing a specific neighbor,  
therefore, it would be address TLV's...

So, we'd have to create TWO registries (one for DLEP message TLV's,  
another for DLEP address TLV's), and make sure at least metrics and  
addresses are in BOTH of them. I'm sorry, but that's just silly to me.

Stan

On Apr 26, 2012, at 11:34 AM, Rick Taylor wrote:

>> On Thu, Apr 26, 2012 at 17:25, Rick Taylor  
>> <[email-masked]>
>> wrote:
>>>
>>> So, you are suggesting:
>>>

---

From: Henning Rogge <[email-masked]>
Date: Thu, 26 Apr 2012 20:19:03 +0200

On Thu, Apr 26, 2012 at 20:10, Stan Ratliff <[email-masked]> wrote:
> I still can't get past the notion that this approach requires the allocation
> of a TLV into TWO number spaces. All of the address and metric TLV's can
> currently exist at the Peer (radio-wide) level, AND for an individual
> neighbor. As I understand the proposal, Peer level traffic (Peer Discovery,
> Peer Offer, Peer Update) would be encoded as 5444 message TLV's.
> Neighbor-specific traffic (Neighbor Up, Neighbor Update, Neighbor Down)
> would be referencing a specific neighbor, therefore, it would be address
> TLV's...

Yes. So what?

> So, we'd have to create TWO registries (one for DLEP message TLV's, another
> for DLEP address TLV's), and make sure at least metrics and addresses are in
> BOTH of them. I'm sorry, but that's just silly to me.

Its common stuff in the IETF, for example with RFC 5444 involved. Its
reasonable to have this kind of TLVs for routing protocols that are
layer-2 aware.

If we go (as Christopher suggested some time ago) the way of a
"specific metric" TLV, you could have one message TLV for the metrics,
one address TLV for them... and use the same extension type registry
for them.

Some other TLVs might even be useful for the global address space. If
we have a TLV for attaching an address of different length to an
existing address in RFC 5444, I could see this quite useful for a
dual-stack OLSRv2 implementation. A similar thing is true for the
'Maximum Link speed' TLV, this could be quite useful in multi-topology
routing to choose paths for high-bandwidth links.

Henning Rogge

---

From: Stan Ratliff <[email-masked]>
Date: Thu, 26 Apr 2012 14:29:56 -0400

On Apr 26, 2012, at 2:19 PM, Henning Rogge wrote:

>> allocation

So what? You want to put the same TLV in 2 different registries, then  
tell me that's simpler?

>> another

No, I haven't seen this as a "common" approach. It's a bad idea.

Stan

---

From: Ulrich Herberg <[email-masked]>
Date: Thu, 26 Apr 2012 11:30:43 -0700

Stan,

On Thu, Apr 26, 2012 at 11:10 AM, Stan Ratliff <[email-masked]> wrote:

> allocation of a TLV into TWO number spaces. All of the address and metric
> TLV's can currently exist at the Peer (radio-wide) level, AND for an
> individual neighbor. As I understand the proposal, Peer level traffic (Peer
> Discovery, Peer Offer, Peer Update) would be encoded as 5444 message TLV's.

Yes, that is exactly what we did for all the other drafts/RFCs in MANET,
for example, for the packetbb-sec RFC-to-be. I think it is wise to use the
same TLV types for packet/message/address-block TLVs. Setting up registries
is trivial and does not complicate code.

Regards
Ulrich

---

From: Stan Ratliff <[email-masked]>
Date: Thu, 26 Apr 2012 14:32:39 -0400

On Apr 26, 2012, at 2:30 PM, Ulrich Herberg wrote:

> traffic (Peer Discovery, Peer Offer, Peer Update) would be encoded  
> as 5444 message TLV's. Neighbor-specific traffic (Neighbor Up,  
> Neighbor Update, Neighbor Down) would be referencing a specific  
> neighbor, therefore, it would be address TLV's...
>
> Yes, that is exactly what we did for all the other drafts/RFCs in  
> MANET,  for example, for the packetbb-sec RFC-to-be. I think it is  
> wise to use the same TLV types for packet/message/address-block  
> TLVs. Setting up registries is trivial and does not complicate code.
>

I disagree - it does complicate things. Both code-wise, and  
administratively. The fact that it's been done before means little to  
me.

Stan

---

From: Ulrich Herberg <[email-masked]>
Date: Thu, 26 Apr 2012 11:35:29 -0700

Stan,

why should it complicate things? Have a look at the MANET regsitry:
http://www.iana.org/assignments/manet-parameters/manet-parameters.xml#message-type-ranges

We have VALIDITY_TIME and INTERVAL_TIME, as well as the newer ICV and
TIMESTAMP TLVs as message and as address block TLVs. I have implemented
NHDP/OLSRv2 and packetbb-sec. Assuming that the TLV types are the same
(which I hope they will be for packetbb-sec ;-), there is no more code
complexity. I have implemented the different TLVs only once.

Regards
Ulrich

On Thu, Apr 26, 2012 at 11:32 AM, Stan Ratliff <[email-masked]> wrote:

> administratively. The fact that it's been done before means little to me.
>
> Stan
>
>
> Regards
> Ulrich
>
>
>

---

From: Henning Rogge <[email-masked]>
Date: Thu, 26 Apr 2012 20:36:34 +0200

There is a reason why IANA always allocated the same code value for
both address and message TLVs where they applied to both. I think they
will keep doing so, because it keeps things easy.

It seems no problem for writing the drafts (as you can see in the
existing drafts) and I know from personal experience it does NOT
complicate the code of your program.

So where is your problem?

Henning

---

From: Ulrich Herberg <[email-masked]>
Date: Thu, 26 Apr 2012 11:37:22 -0700

P.S. Administratively, that is trivial. Just an email to IANA once the
draft is in the RFC Editor Queue. We are going through that process right
now with packetbb-sec.

---

From: Stan Ratliff <[email-masked]>
Date: Thu, 26 Apr 2012 14:52:44 -0400

Why does it complicate things?
As you said - "Assuming that the TLV types are the same..."  Not only  
now, but on down the line if/when we want to add TLVs? You can  
guarantee that will always be the case?

Stan

On Apr 26, 2012, at 2:35 PM, Ulrich Herberg wrote:

> We have VALIDITY_TIME and INTERVAL_TIME, as well as the newer ICV  
> and TIMESTAMP TLVs as message and as address block TLVs. I have  
> implemented NHDP/OLSRv2 and packetbb-sec. Assuming that the TLV  
> types are the same (which I hope they will be for packetbb-sec ;-),  
> there is no more code complexity. I have implemented the different  
> TLVs only once.
>
> Regards
> Ulrich
>

---

From: Stan Ratliff <[email-masked]>
Date: Thu, 26 Apr 2012 14:54:36 -0400

> So where is your problem?

See the earlier response to Ulrich. Multiple allocations in multiple  
number spaces is a bad idea. The fact that it has been done before  
doesn't help me - by extension, I could use that same argument to say  
"People have successfully shop-lifted before. Ergo, shop-lifting is  
OK." Doesn't work for me.

Stan

---

From: Henning Rogge <[email-masked]>
Date: Thu, 26 Apr 2012 20:55:49 +0200

Adding something proprietary like "subtlvs" is a lot worse. Its an
additional dimension for the registries and for the parser/generator.

Henning Rogge

On Thu, Apr 26, 2012 at 20:52, Stan Ratliff <[email-masked]> wrote:
> As you said - "Assuming that the TLV types are the same..."  Not only now,
> but on down the line if/when we want to add TLVs? You can guarantee that
> will always be the case?
>
> Stan
>

---

From: Stan Ratliff <[email-masked]>
Date: Thu, 26 Apr 2012 14:57:09 -0400

BTW - according to a quick read by one of my co-authors, , ICV and  
TIMESTAMP TLVs have different type values for packet/message/address  
TLVs. How does that simplify things?

Stan

---

From: Stan Ratliff <[email-masked]>
Date: Thu, 26 Apr 2012 14:58:32 -0400

And I guess that's the crux of the subjective crossroads we find  
ourselves at. At least with the sub-TLV's, you always know that CDR is  
CDR, because it's only defined once.

Stan

On Apr 26, 2012, at 2:55 PM, Henning Rogge wrote:

>>> MANET,

---

From: Ulrich Herberg <[email-masked]>
Date: Thu, 26 Apr 2012 12:00:56 -0700

Stan,

I think you should have been in CC of some mails between the authors of
packetbb-sec and IANA. I suggested to IANA to use the same values instead.
They requested confirmation by the chairs. The registration process for
packetbb-sec is not yet finished, so that can still be changed.

Regards
Ulrich

On Thu, Apr 26, 2012 at 11:57 AM, Stan Ratliff <[email-masked]> wrote:

> TIMESTAMP TLVs have different type values for packet/message/address TLVs.
> How does that simplify things?
>
> Stan
>

---

From: Henning Rogge <[email-masked]>
Date: Thu, 26 Apr 2012 21:02:19 +0200

The problem is that SubTLVs are the start of duplicating things.
Because if we define useful TLVs as subtlvs, we cannot reuse them
elsewhere.

But I think thats not even the important point.

We did quite a lot of work to get RFC5444 to the current state, and
now we don't want to use it because of the registries involved? Whats
the use of a generic and flexible packet format if protocols start
using it just as a wrapper for proprietary stuff?

Henning Rogge

On Thu, Apr 26, 2012 at 20:58, Stan Ratliff <[email-masked]> wrote:
> And I guess that's the crux of the subjective crossroads we find ourselves
> at. At least with the sub-TLV's, you always know that CDR is CDR, because
> it's only defined once.
>
> Stan
>
>
>>> now,

---

From: Ulrich Herberg <[email-masked]>
Date: Thu, 26 Apr 2012 12:03:42 -0700

> but on down the line if/when we want to add TLVs? You can guarantee that

I cannot guarantee that. But IANA / an Expert Review can and should do
that. If we wanted to change the way of the message / address block TLV
registrations, we would need to obsolete or update RFC5444 and all RFCs
based on it.

Best regards
Ulrich

---

From: Stan Ratliff <[email-masked]>
Date: Thu, 26 Apr 2012 15:06:34 -0400

Ulrich,

JMO, but that just makes my point - this is "easier"? Having to check  
& double-check to make sure some poor individual in IANA gets the  
allocations matched up correctly?

Stan

On Apr 26, 2012, at 3:00 PM, Ulrich Herberg wrote:

> Stan,
>
> I think you should have been in CC of some mails between the authors  
> of packetbb-sec and IANA. I suggested to IANA to use the same values  
> instead. They requested confirmation by the chairs. The registration  
> process for packetbb-sec is not yet finished, so that can still be  
> changed.
>
> Regards
> Ulrich
>
>
>

---

From: Thomas Heide Clausen <[email-masked]>
Date: Thu, 26 Apr 2012 23:02:09 +0200

Actually, I think that it's more precise to say that we've requested that IANA allocate the same values for the same mnemonics, and that they're waiting for the designated experts (which, currently, is the WG chairs) to OK that.

In the interest of seeing packetbb-sec move ahead, would it be possible to get you to OK that request to IANA?

Best,

Thomas

-- 
Thomas Heide Clausen
http://www.thomasclausen.org/

"Any simple problem can be made insoluble if enough meetings are held to
 discuss it."
   -- Mitchell's Law of Committees

On 26 Apr 2012, at 21:00, Ulrich Herberg <[email-masked]> wrote:

> Stan,
> 
> I think you should have been in CC of some mails between the authors of packetbb-sec and IANA. I suggested to IANA to use the same values instead. They requested confirmation by the chairs. The registration process for packetbb-sec is not yet finished, so that can still be changed.
> 
> Regards
> Ulrich
> 
> 
> 
> BTW - according to a quick read by one of my co-authors, , ICV and TIMESTAMP TLVs have different type values for packet/message/address TLVs. How does that simplify things?
> 
> Stan
> 
>> We have VALIDITY_TIME and INTERVAL_TIME, as well as the newer ICV and TIMESTAMP TLVs as message and as address block TLVs. I have implemented NHDP/OLSRv2 and packetbb-sec. Assuming that the TLV types are the same (which I hope they will be for packetbb-sec ;-), there is no more code complexity. I have implemented the different TLVs only once.
>> 
>> Regards
>> Ulrich
>> 
>>> Yes, that is exactly what we did for all the other drafts/RFCs in MANET,  for example, for the packetbb-sec RFC-to-be. I think it is wise to use the same TLV types for packet/message/address-block TLVs. Setting up registries is trivial and does not complicate code.
>>> 
>> 
>> I disagree - it does complicate things. Both code-wise, and administratively. The fact that it's been done before means little to me.
>> 
>> Stan
>> 
>> 
>>> Regards
>>> Ulrich
>>> 
>>> 
>>>

---

From: Thomas Heide Clausen <[email-masked]>
Date: Thu, 26 Apr 2012 23:13:41 +0200

Stan,

I'm not Ulrich, but I am one of the authors of RFC5444.

In RFC5444, Packet-TLVs, Message-TLVs and Address-block-TLVs are different entities, doing different things and applying in different contexts. Therefore, there are different registries for these. 

It's therefore not a matter of "registering the same thing multiple times". Rather, it's merely a convenience if the same mnemonic maps to the same numerical value, regardless of in which context it's used.

If IANA does not get things "matched up correctly", that doesn't break things - but generally, vigilant designated experts and attentive working-groups should be able to keep registries sane and safe ;)

Best,

Thomas

On 26 Apr 2012, at 21:06, Stan Ratliff <[email-masked]> wrote:

> Ulrich, 
> 
> JMO, but that just makes my point - this is "easier"? Having to check & double-check to make sure some poor individual in IANA gets the allocations matched up correctly?
> 
> Stan
>

---

From: Teco Boot <[email-masked]>
Date: Fri, 27 Apr 2012 09:06:50 +0200

Op 26 apr. 2012, om 17:43 heeft Stan Ratliff het volgende geschreven:

> WIthout DLEP, it's *not* solved. That is the point. Or rather, the point of including the address TLV's.

It is a problem in your boxes. Can be fixed, using something similar to Linux's arp_ignore sysctl. Then, it always works. Without dependency on DLEP and radio's support for this address resolving feature, which is good. ARP is a standard protocol and there is running code around.

Teco

---

From: Teco Boot <[email-masked]>
Date: Fri, 27 Apr 2012 09:14:55 +0200

> I can understand how some DLEP consumers like having a dimensionless metric 'Relative Link Quality', but I am against having more than 1 dimensionless 'soft' metric to choose from.

It is not about dimensionless or not. It is about semantics. RLQ is something like RSSI / loss ratio and resources could be battery/CPU/memory levels, or coins in the pocket. Yes, having more than one semantics_free dimensionless metric doesn't make sense.

Teco

---

From: "Rick Taylor" <[email-masked]>
Date: Fri, 27 Apr 2012 09:38:54 +0100

> > I can understand how some DLEP consumers like having a dimensionless
> metric 'Relative Link Quality', but I am against having more than 1
> dimensionless 'soft' metric to choose from.
> 
> It is not about dimensionless or not. It is about semantics. RLQ is
> something like RSSI / loss ratio and resources could be
battery/CPU/memory
> levels, or coins in the pocket. Yes, having more than one
semantics_free
> dimensionless metric doesn't make sense.
> 

+1  (Agreeing with myself)

Rick Taylor

---

From: Henning Rogge <[email-masked]>
Date: Fri, 27 Apr 2012 10:43:26 +0200

> +1  (Agreeing with myself)

Maybe we could allocate one of the type extensions of the link metric 
address-tlv from OLSRv2 for DLEP?

Henning Rogge

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Fri, 27 Apr 2012 08:47:19 +0000

It is essential to the metric type agnosticism of OLSRv2 that all type extensions of the selected type use the same encoding, which no one is suggesting for DLEP. So. no, DLEP can't have one.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Henning Rogge
Sent: 27 April 2012 09:43
To: [email-masked]
Subject: Re: [manet] DLEP and TLV breakdown

Henning Rogge

---

From: Henning Rogge <[email-masked]>
Date: Fri, 27 Apr 2012 10:50:42 +0200

Am 27.04.2012 10:47, schrieb Dearlove, Christopher (UK):
> It is essential to the metric type agnosticism of OLSRv2 that all
> type extensions of the selected type use the same encoding, which no
> one is suggesting for DLEP. So. no, DLEP can't have one.

I think it might be a good idea to use the same encoding as OLSRv2.

But I see this can be controversial.

Still, it might be a nice idea to allow DLEP radios to deliver a 
dimensionless encoding in OLSRv2 encoded form.

Henning Rogge

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Fri, 27 Apr 2012 08:51:49 +0000

I'm sorry, that makes no sense to me. You want a complicated mess of sub-TLVs and a less clear and efficient message just because you don't want similar address and message TLVs? Something we both already do and designed for?

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Stan Ratliff
Sent: 26 April 2012 19:11
To: Rick Taylor
Cc: Dearlove, Christopher (UK); [email-masked]; Bo Berry
Subject: Re: [manet] DLEP and TLV breakdown

Stan

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Fri, 27 Apr 2012 08:55:43 +0000

Whether the actual numbers are the same is not really something that matters, it's a minor convenience. But INTERVAL_TIME and VALIDITY_TIME in 5497 which are message and address TLVs, have the same number.

[email-masked]<mailto:[email-masked]> | http://www.baesystems.com

From: Stan Ratliff [mailto:[email-masked]]
Sent: 26 April 2012 19:57
To: Ulrich Herberg
Cc: Dearlove, Christopher (UK); [email-masked]; Bo Berry
Subject: Re: [manet] DLEP and TLV breakdown

*** WARNING ***
This message originates from outside our organisation, either from an external partner or the internet.
Keep this in mind if you answer this message.
Please see this process<http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Dealing%20With%20Suspicious%20Emails.pdf> on how to deal with suspicious emails.
BTW - according to a quick read by one of my co-authors, , ICV and TIMESTAMP TLVs have different type values for packet/message/address TLVs. How does that simplify things?

Stan

Stan,

Regards
Ulrich
On Thu, Apr 26, 2012 at 11:32 AM, Stan Ratliff <[email-masked]<mailto:[email-masked]>> wrote:

Stan

Regards
Ulrich

_______________________________________________
manet mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/manet

---

From: "Rick Taylor" <[email-masked]>
Date: Fri, 27 Apr 2012 09:55:41 +0100

> dimensionless encoding in OLSRv2 encoded form.

-1   I'm with Chris on this one.  

I don't want to see DLEP tied closely to OLSRv2.  I suggest a different
dimensionless "Relative Link Quality" remain in DLEP as a fallback for
interoperability with existing routing protocols (OLSR and EIGRP can
both use it without much modification)

Rick Taylor

---

From: Teco Boot <[email-masked]>
Date: Fri, 27 Apr 2012 11:05:59 +0200

> both use it without much modification)

The dimensionless metric is not tied to any routing protocol, I think.
RLQ has semantics and range is far to restrictive. For RSSI it is OK.

When having the dimensionless metric, high values would be bad / slow /
high delay / costly / etc. links.

Teco

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Fri, 27 Apr 2012 09:07:20 +0000

To be precise (and I think this is just refining my agreement with Rick) OLSRv2 wants a set all coded the same. From the OLSRv2 side it then is fine for anything (e.g. DLEP) to use those, as long as no changes are made. But from the DLEP side this isn't the primary purpose of DLEP. It would however be a trivial addition to specify what we might call "DLEP for OLSRv2" to add it. But if anyone wants to create such a thing, a separate draft that extends DLEP to say "DLEP can also carry the link metrics defined by OLSRv2" (no doubt turned into several pages of text) could be written. If anyone wants that, they can write it. And in the meanwhile DLEP doesn't couple unnecessarily to OLSRv2.

(If you were using DLEP with OLSRv2, the question would be where to put the intelligence that converts real world metrics to additive routing metrics. If in the router, DLEP has no need to know anything about OLSRv2. If in the radio then DLEP for OLSRv2 makes sense. But I can't see any point - or any manufacturer likelihood to support - that being in the radio. It would I think have to be a different use of DLEP, not simply router-radio use.)

-----Original Message-----
From: Rick Taylor [mailto:[email-masked]] 
Sent: 27 April 2012 09:56
To: Henning Rogge; Dearlove, Christopher (UK)
Cc: [email-masked]
Subject: RE: [manet] DLEP and TLV breakdown

Rick Taylor

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Fri, 27 Apr 2012 09:13:22 +0000

Sorry, the argument has descended  further than it should go at this point. And as an author of 5497 it's being suggested I was engaged in something that's being compared with shoplifting.

(Actually the addition of address TLVs for these times was added at the request of the DYMO authors, who at that time thought they'd have a use for it. It's not needed by NHDP/OLSRv2. But I wouldn't be an author if I thought it was inappropriate. And the need for packet/message versions of cryptographic TLVs, especially for signatures, is clear. I would venture to suggest if that isn't understood then the whole packet/message approach of 5444 isn't understood.)

-----Original Message-----
From: Stan Ratliff [mailto:[email-masked]] 
Sent: 26 April 2012 19:55
To: Henning Rogge
Cc: Dearlove, Christopher (UK); [email-masked]; Bo Berry
Subject: Re: [manet] DLEP and TLV breakdown

Stan

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Fri, 27 Apr 2012 09:34:48 +0000

It's not entirely subjective. Hands up those who have written 5444 parsing code, don't have any problems with different TLV spaces, and would find sub-TLVs much more complicated.

My hand is up.

-----Original Message-----
From: Stan Ratliff [mailto:[email-masked]] 
Sent: 26 April 2012 19:59
To: Henning Rogge
Cc: Ulrich Herberg; Dearlove, Christopher (UK); [email-masked]; Bo Berry
Subject: Re: [manet] DLEP and TLV breakdown

Stan

---

From: "Rick Taylor" <[email-masked]>
Date: Fri, 27 Apr 2012 10:54:37 +0100

I think we are mostly in agreement that the current DLEP draft-02 RLQ is
a useful metric.

As I understand it, the 'meaning' of RLQ is:

"If you understand no other metric but this, RLQ gives you an idea of
the quality of a link as a percentage of the ideal quality."

Rick Taylor

> From: Teco Boot [mailto:[email-masked]]
> Sent: 27 April 2012 10:06
> To: Rick Taylor
> Cc: Henning Rogge; Dearlove, Christopher (UK); [email-masked]

---

From: "Rick Taylor" <[email-masked]>
Date: Fri, 27 Apr 2012 10:59:17 +0100

> It's not entirely subjective. Hands up those who have written 5444
parsing
> code, don't have any problems with different TLV spaces, and would
find
> sub-TLVs much more complicated.
> 
> My hand is up.

My hand is half-way.  I have a production-grade parser.  Sub-TLV's are
just TLV payload, no more or less complex.

My *only* objection to TLV's is 'elegance'.  I see no noticeable
implementation complexity difference in any of the proposals or draft-02
formats.  In reality, parsing is not the most complex part of network
I/O software.

---

From: Thomas Heide Clausen <[email-masked]>
Date: Fri, 27 Apr 2012 12:32:38 +0200

> It's not entirely subjective. Hands up those who have written 5444 parsing code, don't have any problems with different TLV spaces, and would find sub-TLVs much more complicated.

Ok, since you ask, I've implemented not one, but two 5444 parsers (in two different languages on two different platforms), and I never even thought of the different TLV spaces as being problematic (they're for different kind of TLVs, so fell quite naturally).

I'm not sure I understand the sub-TLVs quite right (or rather: I hope that I dont since if I do then it's definitely quite complicated....)

So my hand is up with Chris' (actually, as I've implemented 5444-parsers twice, can I raise both hands, please?)

Thomas

---

From: Thomas Heide Clausen <[email-masked]>
Date: Fri, 27 Apr 2012 12:34:05 +0200

> formats.  In reality, parsing is not the most complex part of network

Well, that _does_ depend on what platform you're targeting, really, specifically how (in-)efficient you can afford being with memory.

---

From: Henning Rogge <[email-masked]>
Date: Fri, 27 Apr 2012 12:37:46 +0200

> formats.  In reality, parsing is not the most complex part of network

My hand is up, too.

I have a parser and a generator that can multiplex and demultiplex 
RFC5444 for different "interested parties" (for example my OLSRv2 code 
will be able to add TLVs to NHDP Hello messages without changing the 
NHDP code).

But sub-tlvs will be another layer of complexity, especially because the 
order of the subtlvs seems to make a difference!

Henning Rogge

---

From: "Rick Taylor" <[email-masked]>
Date: Fri, 27 Apr 2012 12:09:39 +0100

I think we are in danger of letting the tail wag the dog here.

The best DLEP spec will result in specifying what needs to be there by analysing the use-cases and taking into account transport characteristics.  Not how easy it makes implementers jobs.  Obviously, specifying something totally wacky is never a good idea, but really, what is the difference between...

Packet                        AND     Packet
|                                     |
+-Message                             +-Message
  |                                     |
  +-DLEP_TLV                            +-DLEP_ORDER_TLV
    |                                   |
    +-SubTLV_1                          +-DLEP_TLV_1
    |                                   |
    +-SubTLV_2                          +-DLEP_TLV_2
    :                                   :

...as far as the parser is concerned?  From my perspective, Stan's Sub-TLV's are possibly easier to integrate into an existing parser than having to maintain the state at the message processing level in Henning's model.

The problem with Stan's SubTLV model is not really with the SubTLV's (RFC5444 allows any data in a TLV) but with the administrivia of having a new Sub-TLV registry.

Rick Taylor

> Sent: 27 April 2012 11:38
> To: [email-masked]

---

From: Henning Rogge <[email-masked]>
Date: Fri, 27 Apr 2012 13:15:38 +0200

On 04/27/2012 01:09 PM, Rick Taylor wrote:
> The best DLEP spec will result in specifying what needs to be there
> by analysing the use-cases and taking into account
> transportcharacteristics. Not how easy it makes implementers jobs.
> Obviously, specifying something totally wacky is never a good idea, but
> really, what is the difference between...
>
> Packet                        AND     Packet
> |                                     |
> +-Message                             +-Message
>    |                                     |
> ...as far as the parser is concerned? From my perspective, Stan's
> Sub-TLV's are possibly easier to integrate into an existing parser than
> having to maintain the state at the message processing level in
> Henning's model.

With a generic parser you don't have to integrate anything new for the 
right one. You just add a few numbers to an array of "TLVs you are 
interested in".

No additional byte parsing code necessary.

I would not even notice if the DLEP_ORDER_TLV is the last TLV in the 
list of message TLVs.

I plan to use the same parser for NHDP, OLSRv2 and DLEP in the coming 
olsr.org (v2) implementation. Having something special for DLEP is just 
bad and unnecessary.

Henning Rogge

---

From: Bo Berry <[email-masked]>
Date: Fri, 27 Apr 2012 07:17:42 -0400

+1

> 
> The best DLEP spec will result in specifying what needs to be there by analysing the use-cases and taking into account transport characteristics.  

+1

> Not how easy it makes implementers jobs.  Obviously, specifying something totally wacky is never a good idea, but really, what is the difference between...

+1

----
[email-masked]

---

From: Bo Berry <[email-masked]>
Date: Fri, 27 Apr 2012 07:23:59 -0400

On Apr 27, 2012, at 7:15 AM, Henning Rogge wrote:

> With a generic parser you don't have to integrate anything new for the right one. You just add a few numbers to an array of "TLVs you are interested in".
> 
> I would not even notice if the DLEP_ORDER_TLV is the last TLV in the list of message TLVs.
> 
> I plan to use the same parser for NHDP, OLSRv2 and DLEP in the coming olsr.org (v2) implementation. Having something special for DLEP is just bad and unnecessary.

From your perspective I can understand that position.  But there are others that have diff parsers, diff protocols, diff radios, networks, etc.  Ricks' caution is a good one.

----
[email-masked]

---

From: Henning Rogge <[email-masked]>
Date: Fri, 27 Apr 2012 13:26:45 +0200

>  From your perspective I can understand that position.  But there are others that have diff parsers, diff protocols, diff radios, networks, etc.  Ricks' caution is a good one.

My point is that with RFC 5444 (without subtlvs) one option needs 
additional byte-juggling code, and the other does not (the one with a 
generic RFC 5444 parser).

The subtlv option needs always additional byte-juggling code.

Henning Rogge

---

From: Bo Berry <[email-masked]>
Date: Fri, 27 Apr 2012 07:29:30 -0400

On Apr 27, 2012, at 7:26 AM, Henning Rogge wrote:

> My point is that with RFC 5444 (without subtlvs) one option needs additional byte-juggling code, and the other does not (the one with a generic RFC 5444 parser).
> 

I understand your point.  What one considers byte=juggling in his/her parser may not be in anothers.  

----
[email-masked]

---

From: "Rick Taylor" <[email-masked]>
Date: Fri, 27 Apr 2012 12:34:03 +0100

> From: Henning Rogge [mailto:[email-masked]]
> 

Or, in a callback-based parser, with SubTLVs, in the
On_DLEP_TLV(id,data) function you just loop parsing SubTLVs, calling
On_DLEP_SubTLV().

It's all just how you write it.  And that shouldn't define the protocol.

> I would not even notice if the DLEP_ORDER_TLV is the last TLV in the

But you would have to record that you had pending DLEP_TLVs waiting for
an order.

I like your ORDER_TLVs, but I think they are a potential solution to the
SubTLV registry problem, not an implementation aid.

> olsr.org (v2) implementation. Having something special for DLEP is
just

I'm all in favour of code reuse.  A generic parser is one of the ideals
of RFC5444, but your generic parser is different from my generic parser.

The problem is DLEP has optional and mandatory 'parameters' to each
'order', this is 'special' when compared to OLSRv2 (as far as I
understand) already.  The discussion is how do we handle this
'special-ness' in the simplest way, without RFC5444bis or adding excess
state to any parser.

Rick Taylor

---

From: Henning Rogge <[email-masked]>
Date: Fri, 27 Apr 2012 13:42:10 +0200

> It's all just how you write it.  And that shouldn't define the protocol.

no, it doesn't work this way... because the parser would have to be 
aware that it is a TLV which contains subtlvs, which cannot be detected 
in the generic case.

> But you would have to record that you had pending DLEP_TLVs waiting for

No, I do not. I don't parse the TLVs in my protocol code in the order 
they are in the message.

I set up a static array where I define which TLVs I am interested in and 
the parser fills up the existing TLVs into this array. This means I get 
all the tlvs of message level at once, instead of getting them piece by 
piece.

Makes parsing things a lot easier.

See 
http://olsr.org/git/?p=framework.git;a=tree;f=src-api/packetbb;h=5bc637e8522633fc2704ff12597e6383d45f3799;hb=master

I still have to update the documentation for the latest change (which 
has to do with registering the used address-TLVs), but most of the 
documentation is okay.

http://olsr.org/git/?p=framework.git;a=tree;f=docs/packetbb;h=0e4c3ee1f30530718b53759a8c7d60ec7c20d27f;hb=master

Henning Rogge

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Fri, 27 Apr 2012 12:55:23 +0000

I think the diff parsers etc. misses the point. If DLEP is to use 5444 then having a 5444 parser may be taken as the starting point. And without sub-TLVs that's all the parser you need.

I'm afraid I think this is a clear case of design using 5444 without really appreciating it. And then when people who have greater familiarity with 5444 suggest what is a more natural use of 5444, meeting a resistance that may be based on several things, but offering a better fit to 5444 and better parsing options are not among those things.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Bo Berry
Sent: 27 April 2012 12:24
To: Henning Rogge
Cc: [email-masked]
Subject: Re: [manet] DLEP and TLV breakdown

----
[email-masked]

---

From: Henning Rogge <[email-masked]>
Date: Fri, 27 Apr 2012 15:31:38 +0200

> I think the diff parsers etc. misses the point. If DLEP is to use 5444 then having a 5444 parser may be taken as the starting point. And without sub-TLVs that's all the parser you need.

Exactly.

Yes.

At the moment DLEP is not using RFC5444 at all... except as a wrapper
around its own format. And everything DLEP does at the moment can be
expressed in a reasonable way within RFC5444.

Henning Rogge

---

From: dsatterw <[email-masked]>
Date: Fri, 27 Apr 2012 10:17:29 -0400

I personally have an issue at this stage of the game (we are now on our 3rd
version of DLEP) of having to completely rewrite our packet format so that
it better integrates into RFC5444. At this point we have at least 4 working
implementations of DLEP out there which were all based on our sourceforge
example of a packet parser that seems sufficient for the ones involved. If
we, at this point, decide to rewrite the packet formats then everyone that
has working versions today would have work to do without really any benefit
IMO. If this objection were brought up in the 00 or 01 version of the draft
it would be a little easier to accept than year(s) later. To be quite
honest, I don't think DLEP fits well in RFC5444 in the first place. RFC5444
states that it should be used by routing protocols for information exchange
and DLEP is not a routing protocol. I would really rather spend our time
trying to make sure that the content being exchanged between the radio and
router is adequate than arguing about packet parsers.

Darryl Satterwhite
Cisco Systems

On 4/27/12 9:31 AM, "Henning Rogge" <[email-masked]> wrote:

>> I think the diff parsers etc. misses the point. If DLEP is to use 5444 then
>> having a 5444 parser may be taken as the starting point. And without sub-TLVs
>> that's all the parser you need.
> 
> Exactly.
> 
>> I'm afraid I think this is a clear case of design using 5444 without really
>> appreciating it. And then when people who have greater familiarity with 5444
>> suggest what is a more natural use of 5444, meeting a resistance that may be
>> based on several things, but offering a better fit to 5444 and better parsing
>> options are not among those things.
> 
> Yes.
>

---

From: Stan Ratliff <[email-masked]>
Date: Fri, 27 Apr 2012 10:26:49 -0400

Thomas,

Yes, I agree with that. What I was discussing was an earlier comment  
that the multiple registries somehow "made the code easier". I don't  
buy that.

Regards,
Stan

On Apr 26, 2012, at 5:13 PM, Thomas Heide Clausen wrote:

> In RFC5444, Packet-TLVs, Message-TLVs and Address-block-TLVs are  
> different entities, doing different things and applying in different  
> contexts. Therefore, there are different registries for these.
>
> It's therefore not a matter of "registering the same thing multiple  
> times". Rather, it's merely a convenience if the same mnemonic maps  
> to the same numerical value, regardless of in which context it's used.
>
> If IANA does not get things "matched up correctly", that doesn't  
> break things - but generally, vigilant designated experts and  
> attentive working-groups should be able to keep registries sane and  
> safe ;)
>
> Best,
>
> Thomas
>
> -- 
> Thomas Heide Clausen
>> JMO, but that just makes my point - this is "easier"? Having to  
>> check & double-check to make sure some poor individual in IANA gets  
>> the allocations matched up correctly?
>>
>> Stan
>>
>>> I think you should have been in CC of some mails between the  
>>> authors of packetbb-sec and IANA. I suggested to IANA to use the  
>>> same values instead. They requested confirmation by the chairs.  
>>> The registration process for packetbb-sec is not yet finished, so  
>>> that can still be changed.
>>>
>>> Regards
>>> Ulrich
>>>
>>>
>>>
>>> TIMESTAMP TLVs have different type values for packet/message/ 
>>> address TLVs. How does that simplify things?
>>>
>>> Stan
>>>
>>>> types are the same (which I hope they will be for packetbb- 
>>>> sec ;-), there is no more code complexity. I have implemented the  
>>>> different TLVs only once.
>>>>
>>>> Regards
>>>> Ulrich
>>>>
>>>>> Yes, that is exactly what we did for all the other drafts/RFCs  
>>>>> in MANET,  for example, for the packetbb-sec RFC-to-be. I think  
>>>>> it is wise to use the same TLV types for packet/message/address- 
>>>>> block TLVs. Setting up registries is trivial and does not  
>>>>> complicate code.
>>>>>
>>>>

---

From: Ulrich Herberg <[email-masked]>
Date: Fri, 27 Apr 2012 07:35:18 -0700

My hand is up, too.

Ulrich

---

From: Henning Rogge <[email-masked]>
Date: Fri, 27 Apr 2012 16:36:26 +0200

On Fri, Apr 27, 2012 at 16:17, dsatterw <[email-masked]> wrote:
> it would be a little easier to accept than year(s) later.

DLEP-00 did not even contain the concept of subtlvs.

But I must admit that I missed the introduction of subtlvs in DLEP-01.
I only noticed them again when I tried to start to implement DLEP-02
and found out, that it defined its own byte format.

> router is adequate than arguing about packet parsers.

I disagree completely.

DLEP is mostly presenting data about layer2 that reminds me very
strong to what NHDP is presenting (just a layer higher).

The structure of RFC5444 with messages that contain both message-level
information and multiple addresses with attached information is
fitting very well to the concept of DLEP. Thats not a guess from my
side, I implemented a RFC5444-compatible DLEP protocol (at least the
session and metric part) in the last month to test it.

Also RFC5444 would make it very easy to extend DLEP later without
breaking compatibility quite a lot. At the moment DLEP use some of the
mechanisms of RFC5444 without realizing what you can do with them.

One example is the "Relative Link Quality Sub-TLV" and its 'default'.
I understand the need of default values in protocol with a fixed
header format, but its quite useless for TLV-based packet formats. Why
using a dual-meaning encoding (perfect link = I cannot measure it?)
when you just can drop the TLV from the message to tell the
application "cannot calculate it"?

But I agree, that the communication at the start of DLEP could have
been better. From both sides.

Henning Rogge

---

From: Ulrich Herberg <[email-masked]>
Date: Fri, 27 Apr 2012 07:44:56 -0700

I totally agree with Chris. I think he said in a previous email , "take it or leave it". Not using RFC5444 in DLEP would be acceptable for me, but if it uses it, then it should use it correctly. It has been pointed out by several of the authors of RFC5444 as well as by several implementers how to do that. I don't understand the resistance. There seems to be a rough concensus on that in the WG (besides by the authors), and the draft is a WG draft, not an individual draft.

Ulrich

---

From: Ulrich Herberg <[email-masked]>
Date: Fri, 27 Apr 2012 07:49:27 -0700

Darryl,

I don't believe that to be an argument. I still believe the WG should do its best job to come up with  the best solution. DLEP is a WG document and uses RFC5444, but not correctly. That worries me, and the only real counter-argument to the suggested changes so far has been "we have an existing implementation and don't want to change it.".

Ulrich

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Fri, 27 Apr 2012 14:59:50 +0000

I believe the context for "take it or leave it" (which might otherwise be misunderstood) was that 5444 is provided on a take it or leave it basis. And although as an author of 5444 I find it gratifying when anyone wants to use it, I would always say that 5444 is good for some things and less good for others. However I do think that if used then more value is gained if it is used in some ways rather than others.

(The only place where 5444 is other than optional is as described in 5498, but I don't think we are discussing that protocol/port.)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ulrich Herberg
Sent: 27 April 2012 15:45
To: Dearlove, Christopher (UK)
Cc: [email-masked]; Bo Berry
Subject: Re: [manet] DLEP and TLV breakdown

Ulrich

---

From: Ulrich Herberg <[email-masked]>
Date: Fri, 27 Apr 2012 07:59:51 -0700

P.S To clarify my last email...

On Apr 27, 2012, at 7:44, Ulrich Herberg <[email-masked]> wrote:

> I totally agree with Chris. I think he said in a previous email , "take it or leave it". Not using RFC5444 in DLEP would be acceptable for me,

Well, as Henning pointed out, I also believe that RFC5444 is very suitable for DLEP. So, not using it is just one notch above in my preference of using it as it is used currently. Really, I would prefer to use it as discussed by Henning, Chris, etc.

Ulrich

> but if it uses it, then it should use it correctly. It has been pointed out by several of the authors of RFC5444 as well as by several implementers how to do that. I don't understand the resistance. There seems to be a rough concensus on that in the WG (besides by the authors), and the draft is a WG draft, not an individual draft.
> 
> Ulrich
>

---

From: Ulrich Herberg <[email-masked]>
Date: Fri, 27 Apr 2012 08:01:43 -0700

+1

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Fri, 27 Apr 2012 15:22:02 +0000

I believe I understand both this point of view and the point of view that says we should do things "right". Understanding two points of view is always difficult as it leaves you not sure what you think should happen next.  I would suggest that this might be the point where our disinterested (*) WG chair, and responsible AD might need to express an opinion. Unfortunately I don't think any way forward is ideal, but that's life.

(*) Correct usage, not uninterested. Not sure there's anything MANET-related Joe's uninterested in.

-----Original Message-----
From: dsatterw [mailto:[email-masked]] 
Sent: 27 April 2012 15:17
To: Henning Rogge; Dearlove, Christopher (UK)
Cc: [email-masked]; Bo Berry
Subject: Re: [manet] DLEP and TLV breakdown

Darryl Satterwhite
Cisco Systems

---

From: Ulrich Herberg <[email-masked]>
Date: Fri, 27 Apr 2012 08:33:18 -0700

+1

---

From: Ulrich Herberg <[email-masked]>
Date: Fri, 27 Apr 2012 09:07:18 -0700

P.S. My tone may have been a little strong in that email, apologies. I
think it is great to have implementations of the standards we come up in
MANET, even more so if there are several of them. But I think as a WG we
should do the right thing and make sure that our standards, such as
RFC5444, are used in the intended and ideal way. And some DLEP
implementations (e.g. Henning's) seem to use RFC5444 Message-TLVs and
address blocks already, so there is also proof that this works (and does
not require to modify the RFC5444 parser).

Ulrich (probably my last email on the subject)

On Fri, Apr 27, 2012 at 7:49 AM, Ulrich Herberg <[email-masked]> wrote:

> Darryl,
>
> I don't believe that to be an argument. I still believe the WG should do
> its best job to come up with  the best solution. DLEP is a WG document and
> uses RFC5444, but not correctly. That worries me, and the only real
> counter-argument to the suggested changes so far has been "we have an
> existing implementation and don't want to change it.".
>
> Ulrich
>

---

From: dsatterw <[email-masked]>
Date: Fri, 27 Apr 2012 12:25:27 -0400

Ulrich,

You point is taken and I didn¹t take it in a negative way. I just wish we
could have had this lively discussion when reviewing DLEP 01 not DLEP 02.

At this point I think its very clear the 2 possible directions we can
proceed. I think its time for the DLEP author and co-authors to have a chat
and decide where to go from here.

- Darryl

On 4/27/12 12:07 PM, "Ulrich Herberg" <[email-masked]> wrote:

> P.S. My tone may have been a little strong in that email, apologies. I think
> it is great to have implementations of the standards we come up in MANET, even
> more so if there are several of them. But I think as a WG we should do the
> right thing and make sure that our standards, such as RFC5444, are used in the
> intended and ideal way. And some DLEP implementations (e.g. Henning's) seem to
> use RFC5444 Message-TLVs and address blocks already, so there is also proof
> that this works (and does not require to modify the RFC5444 parser).
> 
>> I don't believe that to be an argument. I still believe the WG should do its
>> best job to come up with  the best solution. DLEP is a WG document and uses
>> RFC5444, but not correctly. That worries me, and the only real

---

From: Henning Rogge <[email-masked]>
Date: Fri, 27 Apr 2012 18:32:35 +0200

On Fri, Apr 27, 2012 at 18:25, dsatterw <[email-masked]> wrote:
> Ulrich,
>
> You point is taken and I didn’t take it in a negative way. I just wish we
Sorry for triggering this discussion that late. I always had the 'need
to build a DLEP agent' on my personal hobby list, but looking into it
only became part of my job at work in late March.

I have talked with quite a few people who tried to use the "radio to
router" extension for PPPoE, and none of them were happy about it. We
need something like DLEP as a really good standard, but I fear we will
loose quite a few opportunities if we do not fix it now.

And going for a third standard to do this kind of work doesn't sound very good.

Henning Rogge

---

From: Teco Boot <[email-masked]>
Date: Sat, 28 Apr 2012 10:05:15 +0200

I brought up the complexity of DLEP long time ago. It is not only TLV
encoding, but also using reliable transfer instead of using validity
timers. This introduces synchronisation of state machines on modem and
router. IMHO unneeded and it should be removed.

Current DLEP reduces traffic with transfer of updates only (the OSPF
approach), where 5444 optimizes transfer of repeating messages (the
OLSR approach).
Where information changes over and over, and is related to addresses,
5444 is to be used. ACKing this info doesn't make sense. Loss rate on 
local link is expected to be extremely low anyway.

I don't mind go forward with current DLEP as-is as experimental DLEP,
and discuss an improved DLEPv2. Same approach as OLSR -> OLSRv2, where
OLSR uses simple encoded messages and OLSRv2 the optimized variant.

AFAIK Henning his efforts takes DLEP to DLEPv2.

Teco

---

From: Henning Rogge <[email-masked]>
Date: Sat, 28 Apr 2012 11:53:44 +0200

Is there a current version of the source that compiles cleanly? I
would like to take a look at the sourcecode at Sourceforge.

I downloaded the sourceforge code, but my GCC puts out lots of
warnings and errors.

(I am using a standard Ubuntu 11.10, gcc 4.6.1 on a x86_64-linux-gnu system)

Henning Rogge

---

From: Henning Rogge <[email-masked]>
Date: Sat, 28 Apr 2012 12:59:42 +0200

On Fri, Apr 27, 2012 at 16:17, dsatterw <[email-masked]> wrote:
> At this point we have at least 4 working
> example of a packet parser that seems sufficient for the ones involved.

One more questions about the sourceforge code:
Could it be that the sourceforge code is only compatible with DLEP-00?

Henning Rogge

---

From: Stan Ratliff <[email-masked]>
Date: Mon, 30 Apr 2012 11:22:54 -0400

Henning, 

Yes, I believe that's correct. The Sourceforge implementation was based on DLEP-00 or DLEP-01, can't remember which. It should be in the README.

Regards,
Stan

---

From: Bo Berry <[email-masked]>
Date: Mon, 30 Apr 2012 11:35:20 -0400

Henning, All
The sourceforge implementation is DLEP-00, supporting only the RFC 544 features that we required. It includes a server (router) and client (radio) side.   It is posted using the MIT style license. 

It was built primarily on MAC.  

-Bo

----
[email-masked]