I think in section 8 is a good place to put it...Section 12 is just tables
for IANA really isnt it? I think it was relevant to talk about the 0 /
DEFAULT_METRIC_TYPE point in section 12, but expanding on the use of the
PATH_METRIC TLV there doesnt seem to fit right.
I've added into section 8 underneath the table which says address block
TLVs for RERR:
"Using the PATH_METRIC TLV without a value is a mechanism used in RERR
messages to indicate the MetricType associated with the route being
reported, without the need to include a Metric value. Multiple PATH_METRIC
TLVs may be necessary if routes with multiple MetricTypes are included in
the RERR."
This is followed by the text about not including when using
DEFAULT_METRIC_TYPE.
Regards,
Vicky.
On Wed, Jun 24, 2015 at 3:48 PM, Lotte Steenbrink <
lotte.steenbrink@xxxxxxxxxxxx> wrote:
Quick feedback from Henning:
he says it's not really clearly stated that RERRs use *only* the extension
type of the PATH_METRIC (to mark routes with metric types other than
default). He suggested to add a paragraph along the lines of
“Each PATH_METRIC TLV has a length, depending on the metric type. It can
also be used with length 0 to just announce the metric type without a
metric value.” to section 12.3. Personally, I think that would be
confusing too, because it addresses a specific case which is different from
the norm. In my opinion, it would make more sense to state this near the
beginning of section 8.4.4.2, where it will be noticeable, but only to
those who need it.
What do you think?
regards,
Lotte
Am 24.06.2015 um 16:27 schrieb Lotte Steenbrink <
lotte.steenbrink@xxxxxxxxxxxx>:
Hi all,
after a lot of discussion and some consultation with Henning, we've
updated AODVv2's RFC5444 packet section so that each Address is now
associated with a TLV that can definitively identify the Type of the
Address (i.e. Originating Address, Target Address, etc). We've chosen to
create a new Address Block TLV type for this, namely ADDRESS_TYPE. Each
address is associated with an ADDRESS_TYPE TLV which contains a specific
value encoding the type of the address (see Table 12).
Attached you'll find the modified sections.
Additionally, we removed the following two paragraphs from Section 7:
From 7.1:
The OrigSeqNum data element in a RteMsg MUST apply only to OrigAddr.
Therefore the other address in the AddressList is TargAddr. If the
TargSeqNum data element is included, then it MUST apply only to
TargAddr.
From 7.2:
The TargSeqNum data element in a RteMsg MUST apply only to TargAddr.
Therefore the other address in the AddressList is OrigAddr.
As always, we're looking forward to your feedback!
Regards,
Lotte
<AODVv2 RFC5444 Representation v2 (Replaces Draft 9 Sections 8 and 12)>
