Hello folks,
Comments to be posted to the mailing list. If they are O.K. would
prefer if someone else would post them.
It does mention that the route table interface discussion would be in a
separate document. Maybe that should be the first sentence.
> “Revised” — how? Would be good to call
> out any new features introduced, major
> bugs addressed, or unused/inappropriate
> features from the predecessor eliminated?
No major bugs addressed. Some features made optional (see the section).
Requirements for compliance to RFC 5444 incorporated.
> This is a little over-stating the applicability:
> these statements may be true in some
> scenarios (for example, when there are few
> concurrent traffic flows, and therefore few
> routes to repair, and therefore few flooding
> operations to contend for channel access).
We could say, "in cases where the communication graph does
not form a complete graph".
> As a general statement, this last sentence is
> incorrect.
Maybe if the extra clause is added, this comment will be resolved.
Routing protocols in the IETF cannot claim to provide instant
convergence, or to always maintain a exactrepresentation of
the network topology.
> This issue has been brought up several
> times in the WG before, but has not been
> addressed so far.
> What are the clients of a router? I believe
> that this is a confusing and inappropriate
> term (and, fortunately, furthermore is an
> unnecessary term).
We define the term a certain way, and the definition is refined
by the protocol operations in the document.
> In the terminology “router client” is defined
> as something akin to “someone requiring
> the services of a router” — which matches
> “the whole world”: the service provided by
> a router includes “forwarding an incoming
> data packet so as to bring it closer to the
> destination”. Consequently, the source of a
> datagram is the “client” of a router 10 hops
> away that happens to be on the path
> towards the destination? I believe that this
> is not the intention.
> Also, when I see “client” the next word that
> pops into my mind is “server” — two
> entities running (typically) distinct parts of a
> protocol: a DHCP server and a DHCP
> client, for example. I believe that this is not
> the intended association either.
If anyone has a better term than Router Client, of course we could
discuss changing terminology.
Here is a revised definition to resolve the issue:
"An address or address range corresponding to one or more nodes which
require an AODVv2 router to initiate and respond to route discoveries
on their behalf so that they can send and receive IP traffic to and
from remote destinations. The AODVv2 router's interface addresses are
also configured as Router Clients."
> “Confirming adjacencies” sounds like there
> is a sort of HELLO message exchange, or
> other local signalling, in use — at least, to
> someone used to reading OSPF and related
> protocols, that would be the immediate
> understanding.
We could add a clause along the lines "without requiring HELLO message
exchange" and cross reference other more specific text.
> The overview must also include a
> paragraph on the intersections between this
> protocol and the forwarding plane — this,
> as it is different (and more invasive) from
> that which is typically seen in routing
> protocols.
The section on what is required from IP should cover this,
and the overview can cross-reference that section.
> Specifically, as a reactive protocol, it is
> required (at least) that the forwarding plane
> is modified :
> 1) A “miss” when looking up a next hop for
> a data packet to be forwarded, is signalled
> to the AODVv2 process so as to permit that
> route discovery be launched;
> 2) A “miss” when attempting to deliver a
> data packet to a next hop, which was
> recorded in the routing table, is signalled to
> the AODVv2 process so as to permit that a
> route repair be initiated and/or a Route
> Error be generated.
> 3) A “hit” when looking up a next hop for a
> data packet to be forwarded to a
> destination is signalled to the AODVv2
> process so as to permit maintenance of
> “active route” Route State, timers and such.
These should be made clear in Appendix A.
> It is important to do more than this: 7182
> does only provide “containers” for ICVs and
> timestamps, and does not specify how to
> use them to obtain specific security
> properties.
The specific security properties are authentication
and confidentiality. I'm not sure exactly how to
make that more clear in the text.
> This is incredibly frustrating to read and
> use: all the “interesting concepts” are
> defined as “An AODVv2 Data Element” with
> a forward reference to a Table 1
> somewhere.
> Why is the content from that “Table 1” not
> simply included where it belongs: below
> each of the terms in the hangText? The
> existence in a table does not really
> contribute anything (other than space in a
> printed document).
AODVv2 Data Elements have been removed from Table 1.
> All a router cares about is “an address”. If
> that address is of a network, or a router, or
> an interface (and, if said interface is
> installed in a router or a host) doesn’t
> matter.
> So, “an address” is something that the
> routing protocol should care about finding
> paths to. Which means that each address
> that should be made reachable by the
> routing protocol should be advertised by (at
> least) one router in the network.
Not necessarily, especially for reactive routing protocols.
> One way of doing that would be to simply
> talk about “Attached Networks” as is done
> in RFC7181, wherein an address included in
> the “Attached Network Set” is advertised
> by an OLSRv2 router….in this case, the
> equivalent would be “for each address in
> the Attached Network Set of an AODVv2
> router the router MUST respond
> authoritatively to a RREQ, and MUST
> maintain the corresponding sequence
> number”.
We should have more discussion about whether the proposed
new terminology is really appropriate. See below...
> Is there any technical reason why not
> simply *any* address could be considered
> by the routing protocol?
> My understanding, but correct me if I am
> wrong, is that all that is required is that all
> interfaces in a given AODVv2 routing
> domain has an unique address.
We could specify loopback addresses, unspecified addresses,
and multicast addresses, etc. For AODV, we have seen
geographic addresses and DTNs, but those are not part of
AODVv2. We did not expect to do this before Last Call.
> That some of these addresses (by an IP
> addressing architecture document) has
> special semantics associated (such as are
> link locals, or are for private use, or are for
> example use only, or are for multicast) is out
> of scope here?
Yes I would say they are out of scope. Happy to do multicast later.
> Now, with that being said also, the WG
> wanted that RFC7181 supports not just
> multiple interfaces, but also the same
> address used on multiple interfaces of the
> same router. There were good reasons for
> that, and while it was not trivial to
> implement, it turned out to be the right
> thing to support. If there are technical
> reasons why this is not supported in
> AODVv2 (for example, if this cannot be
> made work because of <reason>) then that
> should be called out in the applicability
> statement also?
I am not aware of any reason why this would not work.
> Conversely, if it is possible in AODVv2, then
> I do not believe that it is clearly specified
> how (at least, in the “naive” on paper
> examples I drew up, something ended up
> not working). So either the protocol as-is
> does not support it (but could be made to?)
> or it is supported (but just need to be
> spelled out), or is not possible (and need to
> be disclaimed in the applicability
> statement).
> Stan Ratliff was a driving force in holding
> the WG’s collective feet to the fire in getting
> this support included in RFC7181, and
> would likely be the right person to consult
> on this matter?
It would be nice to find out what's not clearly specified.
> “one of the sequence numbers maintained
> by an AODVv2 router to ….”
> That’s a little vague and ambiguous:
> apparently that sequence number is not
> enough — but we’re not told with what it
> must be complemented in order to be
> enough to determine if a route is fresh or
> not.
> Could that be written:
> “SeqNum is the sequence number, which
> does ______”
The sequence number does work to determine whether a route is fresh.
Here is the current text:
> Sequence Number (SeqNum)
> One of the sequence numbers maintained by an AODVv2 router to
> indicate freshness of route information.
Some other discussion about Sequence Numbers in the document provides
information on previous work related to multihoming, which is not supported
in this base document. This does not affect the above definition.
> Target Node is confusing me, and the
> definition given is only making that worse.
> What does it mean to be “hosting the IP
> address”?
A node hosts an IP address by enabling its applications
to use that IP address as a source or destination IP address.
I'm not sure what else to add here.
> A RREQ is flooded through the network,
> and I assume that a RREQ contains the
> TargAddr.
Check.
> Some *router* (not node!) is
> configured to (i) respond to RREQs for
> TargAddr, and (ii) maintain sequence
> numbers associated with TargAddr.
Check.
> So is “TargNode” that *router* ?
No, TargNode hosts the Target Address. But, see below...
> In that
> case, simply saying “TargRouter” would
> make me happier, as would I be happier if
> including the description above.
> Of course, if this is not the correct
> understanding of TargNode, then that’s a
> good indicator that the concept is
> confusing.
We have reworded to avoid use of Target Node, without
loss of clarity.
> This is probably putting the cart before the
> horse quite a bit. I must confess, I cheated
> and read the specification end-to-end
> before starting this review — so I kinda
> understood what was meant.
> I’d first put “Valid route” before
> “unreachable address”, since the latter
> uses the former. [And yes, that would mean
> that terms would not come in alphabetic
> order — I do prefer clarity over adherence
> to the alphabet, though]
We'd like to hear from others. Often, alphabetizied lists
are easier to use.
> Second, should “valid route” not be
> qualified by “to a specific address”?
So then we would have:
Valid route
A route that can be used for forwarding to a specific address.
This would be O.K., if an address range could be considered a
"specific address". But that seems a bit awkward.
> Third, is an “unreachable address” then not
> “an address to which a valid route is not
> known — either because no route to that
> address has been discovered yet, or
> because it is not possible to discover a
> route to that address”.
The current meaning of unreachable means that
something is broken, not that Route Discovery simply
has not yet been attempted. That refers to a useful
concept in the draft for describing RERR operation.
> By the way, I note that you distinguish
> “node” and “address” here; that does mean
> that if a given end-point has two addresses,
> “IP1” and “IP2” (possibly, on the same
> interface), then you will need two RREQ/
> RREP cycles to discover paths to both of
> these?
Yes, it does mean that.
> Also, will a remote device be able to learn
> that IP1 and IP2 really are “the same
> device” (or even, “the same interface”)?
Not by using AODVv2. Moreover, I think that for
privacy reasons this is a good thing.
> Given that RFC5444 does not ensure
> ordering of addresses (or, of elements in a
> TLV block), would it not be possible to talk
> about an “AddressSet” (and similar for
> MetricTypeList and PrefixLengthList, and
> …) so as to not risk (unintentional)
> misunderstandings for the reader?
> Generally, unless there’s a really good
> reason for assuming (or requiring) ordering,
> I’d prefer talking about “set” and then leave
> an implementer to figure out which precise
> data structure is suitable?
Using the terminology "List" allows us to indicate
that multiple lists in the message are in positional
dependence. For instance, we have an AddressList, and
then a PrefixLengthList, and then a SeqNumList, and
although in the RFC5444 representation, the order doesn't
matter, for AODVv2 data elements, it does, because AddressList[1]
and PrefixLengthList[1] and SeqNumList[1] all are linked.
> Actually, this is not really a set of “data
> elements” but rather the “protocol data
> units” that AODVv2 routers exchange —
> correct?
Usually "PDU" means something more than what we
mean by Data Element within the draft.
> I.e., they are defining the content of the
> messages, and not the data elements used
> by the routing algorithm? Suggest changing
> the name and adding an explanation.
We do not restrict algorithms from using data elements
other than those listed.
> I strongly disagree with the assertion that in
> emergency and disaster relief scenarios
> “the ability to communicate is more
> important than being assured of secure
> operations” — I think that that’s an
> unfortunate and incorrect claim to make.
We could change it to say "may be more important".
> I understand the complexities of providing
> security of a reactive routing protocol. I
> believe that it would be orders of magnitude
> better to call those out, and then describes
> the limits of what can be done (securitywise)
> than to claim a set of scenarios not
> needing security (especially since…they do
> …)
The draft does attempt to do that, but we would
be happy to add more clarifying text.
> To give a simple example, given that
> RREQs are mutable (notably the “metric”
> field) in transit, and is manipulated by all
> intermediaries, then obviously a simple e2e
> signature (inserted using the RFC7182
> format) would require that field to be
> “zeroed out” for calculation/verification —
> which would open an attack vector on the
> protocol. Calling that out, presenting the
> consequences hereof, and presenting the
> conditions wherein — despite that —
> AODVv2 would be applicable (For example,
> always run over a L2 providing hop-by-hop
> security, preventing an uninvited intruder
> from overhearing and participating in the
> protocol), that would be particularly
> valuable.
Our security is hop-by-hop and so the above doesn't seem to
apply. We do mention that encryption provides confidentiality.
> I think that the statement “AODVv2 will not
> make use of” and then “…cannot confirm
> bidirectional connectivity should be
> ignored” are slightly conflicting.
There has been a fair bit of rewording around this topic.
> Does this paragraph intend to say:
> “AODVv2 cannot work when faced with unidirectional
> links, and must not be deployed
> on networks wherein such are possible”
How about:
Since the route discovery process results in a route being
established in
both directions along the same path, uni-directional links are not
suitable,
but AODVv2 will detect and exclude those links from route discovery.
> I am curious on the last sentence; requiring
> persistent state….could you elaborate on
> what you would store? and on what, and
> how, a performance penalty would incur?
It matters about whether the sequence number is stored across
reboots. The penalty is waiting for longer if the sequence number
is lost. The procedure is describing this in section 4.4.
> The WG wanted that RFC7181 supports not
> just multiple interfaces, but also the same
> address used on multiple interfaces of the
> same router.
> There were good reasons for that, and while
> it was not trivial to implement, it turned out
> to be the right thing to support.
> Given that this was required by the WG, I
> wonder if there are technical reasons why
> this is not supported in AODVv2 (for
> example, if this cannot be made work
> because of <reason>) then that should be
> called out, also?
As noted before, AODVv2 supports that based on whatever address the
application uses. If a device enables an application to use different
interfaces for the same IP address, AODVv2 would still work fine.
> I think that appendix B needs to be
> removed. Essentially, it makes claims that it
> is possible to do multi-homing — but
> neither specifies how it is done, nor gives
> pointers to documents that justify the claim.
> AODVv2 does not support multi-homing —
> that’s clear, and it is fine that it is called out
> here. Thank you for that.
> Now, with that being said, I am torn
> between being satisfied that it is called out
> on one hand, and wanting to have “multi
> homing” on the other hand. RFC7181
> supports multi-homing, FWIW.
> I believe that this also would merit some
> explicit discussion by the WG, in order to
> understand if this design decision is
> acceptable?
AODVv2 has never explicitly supported multihoming. Since work has been
done for the purpose of supporting multihoming, it would be useful for
people to have the benefit of that knowledge.
> I am wondering “why just the Internet”?
> Can any external network (which is not
> 0::0/0) be interfaced to an AODVv2-routed
> domain?
> Can multiple such external networks (which
> are not 0::0/0) be interfaced to an AODVv2-
> routed domain?
> I can see clear use-cases for “a MANET,
> connected to two external networks, neither
> of which are 0::0/0”, and I would like to
> make sure that that configuration is
> supported by AODVv2.
This is true. The IAR has been renamed to be an External
Network Access Router (ENAR) and Section 9 revised accordingly.
> Is this a should, or a SHOULD? If the latter,
> should it be a MUST?
I think that SHOULD is correct. For many devices there's only one address
and one interface and requiring storage for a list is wrong. How about
this:
"If multiple interfaces of the AODVv2 router are configured for use
by AODVv2,
a list of the interfaces SHOULD be configured in the
AODVv2_INTERFACES list. "
> Also, I recommend to not say “subnet” —
> how about rephrasing to “If a prefix is
> included in the attached network set of an
> AODVv2 router, then that AODVv2 router
> MUST provide connectivity for, i.e. answer
> to RREQs and maintain sequence numbers
> for, all addresses from within that prefix.”
The relevant text has been revised.
> There’s no “cost”, distance, metric,
> associated with these attached networks?
> I’d think that that’d seriously hamper some
> deployments..
This is a good point. We could allow RREP_gen to
initialize the cost field to something nonzero before
transmitting the RREP. That was done in AODV.
> Stepping away from the “multi-homing”
> discussion (which we should have in
> isolation) even without discussing multihoming
> I envision deployments where I’d
> connect to “external service A” if I know
> that the delay is below XX — but if it is
> above XXX then I’d rather connect to
> “external service B”…and where the major
> impact on the delay could be “from the
> MANET router through the external
> network” rather than “within the MANET”.
Language involving "external services" is not really
germane to the operation of AODVv2. Finding a route
that obeys specified metric constraints has been done
for AODV, but was never included within the AODVv2
specification. It would probably be best as a separate
document.
> Does section 6.2 describe how to monitor
> an established adjacency only, or how to
> discover neighbouring AODVv2 routers?
> Looking in 6.2, I see
> “Not every pair of neighboring routers will
> necessarily form an adjacency,” — so it
> likely isn’t 6.2 that tells me how to maintain
> this table?
AODVv2 does not require knowing all neighbors.
> In short, “A neighbour table MUST be
> maintained” — where can I find information
> on how to do this?
> Section 6.2 states:
> “The default approach for monitoring
> bidirectional connectivity to the next hop
> toward OrigAddr is to request
> acknowledgement of Route Reply
> messages.”
> That certainly will tell me if a link over which
> an RREP is sent is bi-directional, but will
> not maintain a “neighbor table”.
> So how is this done? Or, is the “Neighbor
> Table” not supposed to contain the
> complete set of neighbours? What
> information “…MUST be maintained” then,
> in this table?
> This is very unclear, I would not know how
> to implement a mechanism that populates
> this “Neighbor Table” with the needed
> information here.
Revised to say:
"A neighbor table MUST be maintained with information about
neighboring AODVv2 routers which are used in discovered routes, ..."
> “Neighboring routers which cannot confirm
> adjecency…” — do you mean “Neighboring
> routers for which an adjacency cannot be
> confirmed”?
Revised to say:
"Neighboring routers which cannot confirm adjacency when requested "
> I am afraid that I do not understand what
> you mean here….is “adjacency” simply “bidirectionality
> has been verified”?
That seems close enough that we could use the language.
> And, is “blacklisted” then not rather “we
> tried to verify bi-directionality, but failed” —
> it certainly is not “bi-directionality has not
> been confirmed” since that also captures
> situations where no attempt at verification
> were made.
Yes, I think that's what blacklisted means, more or less.
> What would such an “indication of
> adjacency” be?
Added a reference to the section on adjacency monitoring.
> Also, is it mandatory to represent the
> information in the formats that you give (in
> this, and other sections)?Specifically, must
> it be in forms of tables? Your use of
> “should” here indicate that yes, if so, why?
Now it just says "contains". The representation is not mandatory.
> I am very confused by the use of “neighbor”
> and “adjacency”. — for example
> “Neighbor.State: the state of the adjacency
> …”
> And then below “Before a neighbor is
> confirmed” — but “confirmed was a “state
> of the adjacency?….and that paragraph
> continues [but see below for that]
> I do not understand that.
Revised to say ""before a neighbor adjacency is confirmed".
> I do not understand that. “When neighbor
> state is set to confirmed, the unconfirmed
> routes using the neighbor as a next hop can
> transition to Idle”
> 1) Please do not mix the description of data
> structures, with the description of the state
> machine / processing — it makes it hard to
> read [this comment applies through this
> section 4, fwiw]
If information in a conceptual data structure changes,
that can trigger modification of a route table entry.
> 2) With that said, what does “before a
> neighbor is confirmed” mean in the
> preceding sentence? What state does that
> correspond to?
Revised to say:
"Before a neighbor adjacency is confirmed, i.e.,
while Neighbor.State
is set to Unknown, ..."
> 3) It is not clear if there is a difference
> between “neighbor state” and “state of the
> adjacency”; the terminology lead to believe
> that a subset of neighbors were
> adjacencies, but this section mixes that up.
> Please clarify.
How about:
"Before an adjacency to a neighboring router is confirmed,
i.e., while Neighbor.State is set to Unknown, "
> 4) on the processing sentence (that does
> not belong here), what does it mean that a
> “route…can transition to idle”?
How about more simply:
"can be marked as valid"
> 5) there’s a lower-case can — does that
> mean that it is *not* 2119-language? in that
> case, what is the rule here?
"can" is not clear. How about:
"When Neighbor.State is set to Confirmed, the Unconfirmed
routes using the neighbor as a next hop SHOULD be marked as valid "
> I note a lower-case “should”, so I infer that
> this is not 2119-language either? what is,
> then, normative behavior here?
>
> I note a lower-case “should”, so I infer that
> this is not 2119-language either? what is,
> then, normative behavior here?
Here is some proposed revised text:
"If a neighbor is blacklisted, any valid routes installed which use
that neighbor for their next hop are marked as Invalid. If a link
to a neighbor breaks, the neighbor entry SHOULD be removed and all
routes using the neighbor as next hop are marked as Invalid."
> I would like to nit-pick that: the router can
> maintain this sequence number in whatever
> format it pleases — but, when it includes it
> in control messages, it must be
> representable in a specified format,
> respecting certain rules.
It is specified to be an unsigned integer.
> “it can maintain different sequence
> numbers for each interface IP address, but
> MUST NOT use … ”
> This needs clarification.
> First, “can” is not a 2119-word.
Yes, "can" should be "MAY".
> Second, what are the consequences of “a
> single sequence number per router” vs. “a
> single sequence number per interface”?
We do not have to specify the consequence of that. It could be used for
logging on different interfaces or other purposes.
> Third, this paragraph is written as-if each
> interface has one and only one IP address;
> that is unlikely to be the case. How would
> this impact things?
Instead of
"MUST include the sequence number of that interface’s IP address"
we can use
"MUST include the sequence number of the IP
address associated with that Router Client"
> Fourth, an AODVv2 router that is answering
> to RREQs for addresses in an “attached
> network set”, is that router maintaining and
> using a seq# for each address?
Typically not, but it could.
> Or just one
> sequence number?
This would be the typical case.
> Note that these
> addresses are *not* associated to an
> interface of the AODVv2-router (not
> necessarily, at least) and so this text is not
> entirely clear.
> Fifth, assuming that one wanted to consider
> multi-homing [possibly as an interoperable
> extension], would mandating a specific
> choice of which sequence numbers are
> used for what here be more or less
> advantageous?? I have a hunch that it
> would …
In the interest of simplicity, we suggest to say now that there
is just one seqnum per router. A router could maintain multiple
sequence numbers, for reasons such as the above, or for debugging
purposes, among others. But if it will make the discussion
simpler, those ideas can wait until later.
> How about saying RREQ, RREP or RERR?
No problem.
> I am picking this point to dig in here.
> I think that the choice of phrasing is
> unfortunate, and I saw that Christopher
> Dearlove made a similar comment on the
> list - which I am going to agree with.
> The routing protocol implementation
> operates on an “internal data structure”; in
> RFC7182 that’s called a “routing set”. Such
> a set may contain a lot of information, so as
> to permit routing protocol internal
> functioning.
> At appropriate times, a subset of the
> “routing set” is reflected into the “routing
> table” / FIB, for use for data forwarding.
This is according to one implementation design.
> To take but a simple example, the routing
> set may contain the “reverse routes”
> installed by forwarding RREQs and which
> have not been confirmed as bi-directional:
> such should be kept around for forwarding
> RREPs, of course, but certainly should not
> be considered for use for forwarding data
> traffic. Adding this “reverse route” directly
> to the “routing table” could be catastrophic,
> consider this example: a valid, working
> route from a to b might exist via c — but if a
> receives a RREQ directly from c, adding an
> entry reflecting that reverse route to the
> routing table of a would “overwrite” (or, at
> least, provide a lower-cost, alternative to) a
> perfectly valid route.
Yes, this should be avoided.
> I would like to see three things done to the
> document to this end (note, this comment
> does not just address this paragraph):
> 1) Be consistently clear that protocol
> operations are on a “routing set only” and
> that said data structure is different from the
> routing table / FIB.
> 2) Use said “routing set” as appropriate for
> protocol operations — for example, for
> finding next-hop information for forwarding
> RREPs
> 3) Provide a clear discussion somewhere as
> to when the content of the routing set is to
> be reflected into the routing tale / FIB —
> and, in doing so, what information should
> be reflected, and how (noting “removal of
> entries” as well as adding of entries).
We will have a fuller discussion on this topic in
separate email.
> must -> MUST ?
Yes, should be capitalized.
> I would remove the two last sentences.
> While I do know of good ways of unicasting
> RREQs, and do not know of any good
> reasons why multicast RREPs would be a
> good idea, there’s no need to explicitly say
> “future extensions MAY enable …”
> something, nor saying “RREQ messages
> are usually multicast” to leave the door
> open for extensions — just make sure that
> this specification does not explicitly prohibit
> something should suffice [and remove the
> cruft a bit].
O.K.
> What is that? Specifically, “the IP address”
> — assuming a “node” can have multiple
> interfaces, each with multiple addresses?
How about:
"An IP address of the originating node, i.e., the source
address of the IP packet triggering the route request."
> Incidentally, this is an instance of why
> “node” is not a helpful term, and where its
> use leads to imprecision.
According to the above, I think we can eliminate Target Node.
> “a packet” and “the packet” and such are
> used a little scattered through this.
> In RFC5444-terms, “packet” are welldefined.
> I think that this section is not
> referring to that “packet” but to “application
> data packets” that trigger route discovery
> — right?
Can use "application data packet".
> 2119-language?
Replace "should be maintained" by "SHOULD be maintained"
> If a “node” can be a router, a host, or both,
> then a “node” can have multiple addresses
> — on multiple interfaces. In that case, what
> is “the address or address prefix of such a
> node”?
How about:
"An address, which, combined with the Prefix Length, describes
the set of destination addresses reachable via this route"
> “An IP address…” — any address, that is?
> I think that it is a little more tricky than that:
> if router A has two interfaces A1 and A2,
> and router B has two interfaces B1 and
> B2…and that (for example, due to different
> media/frequencies/channels) bidirectional
> connectivity exists only between A1 and B1
> exists, then for B to use A as a “meaningful
> next hop” it would need to have A1 as
> Route.NextHop — recording A2 would be
> useless.
> So it’s, almost definitely, not “an IP Address
> of the AODVv2 router” but rather a
> *specific* address of that router — which
> must be carefully determined and recorded
> by the processing.
The next hop interface structure in the route table is designed to
eliminate all such ambiguities. Forwarding proceeds by using the
Route.NextHopInterface.
The text has been clarified wherever we use the term "IP address".
> In general in the multiple-interface-multipleaddress
> case, there’re a lot of subtleties to
> work through to make sure that things don’t
> break. This “An IP address …” is an
> indicator that it’s worth taking a good and
> careful look to verify that all these subtleties
> have been worked through.
AODV doesn't need to have complete topology information.
We are indeed trying to work through all the subtleties.
> How is this different from the information
> stored in the “Route Message Table”? It
> would seem that the sequence number for
> a route is the sequence number for the
> router generating the RteMsg that installed
> that route — and which therefore should be
> in the Route Message Table?
> I would suggest that it would be more
> “logical” to keep this information in the
> “Route Message Table”, and not keep
> “Invalid” routes around in the Routing Set?
The Multicast Route Message Table is used for duplicate
suppression. The sequence number information in a route
belongs the destination, not the route.
> I assume that you mean “application data
> packets” here?
Yes. In fact, we could say somewhere in the beginning
that all "packets" are application data packets.
> Is this a 2119-may?
Yes.
> This is all fine information to have, but I
> would like to see this expressed apart from
> the data structures, as part of the state
> machine and processing description.
> Embedding processing, state transitions,
> into the data structure description does
> make it much more likely to accidentally
> overlook it. There’s a few of these “set
> entries which have state transitions” and I
> did have to doodle diagrams to keep it
> straight in my head whilst reviewing. This is
> especially needed if not able to “read it
> through in one sitting”.
It would be very nice to see some examples
where the state transitions are confusing.
Regards,
Charlie P.
