[aodvv2-discuss] Re: RFC5444 feedback pt. 1

  • From: Lotte Steenbrink <lotte.steenbrink@xxxxxxxxxxxx>
  • To: aodvv2-discuss@xxxxxxxxxxxxx
  • Date: Mon, 20 Apr 2015 16:54:26 +0200

Hi,

Am 20.04.2015 um 15:42 schrieb Charlie Perkins <charles.perkins@xxxxxxxxxxxxx>:

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.

RFC 5444 can't. Documents that specify extensions to AODVv2 can.

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?

Maybe I did? As far as I understood it, the options you brought up were
- update the entire AODVv2 RFC
- make a certain extension mandatory.

If “update the entire AODVv2 RFC” implies “extansions can be added by updating
the (hopefully, one day) AODVv2 RFC with optional features”... That's
problematic too, in my opionion.
It makes the root document harder to read and is probably a pain to get done
(and through last call), and I don't see any benefits over modularly adding
dedicated documents for specific, optional extensions.
Or did I miss something else entirely?



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.

Well, there could be. For example, it doesn't make sense to me that PktSrc in

What am I missing here? There is not a need to mark addresses
mandated within RFC 5444.

Yes, there is, as it has been explained multiple times now. And we don't even
have to talk about future extensions here. Take PktSource, for example:
PktSource is currently an Address TLV. Especially in an IPv6 network, that is
going to be one huge blob of data. Instead, we could (and, imho, should) add
PktSource as a regular Address to the Address Block. Assuming that the
PktSource will be very likely to share a prefix with some of the other
Addresses in the Address Block, the RFC 5444 builder/parser can then employ its
address compression magic and probably shave off more than the 3-6 bytes which
naming TLVs add to the packet size.


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.

I think I have enough home work trying to figure out the packet situation
as-is, thank you.


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,

And how would hat happen?

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.


Because?

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.

How is the processing algorithm to know for certain that they are NOT the
TargAddress, exactly?


– 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??)

You know how to tweak RFC 5444 into building packets that are technically
legal, but go contrary to the (ridiculously underdocumented) idea of RFC 5444.
I do not think that “technically legal” is a very strong argument, especially
if there are technical arguments against your proposal.


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.


Excuse me? I am trying to do my job here. I have no interest in fueling any
political discussion. I just want to get this document over the finish line.



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.



I'm afraid I can't follow you... Could you rephrase your argument?

Regards,
Lotte

Regards,
Charlie P.



Other related posts: