[aodvv2-discuss] Re: Review of 07k
- From: Victoria Mercieca <vmercieca0@xxxxxxxxx>
- To: "aodvv2-discuss@xxxxxxxxxxxxx" <aodvv2-discuss@xxxxxxxxxxxxx>
- Date: Sun, 1 Mar 2015 18:35:43 +0000
Hi Charlie,
Good point, because there's no address block, so there's no address block
TLVs, so we can't use the already defined TargSeqNum TLV.
I have two points on SeqNum in RREP_Ack:
1. The SeqNum in the RREP_Ack may not be enough.
E.g. If we have a RREP for TargAddr A with SeqNum 1, and another RREP for
TargAddr B with SeqNum 1, and both require an ack, when the RREP_Ack comes
back with SeqNum 1, how do we know which RREP it corresponds to? To really
match a RREP_Ack to an RREP, do we need to include the TargAddr? In which
case we can use address block and address block TLVs already defined.
Also another question here: if we send one message with AckReq, should we
avoid sending a second to the same neighbour, at least while the first
timeout is active?
2. Alternatively, we could say that the SeqNum isn't necessary at all.
E.g. if any ack or any AODVv2 message, or any other message in fact, is
received in the time window expected, from the node it's expected from, is
that good enough?
Another question: Say two RREPs with AckReq were sent to the same router,
and only one RREP_Ack came back, should the router be blacklisted?
What do you think?
Regards,
Vicky.
On Sunday, March 1, 2015, Charlie Perkins <charles.perkins@xxxxxxxxxxxxx>
wrote:
> Hello folks,
>
> I reckon that, if the RFC 5444 representation of RREP_Ack
> is to include TargSeqNum, then we have to define a new
> RFC 5444 Message TLC for TargSeqNum. Similarly, if we
> were to define any sort of transaction ID for RREP_Ack
> (or indeed any future message).
>
> Bleahhh.
>
> Does anyone want to argue for getting rid of TargSeqNum
> in RREP_Ack?
>
> Regards,
> Charlie P.
>
>
> On 3/1/2015 9:00 AM, Charlie Perkins wrote:
>
>
> Hello Vicky,
>
> Follow up below...
>
>
> On 2/28/2015 8:04 AM, Victoria Mercieca wrote:
>
> Thanks for all the hard work you put in last night!
>
>
> Thanks -- and likewise for these comments!
>
>
> 6.4 - I noticed a space has gone missing in "DSDV[Perkins94]" - was that
> intentional?
> 6.5 - we should change "OrigNode Sequence Number" to OrigSeqNum, and
> "TargNode Sequence Number" to TargSeqNum... because later when we talk
> about checking for redundancy (8.6) we look at seqnum for orig*addr*/targ
> *addr* rather than seqnum for the node.
> 9.1.1 - 2nd paragraph - TargSeqNum, ValidityTime, MetricType and
> PrefixLengthList should be optional, using same structure as in 9.2.1
> 9.1.1 - step 4 - "Address List" to "AddressList"
> 9.1.1 - step 6 - should probably say:
> "For the sequence numbers:
> * Increment the SeqNum as specified in Section 6.4.
> * Set OrigSeqNum to the new value of SeqNum.
> * If an Invalid route exists matching TargAddr using longest prefix
> matching, include TargSeqNum and set it to the sequence number on the
> Invalid route. Otherwise omit TargSeqNum."
> 9.1.3 - step 4 - change VALIDITY_TIME to ValidityTime
> 9.2 - in the diagram, the PrefixLengthList line is missing the "}"
> 9.2.1 - change TargSeqNumber List to TargSeqNum
> 9.2.1 - step 5 - "Address List" to "AddressList"
> 9.2.1 - step 7 should say:
> "For the TargSeqNum:
> * RREP_Gen increments its SeqNum as specified in Section 6.4.
> * Set TargSeqNum to the new value of SeqNum."
> 9.2.3 - step 6 - change VALIDITY_TIME to ValidityTime
> 9.3.1 - paragraph 4 - change "Address List" to "AddressList" and "Metric
> List" to "MetricList"
> 9.3.1 - step 6 - "SeqNum List" to "SeqNumList" (twice)
>
>
> All fixed.
>
> Section 10 - where it says "see section 14.2" and "see section 14.3" -
> is it more correct to remove AODVv2 in these sentences? the message TLVs
> and address block TLVs are owned by rfc5444.
>
>
> Here I am not sure. The TLVs are owned by RFC 5444 but specified by
> AODVv2.
>
> Section 10 - the paragraph before the table needs the first sentence
> rewording, maybe to "The following table shows how AODVv2 data elements are
> represented in RFC 5444 messages."
>
>
> Done.
>
>
>
> Questions:
>
> I wondered if the references to TLVs should be removed from everywhere
> except section 10 and appendices. If so,
> 6.2 - "AckReq Message TLV" should be "AckReq data element" (occurs twice
> in 6.2)
> 7 - "MetricType TLV" to "MetricType data element"
> 9.1.1 - step 3 - "MetricType TLV" to "MetricType data element"
> 9.1.1 - step 8 - "ValidityTime Address Block TLV" to "ValidityTime data
> element"
> 9.1.2 - step 4 - "MetricType TLV" to "MetricType data element"
> 9.2.1 - step 3 - "AckReq TLV" to "AckReq data element"
> 9.2.1 - step 4 - "MetricType TLV" to "MetricType data element"
> 9.2.2 - step 3 - "MetricType TLV" to "MetricType data element"
> 9.2.2 - step 6 - "AckReq TLV" to "AckReq data element"
> 9.2.3 - step 5 - "AckReq TLV" to "AckReq data element"
> 9.3.1 - step 2 - "PktSource TLV" to "PktSource data element"
> 9.3.1 - step 3 - "MetricType TLV" to "MetricType data element" and remove
> "in the TLV" from the end of the sentence.
> 9.3.2 - step 2 - "MetricType TLV" to "MetricType data element"
> 9.3.3 - step 2 - "PktSource TLV" to "PktSource data element"
> 9.3.3 - step 3 - "MetricType TLV" to "MetricType data element"
> 9.3.3 - paragraph after step 6 - "PktSource TLV" to "PktSource data
> element"
> 9.4.1 - "AckReq message TLV" to "AckReq data element"
> A.5.1 - "AckReq TLV" to "AckReq data element"
>
>
> All done.
>
>
> We could change from ValidityTimeList to ValidityTime throughout? I
> think the current way is OK, but it seems like ValidityTime is more similar
> to OrigSeqNum than to MetricList and should be handled without a list.
> (It's my fault its in there as ValidityTimeList so I'll find all the bits
> to adjust if you think this is worth doing)
>
>
> I'm not sure about this. Notably, in the specification right now, only one
> address ever has an associated ValidityTime in any AODVv2 message.
> I'll send another email shortly with more discussion.
>
>
> Do we need UnreachableAddressList? Can we just use AddressList and put
> one or more UnreachableAddresses in it? Again, not a pressing issue
>
>
> I really like this idea. But I encountered a logistical problem in Table
> 3.
> I created "RteMsg AddressList" and "RERR AddressList" for the purpose.
> Now, the section of that table looks as follows:
>
> | RteMsg AddressList | RFC 5444 Address Block |
> | - OrigAddr | |
> | - TargAddr | |
> | - PrefixLengthList | |
> | RERR AddressList | RFC 5444 Address Block |
> | - UnreachableAddress | |
> | - PrefixLengthList | |
>
>
>
> Do we need to add OrigSeqNum, OrigAddrMetric, TargAddrMetric and
> TargSeqNum in the terminology section? They are in section 3 but someone
> might expect them to be in with all the other terminology too. AckReq,
> PktSource too?
>
>
> As far as Terminology goes, the more definitions the merrier, as long as
> they are used
> in the document. Another possibility would be to enlarge some of the
> definitions in the
> Terminology section to indicate which of the terms are "official" AODVv2
> data elements.
>
>
> I think you have enough text in there already to understand the RFC5444
> multi-value address block TLVs - I just hadn't read it properly. However,
> it is in section 10, so the reader could get confused by section 9 before
> getting to it. Since Section 3 and Section 10 have so many similarities, is
> it worth relocating section 10 to immediately after section 3?
>
>
> Section 10 seems to be a "late-document" kind of section. Maybe
> it should be moved right after section 13?
>
>
>
> Suggested text in relation to recent emails:
>
> In section 2
> SeqNumList
> The list of Sequence Numbers associated with addresses in an
> AddressList. Used in RERR messages.
> In Section 3
> SeqNumList
> A list of SeqNums, included in RERR messages.
>
>
> Done.
>
>
>
> Apologies for the length of the email again, I hope this is all useful
> and I'm not just being a GIANT pain in the ass!
>
>
> This is super useful, and since I have in the past met
> people who really are a giant pain in the ass I can state
> with confidence that you bear no resemblance.
>
> Regards,
> Charlie P.
>
>
>
Other related posts:
