Hi Charlie,
I'd be tempted to send the longer response and see if anyone has a strong
enough opinion either way?
Regards,
Vicky.
On Thu, Oct 1, 2015 at 1:14 AM, Charlie Perkins <
charles.perkins@xxxxxxxxxxxxx> wrote:
Hello folks,
During our last conference call, it was suggested that we should make
another response to the [manet] mailing list regarding the use of the
terminology "Locally Attached Network Set". Here are two possibles
response along the way towards closing the issue. I'm not really sure that
the issue really warrants any extended discussion, so maybe the first
response is better.
It has been suggested to denote the set of Router Clients for a particular
AODVv2 as its "Locally Attached Network Set", and replace the term "Router
Client" by some other terminology. In the meantime, a number of steps have
been taken to further clarify the meaning of the term "Router Client". Our
hope is that with the recent updates, Router Client terminology will be
clear.
Or, more could be added:
It has been suggested to denote the set of Router Clients for a particular
AODVv2 as its "Locally Attached Network Set", and replace the term "Router
Client" by some other terminology. In the meantime, a number of steps have
been taken to further clarify the meaning of the term "Router Client". Our
hope is that with the recent updates, Router Client terminology will be
clear. The suggested alternative also introduces a bit of ambiguity,
because it is not clear exactly what a "Network Set" is, and the word
"attach" is also ambiguous; "attachment" typically connotes a kind of
physical proximity often implemented with wires or direct media
attachment. In addition, the alternate terminology suggests the attractive
abbreviation "LANS", which is definitely not desirable for the underlying
concept needing terminology.
Regards,
Charlie P.
On 9/10/2015 6:15 AM, Victoria Mercieca wrote:
* Discussion
In OLSRv2 there is a Locally Attached Network Set. Should we adopt a
similar term?
This topic also relates to some confusion later in the document that:
"this indicates that a random AODVv2 router R will not generate a RREQ for
a destination unless the source address of the data packet requiring a
route to that destination also appears in the AODVv2 routers’ attached
network set — correct? It strikes me as something that should be said much,
much earlier in the document.
Also, that strikes me as a policy decision, which really is not for the
routing protocol to make, but for the network operator — it is not hard to
thin up situations where this proposed policy would be a constraint. Any
technical reasons why this policy decision is enforced?"
This comment is interpreted as saying "if another router forwarded me a
packet, but I don't have a route, why wouldn't I request one?" but the
answer (and maybe it could be classed as a policy) is that if we did that,
anyone could decide to forward packets to us, and cause us to send out
route requests. This could be a way to attack a router. Plus, if we did
send a RREQ on behalf of some remote node, what seqnum would we use in the
message, what metric? Do we have a route to OrigAddr in order to forward a
RREP toward it? Also, why is another router sending packets when a route
does not exist? We have defined that only OrigAddr's router, where it is
configured as a Router Client, is supposed to initiate route discovery on
its behalf.
The comment might also hint at fixing broken routes, but in that case we'd
still have the problem of what information to use in the request. We might
not have seqnum or metric info relating to OrigAddr. If we did, are these
up-to-date? It wouldn't be right to increment the seqnum, since that seqnum
belongs to another router: the seqnum used in the RREQ is the one
associated with OrigAddr, it needs to be the originator router's seqnum and
needs to be incremented by that router when a new RREQ is sent.
Besides, in this situation we use RERR to inform OrigAddr's router that we
dont have a route and it needs to find a new one.
Perhaps by clarifying what we mean by Router Client, this becomes
clearer...?
