Sent from my iPhone
On Mar 2, 2016, at 7:07 PM, Charlie Perkins
<charles.perkins@xxxxxxxxxxxxx<mailto:charles.perkins@xxxxxxxxxxxxx>> wrote:
Hello Stan,
Let me know which way you want to go and I'll write up the specification. If
it's an Interface ID, then the RREQ would need to be multicast N times where N
is the number of interfaces that share the same IP address.
I'm not sure - I'm looking for consensus. Maybe we should take this to the
Manet list? Either way, we need a sense of urgency - time isn't on our side.
Follow-up below:
On 3/2/2016 2:50 PM, Stan Ratliff wrote:
Do big iron routers with such IP address allocations have uni-directional links?
No, I know of any big iron routers with uni-directional links - I think
(emphasize think) that this is primarily a characteristic of RF links.
Strictly speaking, not really. Remember half-duplex? Yes it has to do with
interference, but that's usually true for RF as well.
I'm on the iPhone, so I'll try to be brief. But unidirectional isn't equal to
half-dux. Both partners can send on half-dux, just not at the same time...
So yes, there are ways to fix it:
1. disallow same IP address on multiple interfaces.
2. Somehow (and I'm not sure how, that's the devil in the details) disallow
uni-directional links.
If we're using *only* IP addresses to detect unidirectional links, and multiple
interfaces share an IP address, I think it's not feasible.
3. Spec out one of the algorithmic solutions you note above - but I'm skeptical
about a router "picking" one of its interfaces for RREQ, as these interfaces
could be connected to different 1-hop partners.
Yes, indeed. Then RREQ_Gen would presumably go round-robin through its
interfaces.
I'm unsure. Help us out, gang!
Regards,
Stan
Regards,
Charlie P.
In order to keep the heat on, we need to come to consensus, and pick something,
and get it knocked out. Henning's email has a valid use case for multiple
interfaces with the same IP address, so I'd like to at least favor my options 2
and 3 above (that's an opinon)... ;-)
Regards,
Stan
Finally, I am O.K. with simply disallowing the node to use the same IP address
for multiple interfaces. It's not like we're running out of IPv6 addresses any
time soon.
Regards,
Charlie P.
On 3/2/2016 12:38 PM, Ratliff, Stanley wrote:
Charlie,
If the answer is “it actually already works, because <blah>” (in this case,
because of the single sequence number), then great! That’s the answer.
Take a look at Justin’s email on uni-directional links, though – looks to me
like he has a failing case, since traffic received on interface #1 would
*always* need to be sent on interface #2. I didn’t think AODVv2 does that.
Regards,
Stan
From:
aodvv2-discuss-bounce@xxxxxxxxxxxxx<mailto:aodvv2-discuss-bounce@xxxxxxxxxxxxx>
[mailto:aodvv2-discuss-bounce@xxxxxxxxxxxxx] On Behalf Of Charlie Perkins
Sent: Wednesday, March 02, 2016 3:36 PM
To: aodvv2-discuss@xxxxxxxxxxxxx<mailto:aodvv2-discuss@xxxxxxxxxxxxx>
Subject: [aodvv2-discuss] Fwd: Re: [manet] AODVv2 reivew
Hello folks,
Before I wade into unfriendly waters, can someone tell me why AODVv2 does not
already support the same IP address on multiple interfaces? We already went
over this more than once, and keeping a single sequence number for all IP
addresses on the same device just works!
Right now I can't think of any problem with this, but if any of you remember
please tell me.
Regards,
Charlie P.
-------- Forwarded Message --------
Subject:
Re: [manet] AODVv2 reivew
Date:
Wed, 2 Mar 2016 14:27:10 -0500
From:
Justin Dean <mailto:bebemaster@xxxxxxxxx>
<bebemaster@xxxxxxxxx><mailto:bebemaster@xxxxxxxxx>
To:
Stan Ratliff <mailto:ratliffstan@xxxxxxxxx>
<ratliffstan@xxxxxxxxx><mailto:ratliffstan@xxxxxxxxx>
CC:
Dearlove, Christopher (UK) <mailto:chris.dearlove@xxxxxxxxxxxxxx>
<mailto:chris.dearlove@xxxxxxxxxxxxxx>
<chris.dearlove@xxxxxxxxxxxxxx><mailto:chris.dearlove@xxxxxxxxxxxxxx>,
Christopher Dearlove <mailto:chris@xxxxxxxxxxxxxxxxxxxxx>
<chris@xxxxxxxxxxxxxxxxxxxxx><mailto:chris@xxxxxxxxxxxxxxxxxxxxx>,
manet@xxxxxxxx<mailto:manet@xxxxxxxx> <mailto:manet@xxxxxxxx>
<manet@xxxxxxxx><mailto:manet@xxxxxxxx>
To me this isn't a big deal (unless it isn't fixed). Two ways to fix it.Â
Disallow different interfaces to have the same address. Two mandate any
interfaces with the same IP address MUST be bridged into a single logical
interface (i.e. both interfaces send and receive the same traffic). Either
way fixes the issue.
Justin
On Wed, Mar 2, 2016 at 2:22 PM, Stan Ratliff
<<mailto:ratliffstan@xxxxxxxxx>ratliffstan@xxxxxxxxx<mailto:ratliffstan@xxxxxxxxx>>
wrote:
On Wed, Mar 2, 2016 at 2:03 PM, Thomas Heide Clausen
<<mailto:ietf@xxxxxxxxxxxxxxxxx>ietf@xxxxxxxxxxxxxxxxx<mailto:ietf@xxxxxxxxxxxxxxxxx>>
wrote:
A question and a comment:
1) I thought this was about AODVv2, not DLEP, so I fail to seeÂ
   why it is relevant to bring DLEP into this discussion?
I was asked, implicitly, why *I* was pushing (since I was repeatedly named) for
a set of requirements *then*, and not so *now* - specifically, support of ip
unnumbered on interfaces. It's relevant to explain that it was based on
companion technology - technology that I no longer require. I would think that
was self-evident. Apparently not.Â
Â
2) I think that the argument bring made here is the logical fallacy called
     "moving the goal posts".Â
You are correct in that there is a logical fallacy in play here. Yours. All
I've said is (and I quote): "I don’t have any great issues with disallowing
it." That's an *opinion*, not an *edict*; nor does it connote moving of goal
posts, or any other associated hardware. At least I believe that, according to
IETF rules, I still get to express opinions, as a WG participant... or did some
RFC slip past that I'm not aware of?Â
Stan
Â
 Â
There are use cases for "same IP address on multiple interfaces" and I believe
they should be supported (as Chris wrote that we did for OLSRv2 "to the maximum
extend possible"), also by this protocol.
Thomas
On 02 Mar 2016, at 17:02, Ratliff, Stanley
<<mailto:sratliff@xxxxxxxxxxx>sratliff@xxxxxxxxxxx<mailto:sratliff@xxxxxxxxxxx>>
wrote:
Chris,
Â
I’m digging deep into the memory banks here… ;-) But from what I remember,
there were discussions at my old employer about the possibilities of
implementing & running OLSRv2 in the router. Our implementations at the time
were based on RFC5578 – a collection of PPPoE links, running over an RF net.
For that, “ip unnumbered†would have been a requirement. Since DLEP is
*not* PPPoE based, it pretty much mitigates the requirement.
Â
Regards,
Stan
Â
Â
From: Christopher Dearlove
[<mailto:chris@xxxxxxxxxxxxxxxxxxxxx>mailto:chris@xxxxxxxxxxxxxxxxxxxxx]
Sent: Wednesday, March 02, 2016 10:55 AM
To: Ratliff, Stanley
<<mailto:sratliff@xxxxxxxxxxx>sratliff@xxxxxxxxxxx<mailto:sratliff@xxxxxxxxxxx>>
Cc: Dearlove, Christopher (UK)
<<mailto:chris.dearlove@xxxxxxxxxxxxxx>chris.dearlove@xxxxxxxxxxxxxx<mailto:chris.dearlove@xxxxxxxxxxxxxx>>;
Justin Dean
<<mailto:bebemaster@xxxxxxxxx>bebemaster@xxxxxxxxx<mailto:bebemaster@xxxxxxxxx>>;
<mailto:manet@xxxxxxxx> manet@xxxxxxxx<mailto:manet@xxxxxxxx>
Subject: Re: [manet] AODVv2 reivew
Â
I'm not sure why the case was insisted on for OLSRv2 (though we were happy to
oblige to the maximum extent possible) and isn't required for AODVv2, but it
wasn't my requirement.
Â
As for the different addresses on different platforms, I think we are agreed,
it was the point I made. (Gateways may be a related but different issue.)
--Â
Christopher Dearlove
<mailto:christopher.dearlove@xxxxxxxxx>christopher.dearlove@xxxxxxxxx<mailto:christopher.dearlove@xxxxxxxxx>
On 2 Mar 2016, at 15:19, Ratliff, Stanley
<<mailto:sratliff@xxxxxxxxxxx>sratliff@xxxxxxxxxxx<mailto:sratliff@xxxxxxxxxxx>>
wrote:
Chris,
Â
To answer a question with a question – Will anyone want to run AODVv2 over a
collection of PPPoE links? I doubt it. I don’t have any great issues with
disallowing it. That would also resolve Justin’s uni-directional failure
case, since the common addresses wouldn’t be assigned to multiple interfaces
in the first place.
Â
Other thoughts?
Â
Regards,
Stan
Â
Â
From: Christopher Dearlove
[<mailto:chris@xxxxxxxxxxxxxxxxxxxxx>mailto:chris@xxxxxxxxxxxxxxxxxxxxx]
Sent: Wednesday, March 02, 2016 9:52 AM
To: Ratliff, Stanley
<<mailto:sratliff@xxxxxxxxxxx>sratliff@xxxxxxxxxxx<mailto:sratliff@xxxxxxxxxxx>>
Cc: Dearlove, Christopher (UK)
<<mailto:chris.dearlove@xxxxxxxxxxxxxx>chris.dearlove@xxxxxxxxxxxxxx<mailto:chris.dearlove@xxxxxxxxxxxxxx>>;
Justin Dean
<<mailto:bebemaster@xxxxxxxxx>bebemaster@xxxxxxxxx<mailto:bebemaster@xxxxxxxxx>>;
<mailto:manet@xxxxxxxx> manet@xxxxxxxx<mailto:manet@xxxxxxxx>
Subject: Re: [manet] AODVv2 reivew
Â
The question is, is that important for AODVv2? Should it allow it? Are there
any problems?
Â
As I've just said in another post, the step beyond that of routers sharing an
address is a problem, but I don't expect it to be relevant as people shouldn't
do it (it could be explicitly said). Though what I didn't address there is the
impact on gateways. We resolved that in OLSRv2 with two different kinds of
advertised address, one shareable among routers, not tied to an interface, one
shareable among interfaces but only on the same router and only if not commonly
hearable.
-- Â
Christopher Dearlove
<mailto:christopher.dearlove@xxxxxxxxx>christopher.dearlove@xxxxxxxxx<mailto:christopher.dearlove@xxxxxxxxx>
(iPhone)
<mailto:chris@xxxxxxxxxxxxxxxxxxxxx>chris@xxxxxxxxxxxxxxxxxxxxx<mailto:chris@xxxxxxxxxxxxxxxxxxxxx>
(home)
On 2 Mar 2016, at 14:17, Ratliff, Stanley
<<mailto:sratliff@xxxxxxxxxxx>sratliff@xxxxxxxxxxx<mailto:sratliff@xxxxxxxxxxx>>
wrote:
Chris,
Â
The use case comes from routers implementing ip unnumbered. It can cause the
same address to be placed on multiple interfaces. From what I recall, its
especially prevalent with PPPoE interfaces, as they are virtual; cloned from a
common template.
Â
Regards,
Stan
Â
Â
Â
In NHDP, we added (following requests from the WG, Stan in particular IIRC) the
more tricky case of the same address used on different interfaces. We had to
limit that, so any receiving interface would only ever receive one or the other
(which otherwise is not a requirement in NHDP) - which might in a real case be
e.g. different frequencies (timeslots, codes, etc.) I have no idea whether this
is easy or hard in AODVv2 (the devil is in the details). I don’t know if Stan
(for example) still has this requirement.
Â
--
************************
_____________________________________________________
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.
_____________________________________________________
_______________________________________________
manet mailing list
<mailto:manet@xxxxxxxx>manet@xxxxxxxx<mailto:manet@xxxxxxxx>
<https://www.ietf.org/mailman/listinfo/manet>https://www.ietf.org/mailman/listinfo/manet
_____________________________________________________
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.
_____________________________________________________
_____________________________________________________
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.
_____________________________________________________
_______________________________________________
manet mailing list
<mailto:manet@xxxxxxxx>manet@xxxxxxxx<mailto:manet@xxxxxxxx>
<https://www.ietf.org/mailman/listinfo/manet>https://www.ietf.org/mailman/listinfo/manet
_______________________________________________
manet mailing list
manet@xxxxxxxx<mailto:manet@xxxxxxxx>
https://www.ietf.org/mailman/listinfo/manet
_______________________________________________
manet mailing list
manet@xxxxxxxx<mailto:manet@xxxxxxxx>
https://www.ietf.org/mailman/listinfo/manet
_____________________________________________________
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.
_____________________________________________________
_____________________________________________________
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.
_____________________________________________________
