[aodvv2-discuss] Re: Draft 13c
- From: Stan Ratliff <ratliffstan@xxxxxxxxx>
- To: "aodvv2-discuss@xxxxxxxxxxxxx" <aodvv2-discuss@xxxxxxxxxxxxx>
- Date: Mon, 23 Nov 2015 15:36:54 -0500
On Mon, Nov 23, 2015 at 3:05 PM, Charlie Perkins <
charles.perkins@xxxxxxxxxxxxx> wrote:
Hello Vicky,
One has to wonder how OLSRv2 derives the MTU constraints...
And how does an implementation of NHDP go about limiting the information?
SMF is Experimental.
LOADng is inadequate in many ways.
The maximum message size which Henning mentions is exactly what I think
needs to be specified.
If, for instance, an RFC 5444 implementation does this correctly and
provides a maximum message size,
it is this size which AODVv2 needs to respect when creating protocol
messages. If an implementor has
to use an RFC 5444 implementation that fails to specify this constraint,
then some choice has to be made
according to the most likely MTU at layer 3.
I am very skeptical that RFC 5444 will know a lot about RERR messages to
handle them correctly.
Stan, I hope we can have a reasonable discussion about this. I feel like
my cheerleading team is too small.
It depends on what you mean by "a reasonable discussion about this". If you
mean:
1. "Everybody else gives up and lets Charlie put what he wants into the
document", *OR*
2. "We're going to discuss this ad-nauseum and then come to absolutely no
conclusion at all, because we're all tired of typing at each other",
then the answer is : 'No, we're not going to have a reasonable discussion.'
At this point, I see the evidence as overwhelming that the document SHOULD
NOT mention MTU. Multiple reasons have been cited:
1. The responsibility for control plane segmentation/reassembly is
RFC5444's.
2. With present technology, protocols running on top of 5444
implementations do not, and cannot, know the MTU
3. Corresponding drafts in the MANET working group do NOT mention MTU, or
do so only obliquely (and pretty much without substance).
You have, IMO, responded either with musings about how other protocols
address that which they do not document (see point 3 above), or dismissing
the reference in its entirety ("LOADng is inadequate in many ways" - Funny
that they've said the same thing about AODVv2). The dismissal is most
unhelpful - pretty much a waste of my time reading it, so I hope it helped
you to take the time to type it.
Oh, and in addition to the above musings, you express skepticism... Your
skepticism, plus $10 US, will buy me a Latte in the trendy, up-scale coffee
house of my choosing.
Bottom line: I don't see a *technical* argument for re-inserting the MTU
text. I have seen *technical* rationale for removing it. The sand is
running out of the hourglass. Time to "Shoot, or get off the pad." If you
have a productive, enlightening, technical argument, then present it. If
all you're offering is skepticism and dismissal, we're done here.
Stan
Other related posts:
