Subject: [Manet-dt] Packet Format Document

From: Ian Chakeres <[email-masked]>
Date: Sun, 11 Dec 2005 12:17:12 -0800

Late last week Thomas (and others) submitted
draft-clausen-manet-olsrv2-fmt-00. First, I'd like to stay great job
to those involved in writing it up. It looks great and I know the
amount of effort that must have gone into it.

I'm excited to start looking at it in the context of DYMO and I know
the other DYMO people are too.

I have a few initial comments/suggestions/questions about the ID not
specific to DYMO.

I think that originator address should be changed to originator ID.

Should the packet sequence number be originator or interface specific?
>From the ID, it seems like interface. Can you please explain this
decision?

In the <addr-block> definition it states "with which the originator
has a relationship". For dymo, intermediate nodes might append
information. Is the originator the creator of the message or the node
transmitting the message?  I think this is just a terminology issue.

I think duplicate elimination should be changed to duplicate detection.

I noticed the index-start and index-stop are always there even for
single index tlvs. For msg-tlvs these aren't really needed. What was
the motivation of always including these two fields?

Does the example provided on page 26 require a packet-header? Or is
this simply included because in general OLSRv1/2 does always include
the packet header?

Thomas et. al., I want to say again. Great job. I'm really excited
about the possibilities created by utilizing a common format.

Ian

_______________________________________________
Manet-dt mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/manet-dt

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 12 Dec 2005 09:57:13 +0000

>I have a few initial comments/suggestions/questions about the ID not

I'll try to give some background, but this isn't a design team
answer, just me.

>I think that originator address should be changed to originator ID.

I can see that argument, however it has to be IP address sized, and
it has to be unique, at which point it pretty much has to be an IP
address, and calling it originator address makes that clear. So
whilst I can see the point, I prefer originator address. But as I
said, this is just me here.

>From the ID, it seems like interface. Can you please explain this

If something in the ID has given you that impression, could you
let us know where? Originator address is (must be) the message
originator, not changed as the message is forwarded. This is
critical to duplicate detection/elimination.

>transmitting the message?  I think this is just a terminology issue.

As you say, I think this is just wording. There are however issues with
the addition of information as a message is forwarded (such as if using
signatures - a common OLSR extension we can now do with a message TLV -
that would invalidate the signature). Some thought may be needed here,
to include some warning words perhaps.

>I think duplicate elimination should be changed to duplicate detection.

Or possibly to mention both. As I recall (I'm not cross-checking the
draft as I write this) the reference to duplicate elimination is that
the sequence number mechanism permits it (nothing in this ID does it).
As you say it permits duplicate detection, and of course hence it also
permits duplicate elimination. So I don't think we'd want to not mention
duplicate elimination, but as it's via duplicate detection, and you
might
want to detect but not eliminate I suppose, mentioning both is painless.

>the motivation of always including these two fields?

Common parsing logic.

>this simply included because in general OLSRv1/2 does always include

The example is meant to be one showing how it all fits together, so
it is intended to be about the simplest example I could put together
that included almost all features (it's missing an empty address head
example, plus of course including only one message). As such it
naturally includes a packet header, and a full message header. As it
doesn't represent anything in particular, it's a moot point whether
it needs a packet header. But it could, packet sequence number is used
in OLSRv1 (optionally) to allow the detection of lost packets on a
link (not that message sequence number does not do that job) and
whatever protocol this packet represents could have that requirement.
Packet header and having multiple messages in a packet are (using
Thomas' neat trick of relying on that there is no message zero)
orthogonal issues.

Incidentally we have a non-empty list of known typos, and if I ask
for you all to send them, you'll probably hit the same ones. But I'll
ask anyway, there may be some we haven't spotted yet. I'll only mention
one - one of the figures has some extra characters off to the right
that may wrap around and mess up the figure depending on how you print
it. Sorry about that (that one's my fault - not that I'm suggesting
none of the others is). I suggest you delete them from your copy.

********************************************************************
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.
********************************************************************