Hello Vicky,
I sent two possibilities. I just want to get to Last Call as soon as
possible. Whichever one you think achieves that objective. I've
endured a lot of strong opinions and don't lust after them for their own
sake.
Regards,
Charlie P.
On 10/6/2015 5:18 AM, Victoria Mercieca wrote:
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 <mailto: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...?
