Hi all
On 30/04/15 14:20, Lotte Steenbrink wrote:
Hi Vicky,I've just run this past Rick, who recommends that in the AODVv2 specification we simply write 0. The (omit) etc. is a processing instruction. See also Vicky's comment above on including or not the zero in the message. For me, if the implementer is not using a 5444 parser, the 0 could be important.
Am 30.04.2015 um 15:10 schrieb Victoria Mercieca <vmercieca0@xxxxxxxxx <mailto:vmercieca0@xxxxxxxxx>>:
Hi Lotte,
On Thu, Apr 30, 2015 at 1:48 PM, Lotte Steenbrink<lotte.steenbrink@xxxxxxxxxxxx <mailto:lotte.steenbrink@xxxxxxxxxxxx>>wrote:
Hi Vicky,
Am 30.04.2015 um 14:30 schrieb Victoria Mercieca
<vmercieca0@xxxxxxxxx <mailto:vmercieca0@xxxxxxxxx>>:
Hi Lotte,
Thanks for the translation.
On Thu, Apr 30, 2015 at 12:33 PM, Lotte
Steenbrink<lotte.steenbrink@xxxxxxxxxxxx
<mailto: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.
I agree.
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. |
+----------------+------------+------------+------------------------+
Mhm... I think that's more confusing than just having a 0 there.
What about just writing "None" instead of "--"?
I'd be fine with 0, None or -- – go for what you think makes the most sense...
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?
Yup, that's what I'm assuming too.
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.
why so?
Why we dont need a prefix length? Because the RERR is triggered by a packet that cant be delivered. We dont know the prefix length associated with the source IP address of that packet, and we don't need to. We want the RERR to get back to that particular device (i.e. to the router that is responsible for it) - PktSource's prefix length doesnt matter. So if we dont include a prefix length, its like saying prefix length = address length, which is not a problem.
True! Thanks for the explanation.
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?
We are allowed to, but it comes with a few complications. Charlie
and I had a discussion about this in the “RFC5444 feedback pt. 1”
thread... As a compromise, we could add PktSource to the
AddressBlock, mark it with a TLV, but *not* not mark the other
Addresses with a TLV (following the procedure that has been
followed up until now) and then see if there's any feedback from
the working group on this issue once we've published the next
draft update.
Shall we go ahead and do this then?
In the IANA section, we can remove PktSource from the Message TLV section, define it as an address block TLV, Type 14 (TBD), Length 0 (because it wont need to contain a value) and reference back to section on RERR messages.
In the RFC5444 section we'd move PktSource into the address block, and in the address block TLV block, we'd have a section for PktSource, where we associate the PktSource TLV, with no value or extension type.
In the RERR section, PktSource wont be a data element. I can update that section to have PktSource added to the AddressList. The text will need a bit of work in the generation/reception/regeneration sections.
Sounds good to me! If the last step is too much trouble, I think we could also keep PktSource as a Data Element and say that, in the special case of RFC5444, this is translated a bit atypically...
Regards,
Lotte
I'll wait until there's consensus!
Regards,
Vicky.
This wouldnt be a HUGE pain, since we can add just one TLV and
associate it with all addresses except PktSource.
I agree. ;)
Regards,
Lotte
Regards,
Vicky.
Cheers,
Lotte
Anfang der weitergeleiteten Nachricht:
*Von:*Henning Rogge <hrogge@xxxxxxxxx
<mailto:hrogge@xxxxxxxxx>>
*Betreff:**Aw: RFC5444 tables*
*Datum:*29. April 2015 18:56:22 MESZ
*An:*Lotte Steenbrink <lotte.steenbrink@xxxxxxxxxxxx
<mailto: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
<mailto:lotte.steenbrink@xxxxxxxxxxxx>>:
Hi henning,
wie gerade besprochen anbei der Teil des neuen Drafts mit
den neuen Tabellen. :)
Viele Grüße,
Lotte