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

  • From: Charlie Perkins <charles.perkins@xxxxxxxxxxxxx>
  • To: aodvv2-discuss@xxxxxxxxxxxxx
  • Date: Mon, 20 Apr 2015 10:34:34 -0700

Hello Lotte,

A little follow-up below...

On 4/20/2015 7:54 AM, Lotte Steenbrink wrote:


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.

It is currently a Message 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.

I am O.K. with that, but it's never been that way before and no one asked for it.

So your argument with PktSource is that we can be more efficient by converting it
to an Address Block TLV. That is different than the claim that all addresses must be
marked. Moreover, if the PktSource is an Address Block TLV, then it does not mean
that the other address in the Address Block TLV has to be marked to say that it is
"not PktSource".


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.

Well if you don't want to try it, you can take my word that it's practically
impossible. And then we have:


Did someone want to claim that source routing requires
improper routing protocol elements?


I am guessing that no router protocol person in the IETF would make such
a claim, unless they were just being contrarian. Check the new WG on
segment routing. They might be offended if you told them that source
routing was not useful.



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?

It would be nice to have a specific example. But in a little while I will make
up a future Address Block TLV and use it for an example. By doing this, I leave
myself open to the suggestion that my example is not realistic. Which would
be weird, because I am claiming that adding such TLVs is not realistic. But I
will be happy to work with anyone else's example.


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?

I am not sure I get your meaning, but it's because we all agree that
future RFCs can 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
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?

Mainly because there would be an address not marked for any other purpose.


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.

Well, I am trying to have exactly that technical discussion.

In other working groups, technically legal is darned sure a strong argument.
If the WG feels strongly that some technical problem has been caused by use
of some unintentional feature, then that needs to be redressed by another
specification.

But even more to the point my unfortunately brief foray into commentary
regarding RFC 5444 (as you might say, "back in the day") I was assured that
RFC 5444 was designed to be minimally intrusive in protocol design. That
had the effect of providing me with assurance that AODVv2 would not have
problems with its then-current design. Moreover, Ian Chakeres who was the
author of the coalescence RFC with RFC 5444 was never told that these
considerations would block AODVv2. Recall that he wrote a great deal of
the text that Victoria is currently rewriting.

So I don't think that the use of existing mechanism is merely "technically
legal" (but unintentional) since it was just fine with Ian's RFC 5444 collaborators
when he was doing the conversion from DYMO packet formats to RFC 5444.




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.

O.K. I did not say it was a political discussion, and I am delighted that you
don't think it is a political discussion.



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?

I'll be happy to try, but it would be helpful if you could point out the part
that stops making sense to you...

Breaking it down:

How many address blocks do we have for RREQ or RREP messages?

I am asking, but I reckon the answer is one.


Maybe you meant to say that we do not have control over where
RFC 5444 parser puts the addresses within an address block.

John said we don't have control over which address goes into which address
block, and I thought we only had one 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?

Is this question hard to follow?


Now what happens if we get an OrigSeqNum data element associated with
an address, and another address with no SeqNum data element associated?

I am not sure if this statement is viewed as mysterious.


I don't see why RFC 5444 has a problem with that, and it's trivial to process.

O.K. If RFC 5444 returns an address with OrigSeqNum data element and
another address without any Address Block TLVs, then (for messages RREQ
and RREP) the other address is the Target Address. If, for instance, there is
a third address with some newly defined TLV associated with it, the previous
sentence still holds true.

Restating this from the other way around, RFC 5444 is returning addresses
and associated data elements, and the address without any other associated
Address Block TLV is (in this example) the Target Address.

Regards,
Charlie P.



Other related posts:

  1. Home
  2. aodvv2-discuss
  3. Archive
  4. 04-2015