Subject: [manet] Using RFC 6621

From: Charlie Perkins <[email-masked]>
Date: Thu, 3 Mar 2016 07:52:12 -0800

Hello folks,

There has been some discussion about whether or not RFC 6621 algorithms 
could be used with AODVv2.

I wrote a short draft on the subject; feedback especially of the 
constructive variety is solicited and welcome.

Here's the URL for the text:
https://www.ietf.org/id/draft-perkins-manet-using-rfc6621-00.txt

Regards,
Charlie P.

---

From: Victoria Mercieca <[email-masked]>
Date: Thu, 3 Mar 2016 16:24:29 +0000

Hi all,

I believe that we caused a lot of confusion with our attempt to explain
this in the past, which is why references to RFC 6621 were removed from the
core draft.

Charlie's new draft explains that if AODVv2 knew whether the router was
elected as a router that should forward multicast traffic, then it could
decide whether it should regenerate messages. This would be a general rule,
rather than based on feedback from RFC 6621 on a per-packet basis. We dont
want packets to be forwarded by some type of 6621 implementation since we
want AODVv2 to process and regenerate them instead. 6621 also discusses
duplicate suppression, which is also something AODVv2 wants to do its own
way. In fact the rules in RFC 6621 would indicate that AODVv2 messages
(inside RFC5444 packets of course) would not be suitable for forwarding.

I think Charlie's technique is already allowed by statements in the AODVv2
draft like "The router MAY choose not to regenerate the RREQ". This covers
implementers who wish to be clever with any 6621-inspired decisions,
without explicitly referencing RFC 6621.

If one AODVv2 implementation doesnt use that technique, it will regenerate
each message according to the main rules in the draft. If another AODVv2
implementation does use that technique, and it knows it is elected as a
member of the Relay Set, it can also regenerate each AODVv2 message
according to the main rules in the draft. If it is not elected as a member
of the Relay Set, it will not regenerate AODVv2 messages. This should not
stop any route discoveries because there should be enough forwarding nodes
elected (outside the scope of AODVv2) to ensure that the route message
reaches the target's router. I imagine it could have an effect of a
non-optimal route being chosen, i.e. not finding the best path to achieve
the best metric.

It would be assumed that the network is configured so that all routers used
the same relay set selection algorithm. This would not be under the control
of AODVv2.

So in summary:
AODVv2 would know whether the router was part of a relay set. AODVv2
messages wouldnt be forwarded according to the usual interpretation of RFC
6621. The important element is the knowledge of whether the router is
responsible for forwarding multicast traffic in general. This is a signal
to AODVv2 that when it receives AODVv2 messages, it should regenerate them.

Kind regards,
Victoria.

On Thu, Mar 3, 2016 at 3:52 PM, Charlie Perkins <
[email-masked]> wrote:

> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet
>

---

From: Charlie Perkins <[email-masked]>
Date: Thu, 3 Mar 2016 08:47:09 -0800

Hello Vicky,

Thanks for enlarging on the context for this discussion.  You raised the 
issue about effects on ability to discover optimal routes.

It is true that using a multicast backbone for route discovery can 
result in failure to discover optimal routes.  The deviation from 
optimal is sometimes measured by a parameter named "stretch", which can 
be defined as the average percentage increase of "discovered route 
metric" compared to "optimal route metric".

This deviation from optimality is usually pretty small (under 10%), and 
it gets smaller with increasing density of the network.   In return, 
using the multicast backbone brings a great reward in reducing 
interference, providing a significant performance benefit overall.

Regards,
Charlie P.

On 3/3/2016 8:24 AM, Victoria Mercieca wrote:
> Hi all,
>
> I believe that we caused a lot of confusion with our attempt to 
> explain this in the past, which is why references to RFC 6621 were 
> removed from the core draft.
>
> Charlie's new draft explains that if AODVv2 knew whether the router 
> was elected as a router that should forward multicast traffic, then it 
> could decide whether it should regenerate messages. This would be a 
> general rule, rather than based on feedback from RFC 6621 on a 
> per-packet basis. We dont want packets to be forwarded by some type of 
> 6621 implementation since we want AODVv2 to process and regenerate 
> them instead. 6621 also discusses duplicate suppression, which is also 
> something AODVv2 wants to do its own way. In fact the rules in RFC 
> 6621 would indicate that AODVv2 messages (inside RFC5444 packets of 
> course) would not be suitable for forwarding.
>
> I think Charlie's technique is already allowed by statements in the 
> AODVv2 draft like "The router MAY choose not to regenerate the RREQ". 
> This covers implementers who wish to be clever with any 6621-inspired 
> decisions, without explicitly referencing RFC 6621.
>
> If one AODVv2 implementation doesnt use that technique, it will 
> regenerate each message according to the main rules in the draft. If 
> another AODVv2 implementation does use that technique, and it knows it 
> is elected as a member of the Relay Set, it can also regenerate each 
> AODVv2 message according to the main rules in the draft. If it is not 
> elected as a member of the Relay Set, it will not regenerate AODVv2 
> messages. This should not stop any route discoveries because there 
> should be enough forwarding nodes elected (outside the scope of 
> AODVv2) to ensure that the route message reaches the target's router. 
> I imagine it could have an effect of a non-optimal route being chosen, 
> i.e. not finding the best path to achieve the best metric.
>
> It would be assumed that the network is configured so that all routers 
> used the same relay set selection algorithm. This would not be under 
> the control of AODVv2.
>
> So in summary:
> messages wouldnt be forwarded according to the usual interpretation of 
> RFC 6621. The important element is the knowledge of whether the router 
> is responsible for forwarding multicast traffic in general. This is a 
> signal to AODVv2 that when it receives AODVv2 messages, it should 
> regenerate them.
>
> Kind regards,
> Victoria.
>
> On Thu, Mar 3, 2016 at 3:52 PM, Charlie Perkins 
> <[email-masked] <mailto:[email-masked]>> 
> wrote:
>
>
>     Hello folks,
>
>     There has been some discussion about whether or not RFC 6621
>     algorithms could be used with AODVv2.
>
>     [email-masked] <mailto:[email-masked]>

---

From: Charlie Perkins <[email-masked]>
Date: Thu, 3 Mar 2016 09:18:27 -0800

Hello Chris,

On 3/3/2016 9:03 AM, Christopher Dearlove wrote:
>
> Consequently AODVv2 can't use RFC 6621. Maybe you intended that it could, but the requirement to use the 5444 architecture was imposed by RFC 5498. Written by your then co-author.

I have talked with Ian about this more than once, and he assures me that 
he never imagined that RFC 5498 would be used to inhibit useful 
functionality such as this.  Indeed, not until long afterwards were so 
many restrictions put into place -- often with the justification that 
such restrictions made message data easier to parse.

Do you mean to say that an AODVv2 implementation cannot know whether or 
not it is running on a device that is part of the multicast relay set?  
This sounds much more like a problem with RFC 5444 than a problem with 
AODVv2.

Regards,
Charlie P.

---

From: Christopher Dearlove <[email-masked]>
Date: Thu, 3 Mar 2016 17:50:15 +0000

This is message Charlie has already replied to because I sent it from an account not a member of this list.

--  
Christopher Dearlove
[email-masked]

> On 3 Mar 2016, at 17:03, Christopher Dearlove <[email-masked]> wrote:
> 
> Sorry, that draft continues to miss the point. And that's a continuation of what's in the AODVv2 draft, Section 6.5 for example.
> 
> AODVv2 does not send messages over UDP. It sends messages to the RFC 5444 multiplexer which assembles packets hop by hop. The AODVv2 draft continues to not recognise this. It needs to get it right.  It's not as if this is the first time this has been pointed out.
> 
> Consequently AODVv2 can't use RFC 6621. Maybe you intended that it could, but the requirement to use the 5444 architecture was imposed by RFC 5498. Written by your then co-author. It wasn't the OLSRv2/5444 authors who made that - in fact we got extra work dumped on us by 5498 and the IESG. But it was accepted as WG policy, is embodied in Proposed Standards, and the basis on which the Manet port and protocol are allocated.
> 
> Can you use the ideas in 6621? Yes of course. But they need to be defined in AODVv2. And reimplemented - you can't for example use IP options because you don't control that. And any IP packet contains a 5444 packet (one hop only) that may contain one or more AODVv2 messages and/or other MANET messages e.g. NHDP HELLO messages. So you would probably need a message TLV.
> 
> And that is exactly therefore what's done in OLSRv2. And it's not a trivial exercise. But if you want that functionality, it's your only option with the mandated architecture.
> 
> --  
> Christopher Dearlove
> [email-masked]
> 
>> On 3 Mar 2016, at 15:52, Charlie Perkins <[email-masked]> wrote:
>> 
>> 
>> Hello folks,
>> 
>> There has been some discussion about whether or not RFC 6621 algorithms could be used with AODVv2.
>> 
>> I wrote a short draft on the subject; feedback especially of the constructive variety is solicited and welcome.
>>

---

From: Christopher Dearlove <[email-masked]>
Date: Thu, 3 Mar 2016 17:50:34 +0000

If you let individual routers decide about relaying, messages will get lost. There are, for example, some issues in getting MPRs right (especially with multiple interfaces)  and CDRs take some coordination too. So if you want interoperable, they need to make a common decision.

What I don't know - but would be very wary of without a rigorous proof - is whether you can define a forwarding process that works with a mixture of routers using it and routers forwarding everything. If someone has one of those, things get more interesting. If you do, I'd like to see it.

--  
Christopher Dearlove
[email-masked] (iPhone)
[email-masked] (home)
> On 3 Mar 2016, at 16:24, Victoria Mercieca <[email-masked]> wrote:
> 
> Hi all,
> 
> I believe that we caused a lot of confusion with our attempt to explain this in the past, which is why references to RFC 6621 were removed from the core draft. 
> 
> Charlie's new draft explains that if AODVv2 knew whether the router was elected as a router that should forward multicast traffic, then it could decide whether it should regenerate messages. This would be a general rule, rather than based on feedback from RFC 6621 on a per-packet basis. We dont want packets to be forwarded by some type of 6621 implementation since we want AODVv2 to process and regenerate them instead. 6621 also discusses duplicate suppression, which is also something AODVv2 wants to do its own way. In fact the rules in RFC 6621 would indicate that AODVv2 messages (inside RFC5444 packets of course) would not be suitable for forwarding.
> 
> I think Charlie's technique is already allowed by statements in the AODVv2 draft like "The router MAY choose not to regenerate the RREQ". This covers implementers who wish to be clever with any 6621-inspired decisions, without explicitly referencing RFC 6621.
> 
> If one AODVv2 implementation doesnt use that technique, it will regenerate each message according to the main rules in the draft. If another AODVv2 implementation does use that technique, and it knows it is elected as a member of the Relay Set, it can also regenerate each AODVv2 message according to the main rules in the draft. If it is not elected as a member of the Relay Set, it will not regenerate AODVv2 messages. This should not stop any route discoveries because there should be enough forwarding nodes elected (outside the scope of AODVv2) to ensure that the route message reaches the target's router. I imagine it could have an effect of a non-optimal route being chosen, i.e. not finding the best path to achieve the best metric.
> 
> It would be assumed that the network is configured so that all routers used the same relay set selection algorithm. This would not be under the control of AODVv2. 
> 
> So in summary: 
> AODVv2 would know whether the router was part of a relay set. AODVv2 messages wouldnt be forwarded according to the usual interpretation of RFC 6621. The important element is the knowledge of whether the router is responsible for forwarding multicast traffic in general. This is a signal to AODVv2 that when it receives AODVv2 messages, it should regenerate them.
> 
> Kind regards,
> Victoria.
> 
>> On Thu, Mar 3, 2016 at 3:52 PM, Charlie Perkins <[email-masked]> wrote:
>> 
>> Hello folks,
>>

---

From: Christopher Dearlove <[email-masked]>
Date: Thu, 3 Mar 2016 17:50:53 +0000

No, I'm saying you need a mechanism to establish that set, and you don't have one until you define it.

And you can't just say "use 6621" because that is about forwarding whole IP packets. Which you can't, because they contain non-AODVv2 material.

As for what Ian intended, can't help you there.

> On 3 Mar 2016, at 17:18, Charlie Perkins <[email-masked]> wrote:
> 
> Hello Chris,
> 
> I have talked with Ian about this more than once, and he assures me that he never imagined that RFC 5498 would be used to inhibit useful functionality such as this.  Indeed, not until long afterwards were so many restrictions put into place -- often with the justification that such restrictions made message data easier to parse.
> 
> Do you mean to say that an AODVv2 implementation cannot know whether or not it is running on a device that is part of the multicast relay set?  This sounds much more like a problem with RFC 5444 than a problem with AODVv2.
> 
> Regards,
> Charlie P.
>

---

From: Justin Dean <[email-masked]>
Date: Thu, 3 Mar 2016 13:10:16 -0500

You could use the adopt the algorithmic sections in the appendix of 6621
along with a newly defined NHDP Hello message TLV defining algorithmic use
for AODVv2 "forwarding/regeneration".  The defined TLVs won't work because
the suggest standard IP packet SMF forwarding which is not happening here.
All of this can be done after AODVv2 is finished and the only hook required
would be that AODVv2 routers MAY decide not to regenerate RREQs if they are
unwilling to forward traffic or for other reasons which are outside of the
scope of the base specification.  I suggest you go this route and remove
any normative references to 6621.

I'd also like to point out that AODVv2 does correctly specify that messages
only go one hop and are regenerated along the paths of "forwarding".  At
least it was clear to me in my reading.

Justin

On Thu, Mar 3, 2016 at 12:50 PM, Christopher Dearlove <
[email-masked]> wrote:

> And you can't just say "use 6621" because that is about forwarding whole
> IP packets. Which you can't, because they contain non-AODVv2 material.
>
> >> Consequently AODVv2 can't use RFC 6621. Maybe you intended that it
> could, but the requirement to use the 5444 architecture was imposed by RFC
> 5498. Written by your then co-author.
> >
> functionality such as this.  Indeed, not until long afterwards were so many
> restrictions put into place -- often with the justification that such
> restrictions made message data easier to parse.
> >

---

From: Christopher Dearlove <[email-masked]>
Date: Thu, 3 Mar 2016 18:25:31 +0000

Yes, it does that. But it doesn't note that its messages are passed to the multiplexer but (in Section 6.5 in particular) discusses about how AODVv2 sends messages over the Manet port. It doesn't. It passes messages to the multiplexer, which assembles packets that might have other protocol material it, and it sends the packets that way - and only one hop. This also applies to earlier comments.

Incidentally the modification of the message is another reason you need a dedicated process. As Justin as noted.

> On 3 Mar 2016, at 18:10, Justin Dean <[email-masked]> wrote:
> 
> You could use the adopt the algorithmic sections in the appendix of 6621 along with a newly defined NHDP Hello message TLV defining algorithmic use for AODVv2 "forwarding/regeneration".  The defined TLVs won't work because the suggest standard IP packet SMF forwarding which is not happening here.  All of this can be done after AODVv2 is finished and the only hook required would be that AODVv2 routers MAY decide not to regenerate RREQs if they are unwilling to forward traffic or for other reasons which are outside of the scope of the base specification.  I suggest you go this route and remove any normative references to 6621.  
> 
> I'd also like to point out that AODVv2 does correctly specify that messages only go one hop and are regenerated along the paths of "forwarding".  At least it was clear to me in my reading.
> 
> Justin
> 
>> On Thu, Mar 3, 2016 at 12:50 PM, Christopher Dearlove <[email-masked]> wrote:

---

From: Victoria Mercieca <[email-masked]>
Date: Thu, 3 Mar 2016 18:40:30 +0000

Hi Justin.

Just one comment in line.

I would like to point out that this is what we already did. And I pointed
out, in my earlier email,  the statement that says 'MAY decide not to
regenerate.'

Kind regards,
Vicky.

> I'd also like to point out that AODVv2 does correctly specify that
messages only go one hop and are regenerated along the paths of
"forwarding".  At least it was clear to me in my reading.
>> >
>> > I have talked with Ian about this more than once, and he assures me
that he never imagined that RFC 5498 would be used to inhibit useful
functionality such as this.  Indeed, not until long afterwards were so many
restrictions put into place -- often with the justification that such
restrictions made message data easier to parse.
>> >
>> > Do you mean to say that an AODVv2 implementation cannot know whether
or not it is running on a device that is part of the multicast relay set?
This sounds much more like a problem with RFC 5444 than a problem with
AODVv2.

---

From: Thomas Heide Clausen <[email-masked]>
Date: Thu, 3 Mar 2016 19:41:06 +0100

> On 03 Mar 2016, at 19:10, Justin Dean <[email-masked]> wrote:
> 

Yes, but as Ulrich has pointed out, the “regeneration” approach is problematic in terms of a security architecture — it also “deactivates” the effective use of the RFC5497 hop-scoped TLVs as well as of hop-limit/hop-count for scope limited flooding.

On the security architecture issue, “regenerating” a message hop-by-hop nullifies the ability to, for example, use aggregate signatures for path verification. There are (advanced) signature schemes that are tolerant to mutable fields in a forwarded packet, which could be potential candidate solutions with a “forwarding” rather than “regenerating” architecture, such as what Ulrich has proposed.

> Justin
> 
> On Thu, Mar 3, 2016 at 12:50 PM, Christopher Dearlove <[email-masked] <mailto:[email-masked]>> wrote:
> [email-masked] <mailto:[email-masked]>
> 
> 
> 
> --
> Christopher Dearlove
> [email-masked] <mailto:[email-masked]> (iPhone)
> [email-masked] <mailto:[email-masked]> (home)
> > On 3 Mar 2016, at 17:18, Charlie Perkins <[email-masked] <mailto:[email-masked]>> wrote:
> >
> > Hello Chris,
> >
> https://www.ietf.org/mailman/listinfo/manet <https://www.ietf.org/mailman/listinfo/manet>
>

---

From: Stan Ratliff <[email-masked]>
Date: Thu, 3 Mar 2016 13:42:21 -0500

Gents,

Would text along the lines of this help to explain? I understand it may
well need additional word-smithing, but:

"One example of an optimization would be to exploit the information base
built by an implementation of [RFC6621]. In environments where this
information base is available, and accessible by the AODVv2 process, AODVv2
MAY determine whether the node is a part of the [RFC6621] multicast relay
set, and use this information to determine whether the message needs to be
regenerated. The exact nature of this optimization, and the mechanisms for
inter-process communication, are out of scope for this document, and left
to the implementer."

Because what we're talking about here is leveraging the knowledge that a
co-resident 6621 implementation would have about membership in the relay
set, as a trigger for whether or not the message needs to be regenerated.

Regards,
Stan

On Thu, Mar 3, 2016 at 1:25 PM, Christopher Dearlove <
[email-masked]> wrote:

> Yes, it does that. But it doesn't note that its messages are passed to the
> multiplexer but (in Section 6.5 in particular) discusses about how AODVv2
> sends messages over the Manet port. It doesn't. It passes messages to the
> multiplexer, which assembles packets that might have other protocol
> material it, and it sends the packets that way - and only one hop. This
> also applies to earlier comments.
>

---

From: Christopher Dearlove <[email-masked]>
Date: Thu, 3 Mar 2016 18:44:29 +0000

The question is, will messages always get to all destinations if some choose not to regenerate and send? Or, better, how is full delivery ensured, what restrictions are there?

> On 3 Mar 2016, at 18:40, Victoria Mercieca <[email-masked]> wrote:
> 
> Hi Justin.
> 
> I would like to point out that this is what we already did. And I pointed out, in my earlier email,  the statement that says 'MAY decide not to regenerate.'
> 
> Kind regards, 
> Vicky.
>

---

From: Stan Ratliff <[email-masked]>
Date: Thu, 3 Mar 2016 13:50:20 -0500

Chris,

It's absolutely worth quoting other possible sources... it's just that I
can't think of any other sources at the moment... ;-)

Regards,
Stan

On Thu, Mar 3, 2016 at 1:47 PM, Christopher Dearlove <
[email-masked]> wrote:

> I'm reading on a phone, so I want to read more carefully, but that looks
> the sort of thing wanted. Is it worth quoting other possible sources of
> information?
>
> --
> Christopher Dearlove
> On 3 Mar 2016, at 18:42, Stan Ratliff <[email-masked]> wrote:
>
> Gents,
>
>> Yes, it does that. But it doesn't note that its messages are passed to
>> the multiplexer but (in Section 6.5 in particular) discusses about how
>> AODVv2 sends messages over the Manet port. It doesn't. It passes messages
>> to the multiplexer, which assembles packets that might have other protocol

---

From: [email-masked]
Date: Thu, 3 Mar 2016 19:51:00 +0100

> On 03 Mar 2016, at 19:42, Stan Ratliff <[email-masked]> wrote:
> 
> Gents, 
> 
> Would text along the lines of this help to explain? I understand it may well need additional word-smithing, but: 
> 
> "One example of an optimization would be to exploit the information base built by an implementation of [RFC6621]. In environments where this information base is available, and accessible by the AODVv2 process, AODVv2 MAY determine whether the node is a part of the [RFC6621] multicast relay set, and use this information to determine whether the message needs to be regenerated. The exact nature of this optimization, and the mechanisms for inter-process communication, are out of scope for this document, and left to the implementer." 
> 
> Because what we're talking about here is leveraging the knowledge that a co-resident 6621 implementation would have about membership in the relay set, as a trigger for whether or not the message needs to be regenerated. 
> 

I have mentioned this repeatedly in the past: saying RFC6621 is just not sufficient here (even disregarding the “forwarding issue”)
If routers implement different flooding reduction algorithms to determine membership in the multicast relay set, then you can relatively easily end up with situations wherein part of your network is not covered by the flooding operation.

If you want to specify that “flooding reduction is possible, but we’re not going to tell you what algorithm” then the minimum requirement is to provide specific constraints on what those flooding reduction algorithms are allowed to do, and what they are not allowed to do.

In OLSRv2, we did that by way of specifying “each router must select a relay set which satisfies these conditions….” That’s one way to go — but it must be within the specification.

> 
> Regards,
> Stan
> 
> 
> On Thu, Mar 3, 2016 at 1:25 PM, Christopher Dearlove <[email-masked] <mailto:[email-masked]>> wrote:
> On 3 Mar 2016, at 18:10, Justin Dean <[email-masked] <mailto:[email-masked]>> wrote:
>

---

From: [email-masked]
Date: Thu, 3 Mar 2016 19:51:54 +0100

[I think I pulled a Chris, and hit sent with a non-member email address — apologies]

> On 03 Mar 2016, at 19:10, Justin Dean <[email-masked] <mailto:[email-masked]>> wrote:
>

---

From: Justin Dean <[email-masked]>
Date: Thu, 3 Mar 2016 14:18:36 -0500

On Thu, Mar 3, 2016 at 1:42 PM, Stan Ratliff <[email-masked]> wrote:

> A unmodified co-resident 6621 implementation would not provide all of the
information you need.  Similar to the point Thomas is making the "intent"
of other AODVv2 routers is unknown.  Without knowing what other AODVv2
routers are doing to reduce forwarding you can't assume your reductions
will work.  The TLVs defined in 6621 both facilitate algorithmic behaviors
and intent to forward multicast traffic based on those algorithms (i.e.
they do not convey intent to reduce or resend AODVv2 messages based on
those algorithms).  An identical TLVs (algorithmic and format speaking) but
with a new TLV IANA assignments could convey that intent and perform the
same way but that is not unmodified RFC6621

Suggested edit.

"One example of an optimization would be to exploit an information base
built by an implementation of [RFC6621] modified for use with AODVv2. Using
this information base, AODVv2 MAY determine whether the node is a part of
the reduced relay set, and use this information to determine whether the
message needs to be regenerated. The exact nature of this optimization, and
the mechanisms for inter-process communication, are out of scope for this
document, and left to the implementer."

Justin

---

From: Stan Ratliff <[email-masked]>
Date: Thu, 3 Mar 2016 14:34:36 -0500

Justin,

Thanks for that suggestion. Let me take that to the team.

Regards,
Stan

---

From: Victoria Mercieca <[email-masked]>
Date: Thu, 3 Mar 2016 19:35:51 +0000

Hi Thomas,

>>
>
> I have mentioned this repeatedly in the past: saying RFC6621 is just not
sufficient here (even disregarding the “forwarding issue”)
> If routers implement different flooding reduction algorithms to determine
membership in the multicast relay set, then you can relatively easily end
up with situations wherein part of your network is not covered by the
flooding operation.

I think you are saying it is not safe for aodvv2 to assume the network is
configured so that all routers are using the same selection algorithm?
Therefore, we need to also mandate that aodvv2 routers that use membership
of a relay set to influence regeneration MUST be configured to use the same
relay set selection algorithm.

Kind regards,
Victoria.

> If you want to specify that “flooding reduction is possible, but we’re
not going to tell you what algorithm” then the minimum requirement is to
provide specific constraints on what those flooding reduction algorithms
are allowed to do, and what they are not allowed to do.
>
> In OLSRv2, we did that by way of specifying “each router must select a
relay set which satisfies these conditions….” That’s one way to go — but it
must be within the specification.
>>>> You could use the adopt the algorithmic sections in the appendix of
6621 along with a newly defined NHDP Hello message TLV defining algorithmic
use for AODVv2 "forwarding/regeneration".  The defined TLVs won't work
because the suggest standard IP packet SMF forwarding which is not
happening here.  All of this can be done after AODVv2 is finished and the
only hook required would be that AODVv2 routers MAY decide not to
regenerate RREQs if they are unwilling to forward traffic or for other
reasons which are outside of the scope of the base specification.  I
suggest you go this route and remove any normative references to 6621.
[email-masked]> wrote:
>>>>> And you can't just say "use 6621" because that is about forwarding
whole IP packets. Which you can't, because they contain non-AODVv2 material.
>>>>> >
>>>>> > Do you mean to say that an AODVv2 implementation cannot know
whether or not it is running on a device that is part of the multicast
relay set?  This sounds much more like a problem with RFC 5444 than a
problem with AODVv2.

---

From: [email-masked]
Date: Thu, 3 Mar 2016 20:51:18 +0100

> On Mar 3, 2016, at 20:18, Justin Dean <[email-masked]> wrote:
> 
> 
> 
> On Thu, Mar 3, 2016 at 1:42 PM, Stan Ratliff <[email-masked] <mailto:[email-masked]>> wrote:
> Gents, 
> 
> A unmodified co-resident 6621 implementation would not provide all of the information you need.  Similar to the point Thomas is making the "intent" of other AODVv2 routers is unknown.  Without knowing what other AODVv2 routers are doing to reduce forwarding you can't assume your reductions will work.  The TLVs defined in 6621 both facilitate algorithmic behaviors and intent to forward multicast traffic based on those algorithms (i.e. they do not convey intent to reduce or resend AODVv2 messages based on those algorithms).  An identical TLVs (algorithmic and format speaking) but with a new TLV IANA assignments could convey that intent and perform the same way but that is not unmodified RFC6621
> 
> Suggested edit.
> 
> "One example of an optimization would be to exploit an information base built by an implementation of [RFC6621] modified for use with AODVv2. Using this information base, AODVv2 MAY determine whether the node is a part of the reduced relay set, and use this information to determine whether the message needs to be regenerated. The exact nature of this optimization, and the mechanisms for inter-process communication, are out of scope for this document, and left to the implementer." 
> 

If you are requiring agreement in how to modify an information base, and how to interpret the content therein (and/or, on how to interpret over-the-wire signals for modifying the information base) you’ve long left the realms of “out of scope for this document, and left to the implementer” and entered the realm of “specification required for interoperability”.

---

From: Christopher Dearlove <[email-masked]>
Date: Thu, 3 Mar 2016 20:24:29 +0000

Necessary (as far as I know). Sufficient logically, but is it sufficient procedurally, to say that. My reading the runes on what the IESG will want is imperfect (if it weren't I could become a very highly paid consultant just on doing that) but it's in my danger zone for acceptability.

> On 3 Mar 2016, at 19:35, Victoria Mercieca <[email-masked]> wrote:
> 
> Hi Thomas,
> 
> I think you are saying it is not safe for aodvv2 to assume the network is configured so that all routers are using the same selection algorithm? Therefore, we need to also mandate that aodvv2 routers that use membership of a relay set to influence regeneration MUST be configured to use the same relay set selection algorithm.
> 
> Kind regards, 
> Victoria. 
> 
> >> On Thu, Mar 3, 2016 at 1:25 PM, Christopher Dearlove <[email-masked]> wrote:
> >>>

---

From: Jiazi YI <[email-masked]>
Date: Thu, 3 Mar 2016 23:46:49 +0100

For me, using multicast suppression is OK, as long as it's clearly
specified.

RFC6621 is more like a "framework" for me:

     - A neighbour discovery module that can be NDHP or others. Especially,
the algorithms used in RFC6621 require bi-directional check of neighbors,
and 2-hop neighborhood discovery. I don't know how it's handled in AODVv2.

     - A duplicate detection module that can be identity-based or
hash-based. For this, AODVv2 has already its message sequence number.

     - A relay set selection module. RFC 6621 doesn't specify which
algorithm should be used, but simply provided some guidelines and 3
examples (E-CDS, MPR-CDS, S-MPR).

Without clear definition of the three modules above, even implementations
based on RFC6621 won't be able to interoperate -- I don't think it will
work or AODVv2 either.

>From the draft that you provided, I couldn't see how the issues can be
resolved.

best

Jiazi

---

From: Charlie Perkins <[email-masked]>
Date: Thu, 3 Mar 2016 15:31:12 -0800

Hello Jiazi,

AODVv2 can't take responsibility for everything the network does. AODVv2 
should just take care of establishing and maintaining routes.

If the nodes in the network offer multicast suppression, AODVv2 can use it.

If the nodes in the network don't work properly (say, regarding 
multicast suppression, or some other protocol) their improper operation 
can affect the network.

If there is a DNS server in the network, does this imply that AODVv2 has 
to mandate that it work properly?  Well if it doesn't, then maybe DNS 
won't work and then applications can't resolve names, and can't ask AODV 
to establish routes for the IP addresses, etc.

I'd like to write up an integrated version of AODVv2 with some variety 
of multicast suppression algorithm that seems to cooperate conveniently, 
but that's an optimization.  I don't know whether or not it would use 
NDHP, but it might steal some packet formats.

Regards,
Charlie P.

On 3/3/2016 2:46 PM, Jiazi YI wrote:
>      - A neighbour discovery module that can be NDHP or others. 
> Especially, the algorithms used in RFC6621 require bi-directional 
> check of neighbors, and 2-hop neighborhood discovery. I don't know how 
> it's handled in AODVv2.
>
> Without clear definition of the three modules above, even 
> implementations based on RFC6621 won't be able to interoperate -- I 
> don't think it will work or AODVv2 either.
>
> On Thu, Mar 3, 2016 at 4:52 PM, Charlie Perkins

---

From: Christopher Dearlove <[email-masked]>
Date: Fri, 4 Mar 2016 00:01:18 +0000

The network does not and fundamentally cannot offer multicast suppression to AODVv2. This isn't a hard concept, but seems to keep having to be said. AODVv2 messages are carried in 5444 packets, and those only travel one hop. That doesn't allow for suppression. Furthermore AODVv2 is creating new messages each hop. That needs AODVv2 specific handling.

Please, will someone else please try to get this over.

> On 3 Mar 2016, at 23:31, Charlie Perkins <[email-masked]> wrote:
> 
> Hello Jiazi,
> 
> AODVv2 can't take responsibility for everything the network does.  AODVv2 should just take care of establishing and maintaining routes.
> 
> If the nodes in the network don't work properly (say, regarding multicast suppression, or some other protocol) their improper operation can affect the network.
> 
> If there is a DNS server in the network, does this imply that AODVv2 has to mandate that it work properly?  Well if it doesn't, then maybe DNS won't work and then applications can't resolve names, and can't ask AODV to establish routes for the IP addresses, etc.
> 
> I'd like to write up an integrated version of AODVv2 with some variety of multicast suppression algorithm that seems to cooperate conveniently, but that's an optimization.  I don't know whether or not it would use NDHP, but it might steal some packet formats.
> 
> Regards,
> Charlie P.
> 
> 
> 
> 
>> For me, using multicast suppression is OK, as long as it's clearly specified. 
>> 
>>      - A neighbour discovery module that can be NDHP or others. Especially, the algorithms used in RFC6621 require bi-directional check of neighbors, and 2-hop neighborhood discovery. I don't know how it's handled in AODVv2. 
>> 
>>      - A duplicate detection module that can be identity-based or hash-based. For this, AODVv2 has already its message sequence number.  
>> 
>>      - A relay set selection module. RFC 6621 doesn't specify which algorithm should be used, but simply provided some guidelines and 3 examples (E-CDS, MPR-CDS, S-MPR). 
>> 
>> Without clear definition of the three modules above, even implementations based on RFC6621 won't be able to interoperate -- I don't think it will work or AODVv2 either. 
>> 
>> From the draft that you provided, I couldn't see how the issues can be resolved.
>> 
>> best
>> 
>> Jiazi
>> 
>> On Thu, Mar 3, 2016 at 4:52 PM, Charlie Perkins <[email-masked]> wrote:
>>> 
>>> Hello folks,
>>>

---

From: Thomas Heide Clausen <[email-masked]>
Date: Fri, 4 Mar 2016 01:13:23 +0100

> On 04 Mar 2016, at 00:31, Charlie Perkins <[email-masked]> wrote:
> 
> Hello Jiazi,
> 

If protocol X relies on using a flooding operation, then it certainly is protocol X's responsibility to  specify the flooding operation (or, at least, the requirements to the flooding operation ) for correct functioning of protocol X.

> If there is a DNS server in the network, does this imply that AODVv2 has to mandate that it work properly? 

If protocol X relies on specific functions being supported in a specific way from the DNS server, then yes - moreover, it has to specify those specific functions.

> Well if it doesn't, then maybe DNS won't work and then applications can't resolve names, and can't ask AODV to establish routes for the IP addresses, etc.
>

---

From: Jiazi YI <[email-masked]>
Date: Fri, 4 Mar 2016 01:19:55 +0100

On Fri, Mar 4, 2016 at 1:01 AM, Christopher Dearlove <
[email-masked]> wrote:

> The network does not and fundamentally cannot offer multicast suppression
> to AODVv2. This isn't a hard concept, but seems to keep having to be said.
> AODVv2 messages are carried in 5444 packets, and those only travel one hop.
> That doesn't allow for suppression. Furthermore AODVv2 is creating new
> messages each hop. That needs AODVv2 specific handling.
>

Yeah, I think I need to rephrase my previous comment.
I think what AODVv2 really wants to do is to reduce the retransmission (or
regeneration) of RREQ messages -- that's OK, as long as it's clearly
specified.

I agree with Chris that considering AODVv2 is "regenerating" messages, some
special manipulation is required.

And on Charlie's comment:

 AODVv2 should just take care of establishing and maintaining routes.If the
> nodes in the network offer multicast suppression, AODVv2 can use it.

RREQ message dissemination is one of the most important steps for
establishing/maintaining routes. If AODVv2 recommends anything to improve
it, we would expect the specification to tell us how to do it, and how it
can interoperate with others who don't do that.

If there is a DNS server in the network, does this imply that AODVv2 has to
> mandate that it work properly?  Well if it doesn't, then maybe DNS won't
> work and then applications can't resolve names, and can't ask AODV to
> establish routes for the IP addresses, etc.

Well, at least, for the moment, AODVV2 doesn't rely on DNS.
If you say, all right, we can put a hostname as RREQ originator
identification instead of IP address, I'm sure that people will ask you if
DNS is mandatory, what to do if DNS fails, and how to interoperate with
those routers only understand IP :)

best

Jiazi

> If the nodes in the network don't work properly (say, regarding multicast
> suppression, or some other protocol) their improper operation can affect
> the network.
>
> to mandate that it work properly?  Well if it doesn't, then maybe DNS won't
> work and then applications can't resolve names, and can't ask AODV to
> establish routes for the IP addresses, etc.
>
> I'd like to write up an integrated version of AODVv2 with some variety of
> multicast suppression algorithm that seems to cooperate conveniently, but
> that's an optimization.  I don't know whether or not it would use NDHP, but
> it might steal some packet formats.
>
> Regards,
> Charlie P.
>
>
>
>
> Especially, the algorithms used in RFC6621 require bi-directional check of
> neighbors, and 2-hop neighborhood discovery. I don't know how it's handled
> in AODVv2.
>

---

From: Victoria Mercieca <[email-masked]>
Date: Fri, 4 Mar 2016 09:11:57 +0000

Hi Chris,

I think Charlie's statement "If the nodes in the network offer multicast
suppression, AODVv2 can use it" might have caused more confusion. AODVv2
would not expect some other mechanism to handle multicast
suppression/forwarding of AODVv2 messages. AODVv2 messages inside RFC5444
packets, would not be considered for forwarding by this mechanism. We know
this.

AODVv2 would like to know if multicast suppression was being done in the
network, and in particular, if the router on which AODVv2 was running was
elected to forward multicast traffic. The idea is, that if AODVv2 could get
that knowledge, it could similarly decide whether to regenerate AODVv2
messages. It would not expect or desire any existing forwarding mechanism
to get involved with packets containing AODVv2 messages. All the handling
of AODVv2 messages is done by AODVv2.

The rest of the discussion seems to point at mandating more detail on how
multicast suppression would need to be configured across the network,
before AODVv2 could trust that, if it mimicked the relay set in the way it
decided to regenerate messages, route discovery would still succeed.

Kind regards,
Victoria.