Subject: [manet] DLEP comments

From: "Justin Dean" <[email-masked]>
Date: Thu, 2 Dec 2010 17:14:28 -0500

Starting in section 7.

I would suggest a 3rd column which indicates what kind of TLVs are being
defined (Packet/Message/AddressBlock)

Also when giving definitions for the TLVs specify which kind of TLV it is.

Example change "Identification TLV" to "Identification Packet TLV" or
"Identification TLV (Packet)" 

Section 7.1

Change the first sentence from 

This TLV MUST be in the Packet Header TLV Block for all DLEP messages

 to

This TLV MUST be in the Packet Header TLV Block for any rfc5444 packet
containing any DLEP message.

Section 8

"The DLEP Packet, being based on RFC5444, contains the following fields:"

Is suggesting that DLEP will only borrow/use the format and not actually be
compatible with other RFC5444 based protocols which also use RFC 5498 (The
IANA document).  This suggestion contradicts the 3rd paragraph in the
assumptions section which refers to the packets as RFC 5444.   While either
approach is valid I would prefer conformance with both RFC 5498 and 5444 to
allow DLEP to possibly take advantage of other documents such as
packetbb-sec.  In either case clarity on which approach is being taken
should be improved.

Section 8.1 lists "Message TLVs" when I am pretty sure you meant "Message
Types"

That being said I believe there are too many different defined message types
and things could be simplified using message and address block TLVs.  I
suggest paring down the number of Message Types as there is a much lower
number of them in general than actual Message TLVs which can be Message Type
specific so they are cheap assignment wise.

Let me give a few examples.

Let's just start off with a generic DLEP message type and see how the
various Message types you defined might look just using one message type

9.1 Attached Peer Discovery Message

Would look exactly the same except the Msg type would be DLEP (TBD) and I
would change the attached TLV from "Peer Type TLV" (which would no longer
exist) to "Attached Peer Type TLV" (which is new)

9.2 Detached Peer Discovery Message

Same as above except a "Detached Peer Type TLV" (new) would be included.

10. Peer Offer Message

I really don't like the method of including addresses in TLVs when we have a
compressed address block ready to use.  The limitation would be that only
one type of address IPv4/Mac/IPv6 type could be used within a messages
address block.  One work around would be to use 2 different message blocks
which contain differing sized addresses.  Another would be to encode IPv6
addresses in the address block and just bite the bullet and list the IPv4
addresses in a TLV as you have done.  If one uses the address block for
encoding the addresses the IPv4 Address TLV and IPv6 Address TLV could be
changed to 3 different Address Block TLVs, Neighbor Up, Neighbor Update, and
Peer Update, with the value field just containing the "Add/Drop Indicator".

11. Peer Update Message

Same as above except the included Address Block TLV would but the Peer
Update Address Block TLV

20. Neighbor Address Update Message

Same as above except the included Address Block TLV would but the Neighbor
Address Update Message

12. Peer Update ACK Message

13. Peer Termination Message

14. Peer Termination ACK Message

These would all use the standard DLEP message type with the Status Message
TLV included in the message indicating which action is being conveyed.
Alternatively three differing "status" Message TLVs could be defined each
with their own code types.

15. Neighbor Up Message

Similarly to section 11 and 12 use of the address block would be of better
use of RFC5444.

16. Neighbor Up Ack Message

17. Neighbor Down Message

18. Neighbor Down Ack Message

21. Neighbor Address Update ACK Message

It might be useful to use the originator address to encode the provided MAC
address instead of using a TLV.  This will only be efficient when the mac
address is the only address provided but this is the case here.  Also
because we are still using the same message type DLEP, new "status" Message
TLVs, e.g. "Neighbor Up ACK Message TLV" could be used to indicate which of
the four defined messages this message is conveying.

19. Neighbor Update Message

I don't know that anything would need to be changed here other than the
suggested use of the originator address field for the mac address instead of
a TLV.  As above a "status" Message TLV of a specific type may be require
but in this case it could possibly be implied.

22. Heartbeat Message

Nothing would need to change and an RFC5444 packet containing a DLEP Message
with no attached TLVS would be an implied Heartbeat Message.

23. Link Characteristics Request Message
24. Link Characteristics ACK Message

The same principles apply to these two message types as the above.  

Another minor grip I have is that the included "examples" are not sufficient
for illustrating which TLVs are included where.  One is also uncertain of
which fields and TLVs are required.  For example does an Latency TLV need to
be included in all Link Request Messages when the protocol upper layers
might not care?  Is that allowed?  From the text and illustrations it is not
clear.

Justin Dean