Hi Stan,
I like that text :-)
Vicky.
On 6 Oct 2015 7:20 pm, "Ratliff, Stanley" <sratliff@xxxxxxxxxxx> wrote:
FWIW, I think this conversation is spot-on, and is a good thing. Having
said that, I think there’s one additional step for us to consider:
IIRC, part of the question/issue around RFC 6621 use was whether it
induces interoperability problems unless ALL AODVv2 routers are running it
at the same time. I think the conclusion we came to was that there was no
interoperability issue; but that such a “mixed-mode” (some RFC 6221, some
without) network would result in higher overhead (e.g., messages would
possibly be sent when they really weren’t required).
Any text changed in the spec needs to include the above. Here’s my
suggested text: “Implementations MAY choose to employ techniques to reduce
the number of multicast messages sent. Use of {RFC 6621] in deployments is
recommended. Employing [RFC 6621] in a subset of the operational AODVv2
routers in a network will not cause interoperability issues, but will
reduce the effectiveness of the multicast reduction scheme.”
… or something like that. Other thoughts?
Regards,
Stan
*From:* aodvv2-discuss-bounce@xxxxxxxxxxxxx [mailto:
aodvv2-discuss-bounce@xxxxxxxxxxxxx] *On Behalf Of *Charlie Perkins
*Sent:* Tuesday, October 06, 2015 12:22 PM
*To:* aodvv2-discuss@xxxxxxxxxxxxx
*Subject:* [aodvv2-discuss] Re: RFC 6621 considerations
Hello Vicky,
On 10/6/2015 5:26 AM, Victoria Mercieca wrote:
Hi...
I think the last call we had, we stated that 6621 would run alongside
AODVv2... As far as I understand it (and I dont profess to understand much
about 6621) 6621 determines whether a node needs to re-send a multicast
message. i.e. if it doesnt re-send it, will everyone still hear it?
Yes, that is right.
Also, the message itself would be sent unchanged, but this is not what we
want in AODVv2 is it? We want AODVv2 to get the message and decide whether
to regenerate it.
We want AODVv2 to use RFC 6621 to decide whether or not to transmit
messages to the multicast group. It does not matter what the message is.
So would 6621 give AODVv2 an indication of whether it thought it would
re-send a received message, then let AODVv2 update and send the regenerated
version? I dont understand how the two would work together.
RFC 6621 would determine whether a node sends *any* message to the
multicast group.
Regards,
Charlie P.
Regards,
Vicky.
On Wed, Sep 30, 2015 at 1:45 AM, Charlie Perkins <
charles.perkins@xxxxxxxxxxxxx> wrote:
Hello folks,
We had a discussion thread about the use of techniques in RFC 6621. I
mentioned at the time that I was not aware of any downside in the
circumstance that some AODVv2 routers would implement RFC 6621 and others
would not.
That isn't a very precise statement because there is more than one
algorithm discussed in RFC 6621; moreover, there is more than one kind of
"downside". Nevertheless, to the best of my knowledge my claim remains
true "in spirit". Here is some example text taken from Appendix A of RFC
6621, which is naturally much more precise than my earlier claim.
The "Essential Connected Dominating Set" (E-CDS) algorithm [RFC5614]
forms a single CDS mesh for the SMF operating region. It allows
routers to use 2-hop neighborhood topology information to dynamically
perform relay self-election to form a CDS. Its packet-forwarding
rules are not dependent upon previous hop knowledge. Additionally,
E-CDS SMF forwarders can be easily mixed without problems with CF SMF
forwarders, even those not participating in NHDP. Another benefit is
that packets opportunistically received from non-symmetric neighbors
may be forwarded without compromising flooding efficiency or
correctness. Furthermore, multicast sources not participating in
NHDP may freely inject their traffic, and any neighboring E-CDS
relays will properly forward the traffic.
If we specialize our suggestion to say E-CDS instead of RFC 6621, it might
curtail some uncertainty. And I like E-CDS the best. Nevertheless, I
believe the same considerations hold for MPR selection algorithms.
Regards,
Charlie P.
_____________________________________________________
This electronic message and any files transmitted with it contains
information from iDirect, which may be privileged, proprietary
and/or confidential. It is intended solely for the use of the individual
or entity to whom they are addressed. If you are not the original
recipient or the person responsible for delivering the email to the
intended recipient, be advised that you have received this email
in error, and that any use, dissemination, forwarding, printing, or
copying of this email is strictly prohibited. If you received this email
in error, please delete it and immediately notify the sender.
_____________________________________________________
