Subject: RE: [Manet-dt] Unknown TLVs

From: "Dearlove, Christopher \(UK\)" <[email-masked]>
Date: Wed, 28 Sep 2005 09:21:47 +0100

> I think the intent was thus:
>
>	- all "mandatory" (i.e. specified by the OLSRv2 spec) TLVs
>	  MUST come before any "optional" TLVs
>
> Thereby, a "minimal" node COULD process only mandatory TLVs,
> then stop (discard the rest), and still be compliant to the spec.

> However recommended behavior is as Chris states, that unknown
> TLVs be ignored for processing, but still included for forwarding.

> I'll have to look at the notes (which are at work) from the last
> Extreme Editing session to recall the arguments -- but Chris/Justin
> may remember?

At one point we specified mandatory before extension, and then later
we tightened up even further and decided TLVs in a single TLV block
should be in ascending (actually this should be non-descending, as
there may be repeats) order. The deciding motivation for this was
fragmentation, we wanted the Fragmentation TLV to appear absolutely
first in the message TLV block, so that the test "is this a fragment"
could be checked very rapidly (look at byte 12 - assuming IPv4 - of
the message) by making that type 0.

OK, that was from memory, but the good news is - it is in the
-01 draft. (Last paragraph - if you ignore the one line ghost
that should have been deleted - in section 3.2 before section
3.2.1.)

Since we are discussing TLVs, and since Ian kicked this off, a
question I'd planned to ask on this list is, could you specify
all DYMO messages in OLSRv2 format? Three things to note about
that question. First, I'm not suggesting it should be done, I'm
interested to see how flexible the format is, and seeing if
something different could be fitted into it is a test of that.
Second, there are some bits of the OLSRv2 message format that
DYMO doesn't need (e.g. Vtime in the header) but of course those
can be ignored. Third when I say OLSRv2 message format, I mean
the intended OLSRv2 message format, there's a fault in the -01
specification (don't even think about the -00 specification -
and Appendix D isn't properly updated either) which omits the
"number of tails" in the address block. (I also think the special
role of the first address block in specifying own interfaces
could be clearer.)

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

---

From: "Justin Dean" <[email-masked]>
Date: Wed, 28 Sep 2005 11:31:37 -0400

Chris said:
Since we are discussing TLVs, and since Ian kicked this off, a question I'd
planned to ask on this list is, could you specify all DYMO messages in
OLSRv2 format? Three things to note about that question. First, I'm not
suggesting it should be done, I'm interested to see how flexible the format
is, and seeing if something different could be fitted into it is a test of
that.
Second, there are some bits of the OLSRv2 message format that DYMO doesn't
need (e.g. Vtime in the header) but of course those can be ignored. Third
when I say OLSRv2 message format, I mean the intended OLSRv2 message format,
there's a fault in the -01 specification (don't even think about the -00
specification - and Appendix D isn't properly updated either) which omits
the "number of tails" in the address block. (I also think the special role
of the first address block in specifying own interfaces could be clearer.)
End Chris (not really I kinda like Chris)

To further expand on this the SMF draft is going to need some neighbor
discovery method.  There was some discussion of using a common message
format for OLSRv2 DYMO and SMF.  Having tlv's allows for differing cds
algorithms to use the same message format only with differing tlvs.  To this
end what if anything could be changed to the OLSRv2 message format to make
it a better cross algorithm tool and what are peoples thoughts on going in
this direction?

Justin