Hi Vicky,
Am 30.04.2015 um 14:30 schrieb Victoria Mercieca <vmercieca0@xxxxxxxxx>:
Hi Lotte,
Thanks for the translation.
On Thu, Apr 30, 2015 at 12:33 PM, Lotte Steenbrink
<lotte.steenbrink@xxxxxxxxxxxx> wrote:
Hi all,
as promised, Hennings feedback, translated. All comments by me are in square
brackets.
(german version below in case you want to run it through google translate ;) )
1. splitting addresses in <head> <mid><tail> and <prefix-length> is too
detailed; it is sufficient to have <address> + <prefix> in the tables. Then,
Henning recommends not having the Address Table at all, but personally, I
prefer Vickys table notation over my squeezing the prefix into the section
name.
I'll use <address> and <prefix> then. It didnt seem right to not have the
address table when we discuss all the other message elements. We want to show
how our AddressList (or OrigAddr and TargAddr) map to the Address Block.
2. a tip: In cases where we don't want to use an extension we can write
extension 0 instead of -- ... this would make it easier to create an IANA
table for the new TLVs.
[Personally, I'm not so happy with this because it requires the reader to
know that an empty exttype is the same as exttype=0, and implementors who
don't know this might set every exttype explicitly to 0, which is just
unnecessary work that should be done by the RFC 5444 reader/writer]
I see what you are saying, but if you are creating RFC5444 messages, you
should have read RFC5444 and you should know that you dont need to explicitly
include the type extension and also set it to zero, i.e. that you can omit it
to give the same result.
What do you think of writing 0 but with a comment? We have space to do this
without making any tables larger. A couple of examples of how it would look
below. Anyone want to vote on this?
+--------------+---------------+------------+-----------------------+
| Data Element | TLV Type | Extension | Value |
| | | Type | |
+--------------+---------------+------------+-----------------------+
| OrigSeqNum | OrigSeqNum | 0 (omit) | Sequence Number of |
| | | | RREQ_Gen, the router |
| | | | which initiated route |
| | | | discovery. |
| ValidityTime | VALIDITY_TIME | 0 (not | ValidityTime |
| (optional) | | included) | guaranteed for route |
| | | | to OrigAddr. |
+--------------+---------------+------------+-----------------------+
+----------------+------------+------------+------------------------+
| Data Element | TLV Type | Extension | Value |
| | | Type | |
+----------------+------------+------------+------------------------+
| TargSeqNum | TargSeqNum | 0 | The last known |
| (optional) | | (omitted) | TargSeqNum for |
| | | | TargAddr. |
+----------------+------------+------------+------------------------+
3. <hoplimit 1> does not need to be included... if there is no hoplimit, the
message will not be forwarded anyway [I think we had this discussion already
anyway, right?]
Would we need to state this for each message type? I guess Henning says this
because of RREP_Ack though?
I dont know if we came to a decision. We could say in the RREP_Ack section
"There are no data elements in a RREP_Ack." and remove that line about
hop-limit from the RFC5444 section. I'm happy to do this if no-one objects?
4. RREP-message: The PktSource belongs into the Addressblock. [I told him we
were discussing this right now, and that the goal was to first have a new
representation of the current message structure, and then apply any future
modifications to it.]
If we put it in the address block, then instead of having a message TLV, we
need to define an address block TLV we can associate with the address to mark
it as the PktSource. In the address block, we wont need a prefix length for
PktSource, we will assume it is equal to address length.
For all other addresses in the RERR, we might have a SeqNum TLV and we might
have a Metric TLV to indicate MetricType. We might have no associated TLVs.
Are we allowed to presume that anything not marked with PktSource would be a
route which is now invalid, or do we have to ensure some kind of TLV to mark
the address as an invalid destination?
This wouldnt be a HUGE pain, since we can add just one TLV and associate it
with all addresses except PktSource.
Regards,
Vicky.
Cheers,
Lotte
Anfang der weitergeleiteten Nachricht:
Von: Henning Rogge <hrogge@xxxxxxxxx>
Betreff: Aw: RFC5444 tables
Datum: 29. April 2015 18:56:22 MESZ
An: Lotte Steenbrink <lotte.steenbrink@xxxxxxxxxxxx>
Hi,
ein paar Kommentare:
du kümmerst dich noch um zu viele Details... für AODV2 ist es
irrelevant das RFC5444 die Addressen in "<head> <mid> <tail> and
<prefix-length>" aufspalten kann. Daher würde ich die Tabelle zu den
Addressen komplett jeweils entfernen. Einfach die Liste der Addressen
plus Prefixes reichen.
Wenn du übrigens "keine TLV-Extension" nutzen willst, schreib einfach
"Extension 0"... das macht es einfach ne IANA-Tabelle für den neuen
TLV anzufangen und die Extension 0 kann halt von RFC5444 effizienter
kodiert werden.
<hoplimit 1> brauchst du nicht zu kodieren... etwas das kein Hoplimit
hat wird auch auf jeden Fall nicht geforwarded.
RREP-Message: die PktSource gehört in den Addressblock.
Henning
2015-04-29 18:31 GMT+02:00 Lotte Steenbrink <lotte.steenbrink@xxxxxxxxxxxx>:
Hi henning,
wie gerade besprochen anbei der Teil des neuen Drafts mit den neuen
Tabellen. :)
Viele Grüße,
Lotte
