Hi Lotte,
Comments in-line:
On Wed, Apr 8, 2015 at 12:20 PM, Lotte Steenbrink <
lotte.steenbrink@xxxxxxxxxxxx> wrote:
Hi Victoria,
Am 08.04.2015 um 12:20 schrieb Victoria Mercieca <vmercieca0@xxxxxxxxx>:
Hi Lotte,
It's great to get that discussion started! Feel free to send me your
changes, I can add them in. I do like your diagrams and I think it makes a
lot of sense to organise the RFC 5444 section this way, especially if it's
confusing people the way it is! It seems, in the absence of that API
document, we need to write something, and then see if it's good enough! Did
Henning suggest we had made mistakes, or was it hard to tell because we had
explained it poorly?
I think it was the latter. We'll revisit the draft next week and check for
possible factual error in the draft, though :)
More comments below:
On Tue, Apr 7, 2015 at 8:11 PM, Lotte Steenbrink <
lotte.steenbrink@xxxxxxxxxxxx> wrote:
Hi All,About identifying an address by the fact it doesn't have a TLV, I thought
Henning and I were able to talk about the use of RFC5444 in AODVv2
today. We mainly talked about Section 10. Next week we'll go through the
entire draft and look for consistency issues, errors etc. Here's a summary
of today's results.
Section 10
========
- The main point here was that the way the datasets were connected was
utterly unintuitive to Henning (and I have to say that I agree). The
current arrangement of the table of section 10 still doesn't show the
relationship between the datasets, but still groups them together by type.
From our perspective, this just doesn't make sense: Even if the bytes of an
RFC5444 packet are arranged that way, this is not useful information for
the AODVv2 implementor: If you create a JSON object, or an XML file, do you
think about in which order your data may end up on your hard drive? No. You
want to group your data into a meaningful representation. This is what we
*need* to do with AODVv2 too.
(For the record, I *have* stressed how hard it is to do that without an
API specification from the 5444 folks, but that's just not going to fly as
an excuse.)
I've taken the liberty to sketch how the table may be regrouped so that
the relationships become clearer:
<Bildschirmfoto 2015-04-07 um 20.51.32.png>
This is just a really rough draft (wording needs to be improved, exttypes
need to be specified somehow etc), but you get the idea.
- Addresses without a TLV attached are dangerous. If we identify an
address by the *absence* of a TLV (for example the TargAddr of a RREQ), no
extension will ever be able to attach a TLV to said address without
breaking interoperability with nodes that don't feature said extension.
This has been stressed many times before, and imo we really need to address
this. Since we've reworded AODVv2 so that it's not as closely tied to
RFC5444 (and thus allows for more.. economical alternate packet formats if
needed), the idea that saving a few bytes is so important that it can stand
in the way of extensibility and make packet handling more of a hassle than
it needs to be has to go out of the window. Let's figure out a way to mark
each Address with a TLV, and not through the absence of a TLV. (One way to
do this could be to always add an Orig/TargSeqNum TLV and fill it with a 0
in case there's no SeqNum value (for example for TargSeqNum in RREQ))
we'd identify the TargAddr in that case by the fact that it didn't have an
OrigSeqNum TLV specifically. I don't think this means you cant add any
other TLVs relevant to TargAddr? Tagging both addresses with their relevant
TLV would be idiot-proof though :-)
If we identify the TargAddr by the absence of the OrigSeqNum TLV, we'd
still have a similar problem: any new Address (that also isn't associated
with a OrigSeqNum TLV) that is introduced by a future extension might be
mistaken for a TargAddr by implementations that are not aware of this
extension...
True.
Section 10, trying to stress the difference between the sequence number
Other stuff
========
- Henning confirmed to me what he wrote on the list[1]: When using
extension types, If we set DEFAULT_METRIC_TYPE to 0, this will save us 1
byte as opposed to leaving DEFAULT_METRIC_TYPE at 3, because: the
*variable* tlv-type-ext is *always* set, and it is set to 0 by default.
If the <tlv-type-ext> *flag* is set, too, tlv-type-ext will have the
value that <tlv-type-ext> has. So the exttype 0 is always set, and we just
need to make use of it. Charlie gets his tiny packets, I get my painless
handling, everybody's happy.
- why does 9.1
<http://tools.ietf.org/html/draft-ietf-manet-aodvv2-08.html#section-9.1>.
RREQ Messages list all kinds of lists in Figure 1, but OrigSeqNum,
(optional) TargSeqNum is not put into a SeqNumList?
SeqNumList is effectively a multi-value SeqNum TLV used in RERR where we
dont give special significance to any one address. Using the more specific
OrigSeqNum TLV in a RREQ lets us identify which address is the OrigAddr. If
we were to use SeqNum TLV instead and associate the seqnum contained within
it with one address only, we could assume that because it's a RREQ, the
address with the seqnum is OrigAddr, but this means we arent allowed to
include a TargSeqNum, and also ignores the previous point you made.
I think what caused the confusion here was that some Lists have very
specific, named members (such as OrigAddr and TargAddr of the AddressList),
but that this pattern doesn't apply to the SeqNumList.
We might have expressed it this way because of the way we organised
While going through the draft I've noticed a couple of places where thehave a Metric and ValidityTime, or a SeqNum and Metric). Expanding on your
idea of defining a list doesn't sit right with me, i.e. when there's only
one piece of information to put in it. I was wondering how to tidy this up.
+1
- MUST every Invalid route reported in a RERR really have the sameMetric TLV with the extension type to indicate MetricType, are we still
MetricType?
This was because MetricType was a message TLV. Now that we are using the
limited to only one metric type per RERR? I think the MetricType given in
the extension-type will apply to all values in the TLV?
Exactly. The overhead of possibly having different extension types in
there should be smaller than the overhead of sending one message per metric
extension type.
Some thoughts on this: I think we could include multiple Metric TLVs with
different extension types. For example, have the first Metric TLV with
MetricType A apply to addresses 1-3, and the second Metric TLV with
MetricType B apply to address 4? Since we can applying the TLV value to
either one, all, or a contiguous set of the addresses in the AddressList,
the order of the addresses could be important again, to ensure that they
are grouped by metric type...
This is ensured by the RFC5444 parser (or builder or whatever you want to
call it). All we will have to do is specify the extension type and metric
per address, and the parser will group it into multi-value TLVs and make
sure everything is aligned correctly.
so for example, on or side, we'd have to do something like this: (warning,
sketchy pseudocode)
parser.add(address1, {.tlvtype=metric, .exttype = metric_type_hopcount,
.value = 5});
parser.add(address2, {.tlvtype=metric, .exttype = metric_type_hopcount,
.value = 2});
parser.add(address3, {.tlvtype=metric, .exttype = metric_type_unicorn,
.value = 1});
parser.add(address4, {.tlvtype=metric, .exttype = metric_type_hopcount,
.value = 4});
And then the RFC5444 parser will internally group address1, address2 and
address4 together and make sure that metric_type_hopcount applies to all of
them, but not to address. But that's none of our concern, because it
happens out of our spec's scope.
or would we end up adding a bunch more Metric TLVs if they weren't
grouped, e.g. we have addresses 1-3 of MetricType A, address 4 of
MetricType B, and address 5 of MetricType A. Also, if there are two routes
to a particular address and they both break, we could have multiple Metric
TLVs applying to one address, e.g. if there were two broken routes to
address 3 (one of MetricType A, one of MetricType B), we'd have the first
Metric TLV applying to addresses 1-3, and the second Metric TLV applying to
addresses 3-4. Anyone have any thoughts?
We'd have to add the address twice in any case, wouldn't we?
Would we? We need to add multiple TLVs to some addresses anyway (when we
Lotte
Kind regards,
Vicky.
Vicky, since you have the editorial pen– can I just send my changes for
section 10 to you and you'll add them or should I wait until you're done or
how do we do this?
Regards,
Lotte
[1] https://www.ietf.org/mail-archive/web/manet/current/msg17390.html
