Subject: RE: [manet] DYMO Unknown Type Handling Bits

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Wed, 07 Jun 2006 16:52:23 +0100

Sorry, what I meant to say was first if, and then if so, why.

-----Original Message-----
From: Dearlove, Christopher (UK)
Sent: 07 June 2006 16:50
To: 'Ian Chakeres'; Charles E. Perkins (work); manet
Subject: RE: [manet] DYMO Unknown Type Handling Bits

> If you are currently using DYMO or expect to use DYMO in the future,
> please email the list with a few paragraphs describing why this
> functionality is important to you.

May I suggest "if" rather than "why" in order not to presuppose the
answer.

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

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

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Wed, 07 Jun 2006 16:49:44 +0100

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 08 Jun 2006 10:04:03 +0100

> There is an useful functionality missing on this list, that was
present
> in previous DYMO drafts.  Namely, we had a bit in the main header
> that indicated whether a node had ignored an extension.

I don't think that bit ever made it into any OLSRv2/packetbb draft,
only discussion. But that's not important.

There's a complication here that I think needs better understanding of
the philosophical position of DYMO by the OLSRv2 camp and vice versa.

The OLSRv2-inspired model is that a node receives a message (it receives
it in a packet, but a packet is a temporary one hop encapsulation
mechanism that we can ignore for the moment) and (a) may process it, and
(b) may forward it. But (a) and (b) are independent, they can be done in
either order, or even (if you have that sort of hardware/software) in
parallel, and the decisions whether to do each are separate and all four
do/don't options are possible. (Note that the reason some information is
in the message header rather than being tucked away in TLVs is that this
is precisely the information needed to make both do/don't decisions.)
This means that a forwarded message is (apart from hop limit/count
changes) exactly that received. This has a number of advantages, the
separation of processing and forwarding has distinct software
advantages,
the immutability of messages has distinct security advantages (to name
just one, end to end verified signature of messages is possible).

Now DYMO, as I understand it, has much more fluid messages, and
forwarding
is distinctly an aspect of processing. In fact that a message is
forwarded
is a philosophical point, as the things that most obviously make two
different collections of bits "the same message" using the packetbb
structure are the message originator address and sequence number, and
these parts of the message header are (as allowed as a design option)
not used by DYMO. So is DYMO forwarding a message (after changing it
- both additions and subtractions I believe) or sending a new message
incorporating material from the old message. "On the wire" both look
the same.

So I think that whatever we do here (and this I think is a related, but
not quite the same, concept as what I think Ian was meaning - which is
why I think we should be discussing functionality, with specific
required
use cases, rather than implementation details) we need things which fit
both models, without breaking either. Actually if DYMO messages are
fluid,
there's nothing to stop DYMO defining a message TLV which may be added
to
signal this sort of information when it's at the message level. But I
appreciate that this may be undesirable - and it doesn't work at the TLV
level, where we have no "TLV TLVs" (although it would be possible to
define a TLV with such semantics, it would be - to put it mildly -
ugly).
We do have the possibility of reserving one or maybe two bits in the
various semantics bit vectors (packet, message, TLV) as "protocol
specific"
pushing the problem off to the protocols. This I think should form part
of
a wider discussion we know we need about packetbb and related namespace
organisation.

Finally, note that packetbb is currently syntax only, the only semantics
is that "this conveys that piece of information"). (There's an exception
in that the intended ue of hop limit/count is indicated, but even that
could be ignored.) It's a much better fit if we have things of the form
"this bit means such and such" than "if this bit is set, do such and
such"
when - as is the point here - different protocols have quite different
models of how things are done.

Christopher Dearlove