[aodvv2-discuss] Re: RFC5444 feedback pt. 1
- From: Charlie Perkins <charles.perkins@xxxxxxxxxxxxx>
- To: aodvv2-discuss@xxxxxxxxxxxxx
- Date: Mon, 20 Apr 2015 06:42:14 -0700
Hello John,
On 4/20/2015 5:15 AM, John Dowdell wrote:
Saving bytes does matter for energy conservation. The processing
step is that the receiver
has to keep track of the addresses it has received.
Lotte makes the point well ([ref A] below in this email) that RFC5444
parser is in charge of how the bytes actually go out the door to the
next device. Thus if we try to save bytes in the messages, the parser
could easily negate that, and we have (as Lotte says) absolutely no
control over that, unless there is some control flag or message that
can be passed in the API that we still don't know about </grr>. I'd be
more in favour of constructing sensible readable messages that the
parser can then edit, summarise and generally reconstruct to its
hearts content. If the network builder really wants to have tiny
messages, they can architect their network addressing plan and maybe
even build a special parser to do that.
Well, if RFC 5444 can just add new bytes without any justification from
the protocol messages, then I am surprised. I suppose they could simply
define a new TLV called "waste bytes" and add a random number of
random bytes, and we would have no control over that. Padding and all,
because future RFC 5444++ on steroids requires 512 byte alignment.
Oh, and forget energy savings, which is never mentioned in RFC 5444.
The argument about whether new TLVs will be added in the future is
not relevant, because:
a) if they are added, then they can be made mandatory, or AODVv2 can
be updated, and
So, in other words, the creation of any documents that contain
optional extensions which help in specific situations that don't
apply to all AODVv2 deployments is severely restricted, if not
impossible. Imo, that's problematic.
I can't imagine you mean exactly what you said. Of course any future
documents
about AODV are going to be heavily constrained to somehow be conformant to
AODV. Besides, the future extensions can be compatible with existing
AODVv2, by
simply doing what I suggested. Did I misunderstand you?
b) they almost certainly won't be added; no one has made a credible
suggestion, and
c) there is absolutely not any need to "mark" addresses with a TLV
at all, and
Yes there is, and it has been explained time and time again why.
Did you mean for (b) or for (c)?
There isn't a need to mark addresses with a TLV in RERR messages.
What am I missing here? There is not a need to mark addresses
mandated within RFC 5444.
By the way, in the current document, "SeqNumList (one entry per address)"
should be shown as optional for RERR.
c) before they are added, which they won't be, we can hope that RFC
5444 will be
revised to avoid the tight relationship with the needs of OLSR.
I don't think we can hope for any changes regarding RFC 5444, as can
be seen with the missing explanatory document that has been promised
for months now.
Well, we can hope, even though the current atmosphere is bleak.
For homework, please try to specify a source route using RFC 5444.
Did someone want to claim that source routing requires
improper routing protocol elements?
For (a), note that adding new TLVs for AODV address block addresses
would
tautologically require updating AODVv2, so that would be the time to
add new
mandates.
No, it wouldn't. There can be RFCs that specify optional extensions,
and they can add optional addresses. Any AODVv2 router that *doesn't*
have this extension will simply ignore Addresses that it can't
process– unless, with our current configuration, it mistakes these
Addresses for TargAddresses, that is. Again, this has been explained
multiple times and I'm running out of ways to rephrase it.
I'm not asking you to rephrase it. I'm asking you to consider the
history, which
is that in almost 20 years no one has ever pointed out the need for more
addresses in RREQ and RREP except for source routes, which aren't supported
in RFC 5444. Furthermore, the future extension COULD be added in a way that
is backwards compatible with existing AODVv2, but without a specific example
it's hard to make a specific answer to show that.
Again, I fully understand the argument that has been put forward.
But in case the above isn't clear, I'll try more granularity:
No, it wouldn't. There can be RFCs that specify optional extensions,
and they can add optional addresses.
This is not at issue.
Any AODVv2 router that *doesn't* have this extension will simply
ignore Addresses that it can't process
Do you mean the new extension in a future RFC? Presumably the new
addresses would be put
there for some reason, and they are NOT the TargAddress. So, (a) they
cannot ignore existing
AODVv2 mechanisms and still claim to be part of AODV and (b) the
processing remains trivial.
– unless, with our current configuration, it mistakes these Addresses
for TargAddresses, that is. Again, this has been explained multiple
times and I'm running out of ways to rephrase it.
Well, I am sorry it is frustrating but we can go about this in an
orderly fashion
and in a spirit of mutual cooperation on the discussion. I may continue
to disagree
if you tell me something is impossible when I know how to do it, but
that's not
a sign of being hard to get along with (is it??)
Now if the argument is that we are dealing with entrenched positions that
are not amenable to technical discussion, then it gets down to some
political
situation roughly akin to blackmail. It would not be the first time.
I would just take the statement that technical discussion does not matter
and frame it with proper attribution, and be done with it.
So please let me know if it's a technical discussion or a political
discussion.
We're having the same arguments elsewhere about metrics that do not
monotonically increase. I would respectfully request that we do build
in some ability to add experimental Data Items; it's been done on
DLEP. Take a look at draft 9 that was published last Friday.
Is DLEP concerned with multihop paths?
If not, can I delay this particular request? Of course I don't mind if you
mention that such things are for further study. But right now I have
too many
alligators attached to my rear end and I don't really want to work on DLEP.
[ref A]
Again: In 5444 packets, we do not have control which address goes
into which address block. This is done by the 5444 builder/parser,
which we have no control over. The builder/parser will rearrange
stuff in order to create the smallest packets it can.
How many address blocks do we have for RREQ or RREP messages?
Maybe you meant to say that we do not have control over where
RFC 5444 parser puts the addresses within an address block.
Back in the land of AODV, aren't we supposed to get *data elements* from
RFC 5444? Can we frame this discussion using the terminology of data
elements?
Now what happens if we get an OrigSeqNum data element associated with
an address, and another address with no SeqNum data element associated?
I don't see why RFC 5444 has a problem with that, and it's trivial to
process.
Regards,
Charlie P.
Other related posts:
