Subject: Re: [manet] draft-ietf-manet-nhdp-10.txt - WGLC - Oct 5th 2009

From: Henning Rogge <[email-masked]>
Date: Tue, 1 Sep 2009 11:27:18 +0200

Am Tue September 1 2009 08:15:42 schrieb Teco Boot:
> I think we should support multiple interfaces with same addresses.
> P2P links in general use such, PPPoE is not the exception.
> And there is the link-local addresses with VLANs scenario.
I can see the usage of "same IPs" for point2point links. It should be not 
difficult to support this with NHDP/OLSRv2 without changing the message-
structure/TLVs. As long as there are different "regions" of traffic which 
cannot see each other, they could use the same IPs and the client can use the 
"incoming interface" as an information to differentiate them.

> I think introducing a Router-ID in NHDP highly reduces complexity.
> Then, it is no longer needed to advertize __all addresses__ so
> overhead may be reduced.
Yes, an unique identifier would be helpful for efficient implementations too.

> Also, management is simplified. There is already the NeighborNodeId
> in draft manet-nhdp-mib. And interfaces are identified with nhdpIfIndex
> (which is ifIndex).
>
> The IP header source address would be used as Router-ID if msg-orig-addr
> is missing. In case another Router-ID is to be used, msg-orig-addr is
> added. This would be in line with OLSRv2.
Even if we don't add this as mandatory to NHDP, this would be a good thing to 
add to OLSRv2.

> On Henning his 4b (same address on different routers):
> OSPF has no problem with this.
I have looked into the OSPF RFCs and see nothing which solves the problem.

Maybe I'm missing a certain fact and you can help... let's assume a szenario 
with a chain of three nodes A-B-C, where A and C cannot see each other.

If A and C choose the same IP for their interface, how should B forward 
traffic from A to C (or the other way) ?

> Many admins that configured anycast want to stay alive.
> I am one of them!
I'm not sure how anycast helps with addressing the next hop for a packet.

> My major concern is ever changing addresses. Identifiers would be
> stable (or MUST be, as specified in the MIB drafts).
Yes.

> Teco.

*************************************************
Diplom-Informatiker Henning Rogge
Forschungsgesellschaft für
Angewandte Naturwissenschaften e. V. (FGAN) 
Neuenahrer Str. 20, 53343 Wachtberg, Germany
Tel.: 0049 (0)228 9435-961
Fax: 0049 (0)228 9435-685
E-Mail: [email-masked]
Web: www.fgan.de
************************************************
Sitz der Gesellschaft: Bonn
Registergericht: Amtsgericht Bonn VR 2530
Vorstand: Dr. rer. nat. Ralf Dornhaus (Vors.), Prof. Dr. Joachim Ender 
(Stellv.)

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 1 Sep 2009 10:34:11 +0100

Adding that you need an originator address in OLSRv2 is
already in the next OLSRv2 draft that the authors are
trying to get finished.

-- 
Christopher Dearlove
Technology Leader, Communications Group
Networks, Security and Information Systems Department
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194  Fax: +44 1245 242124

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87,
Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

-----Original Message-----
From: Henning Rogge [mailto:[email-masked]] 
Sent: 01 September 2009 10:27
To: [email-masked]
Cc: Teco Boot; 'Stan Ratliff'; 'Thomas Heide Clausen'; Dearlove, Christopher (UK)
Subject: Re: [manet] draft-ietf-manet-nhdp-10.txt - WGLC - Oct 5th 2009

Yes.

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

---

From: "Teco Boot" <[email-masked]>
Date: Tue, 1 Sep 2009 11:48:30 +0200

Hi Henning,

|> On Henning his 4b (same address on different routers):
|> OSPF has no problem with this.
|I have looked into the OSPF RFCs and see nothing which solves the
|problem.

In OSPF, we have RouterID and InterfaceID. Both are NOT addresses. 
InterfaceID is unique with scope of a router, not for the routing domain.
RouterID must be unique within the routing domain.

|Maybe I'm missing a certain fact and you can help... let's assume a
|szenario
|with a chain of three nodes A-B-C, where A and C cannot see each other.
|
|If A and C choose the same IP for their interface, how should B forward
|traffic from A to C (or the other way) ?

If there are two links, A-B and B-C, and router A has address X on A-B,
so has C on B-C, the next-hop for a packet to A is "interface to A-B,
address X". The next-hop for a packet to C is "interface to B-C, address X".

No two addresses may occur on the same link. This is not the case in this 
scenario.

Teco.

---

From: Henning Rogge <[email-masked]>
Date: Tue, 1 Sep 2009 12:32:05 +0200

> No two addresses may occur on the same link. This is not the case in this

That does not really answer my question. I understand how OSPF decides where 
to forward to packet, but how does it work on the kernel routing layer ?

If you have two neighbors you reach through the same link with the same IP, 
you cannot address them with an IP packet. Does OSPF some kind of crosslayer 
aproach and use direct layer-2 addressing to forward packages ?

Henning Rogge

---

From: "Teco Boot" <[email-masked]>
Date: Tue, 1 Sep 2009 15:50:07 +0200

Hi Henning,

No one said it is permitted to use the same address on multiple 
nodes on the same link.
The issue is the same IP can be used on multiple routers, on 
different segments.

Teco.

|-----Oorspronkelijk bericht-----
|Van: Henning Rogge [mailto:[email-masked]]
|Verzonden: dinsdag 1 september 2009 12:32
|Aan: Teco Boot
|CC: [email-masked]; 'Stan Ratliff'; 'Thomas Heide Clausen'; 'Christopher
|Dearlove'
|Onderwerp: Re: [manet] draft-ietf-manet-nhdp-10.txt - WGLC - Oct 5th
|2009
|
|Am Tue September 1 2009 11:48:30 schrieb Teco Boot:
|> Hi Henning,
|>
|> |> On Henning his 4b (same address on different routers):
|> |> OSPF has no problem with this.
|> |
|> |I have looked into the OSPF RFCs and see nothing which solves the
|> |problem.
|>
|> In OSPF, we have RouterID and InterfaceID. Both are NOT addresses.
|> InterfaceID is unique with scope of a router, not for the routing
|domain.
|> RouterID must be unique within the routing domain.
|>
|> |Maybe I'm missing a certain fact and you can help... let's assume a
|> |szenario
|> |with a chain of three nodes A-B-C, where A and C cannot see each
|other.
|> |
|> |If A and C choose the same IP for their interface, how should B
|forward
|> |traffic from A to C (or the other way) ?
|>
|> If there are two links, A-B and B-C, and router A has address X on A-
|B,
|> so has C on B-C, the next-hop for a packet to A is "interface to A-B,
|> address X". The next-hop for a packet to C is "interface to B-C,
|address
|> X".
|>
|> No two addresses may occur on the same link. This is not the case in
|this
|> scenario.
|
|That does not really answer my question. I understand how OSPF decides
|where
|to forward to packet, but how does it work on the kernel routing layer ?
|
|If you have two neighbors you reach through the same link with the same
|IP,
|you cannot address them with an IP packet. Does OSPF some kind of
|crosslayer
|aproach and use direct layer-2 addressing to forward packages ?
|
|Henning Rogge
|
|*************************************************
|Diplom-Informatiker Henning Rogge
|Forschungsgesellschaft für
|Angewandte Naturwissenschaften e. V. (FGAN)
|Neuenahrer Str. 20, 53343 Wachtberg, Germany
|Tel.: 0049 (0)228 9435-961
|Fax: 0049 (0)228 9435-685
|E-Mail: [email-masked]
|Web: www.fgan.de
|************************************************
|Sitz der Gesellschaft: Bonn
|Registergericht: Amtsgericht Bonn VR 2530
|Vorstand: Dr. rer. nat. Ralf Dornhaus (Vors.), Prof. Dr. Joachim Ender
|(Stellv.)

---

From: Henning Rogge <[email-masked]>
Date: Tue, 1 Sep 2009 16:14:49 +0200

> The issue is the same IP can be used on multiple routers, on
So we cannot just use link-local IPs with DAD because DAD cannot guarantee 
unique IPs on the same link.

Most likely OSPF cannot deal with this can too. If two nodes two hops away 
from each other configuring the same LL address I see no way to address them 
on IP layer for a node between this two.

Henning Rogge

---

From: Henning Rogge <[email-masked]>
Date: Tue, 1 Sep 2009 17:56:26 +0200

Am Dienstag 01 September 2009 08:15:42 schrieb Teco Boot:
> I agree with Ian and Stan on topics #3 and #4 (identifying routers,
> interfaces).
You suggest that the interface index is put into the "interface identity" NHDP 
uses, right ?

I played with this idea a little bit and maybe identified a problem...
If we use the ifindex to identifiy a link, we have to put it into the link-
neighbors in the HELLO message too, because we have to identify the 2-hop 
links.

But even if we put it there, we might be unable to detect link to our own 
node, because they might have the same IP (which does not matter on the P2P 
link, but maybe for VLAN ?) and an ifindex, which is not unique for all nodes.

So we might have a link-neighbor entry in the HELLO we are unable to decide if 
it's our own or not... Unless the IPs are "unique".

So even if we insert the ifindex into the HELLO, the interface IP of the link 
must be unique for the node.

And we might be forced to put ifindex values into the TCs too, unless we run 
OLSR in "don't publish non-routable IPs in TCs" mode.

What do you think ?

Henning Rogge

---

From: "Teco Boot" <[email-masked]>
Date: Tue, 1 Sep 2009 21:48:18 +0200

|> No one said it is permitted to use the same address on multiple
|> nodes on the same link.
|> The issue is the same IP can be used on multiple routers, on
|> different segments.
|So we cannot just use link-local IPs with DAD because DAD cannot
|guarantee
|unique IPs on the same link.

Not true. DAD applies to any address. So we cannot use any address
because DAD cannot guarantee unique IPs on the same link.
Or use another method for uniqueness.

Teco.

---

From: "Teco Boot" <[email-masked]>
Date: Wed, 2 Sep 2009 07:59:42 +0200

Hi Henning,

|> |> No one said it is permitted to use the same address on multiple
|> |> nodes on the same link.
|> |> The issue is the same IP can be used on multiple routers, on
|> |> different segments.
|> |
|> |So we cannot just use link-local IPs with DAD because DAD cannot
|> |guarantee
|> |unique IPs on the same link.
|>
|> Not true. DAD applies to any address. So we cannot use any address
|> because DAD cannot guarantee unique IPs on the same link.
|> Or use another method for uniqueness.
|Hmm... so we could use link-local IP, but we need to find a better way
|to
|guarantee that they are two-hop unique on the same link (frequency for
|example). In addition to this the link-local addresses must change if to
|stations get in range which have choosen the same link-local IP some
|time ago.
|
|But maybe we should concentrate how we could solve the "same IP" problem
|on
|different links as VLANs or PPPoE-tunnels.

Correct.
Let Autoconf find out the addressing.
And we should support same address on different interfaces.

Teco.

---

From: Henning Rogge <[email-masked]>
Date: Wed, 2 Sep 2009 09:12:51 +0200

> Let Autoconf find out the addressing.
So maybe someone could write a "lightweight link-local Ip generation in 
MANETs" draft for the autoconf-wg. Not all autoconf sollutions will support 
this, but it might become a feature. But that's a discussion for the autoconf 
WG.

> And we should support same address on different interfaces.
Let's see if we can specify a "problem scenario":

We have two nodes A and B connected by two VLAN 1 and 2, using the same IPs. 
In addition to this B is connected to a node C (on a third interface) which is 
using one of the IPs used by A. All nodes use linkquality extensions.
The numbers in brackets behind the IPs are the interface indices.

----------*              *-------------------*              *-----------
   IP 1(1)+--- VLAN 1 ---+IP 2(2)     IP 2(3)+--- VLAN 3 ---+IP 1(1)
A         |              |         B         |              |       C
   IP 1(2)+--- VLAN 2 ---+IP 2(1)            |              |
----------*              *-------------------*              *-----------

This configuration does not contradict the "no conflicting IPs on the same 
link".

The Hello-message of B received by A through VLAN 1 looks something like this:

HELLO (originator B):
  IP 2: this_if
  IP 2: other_if
  IP 2: other_if

  IP 1: LINK_STATUS  = SYMMETRIC, LINK_COST=<cost A-B on VLAN 1>
  IP 1: OTHER_NEIGHB = SYMMETRIC, LINK_COST=<cost A-B on VLAN 2>
  IP 1: OTHER_NEIGHB = SYMMETRIC, LINK_COST=<cost B-C on VLAN 3>

In this case A cannot know which of the two "OTHER_NEIGHB" entries is his link 
to B (if any) and which is a real 2-hop neighbor.

If we include the local interface index into the hello we get:

HELLO (originator B):
  IP 2(2): this_if
  IP 2(1): other_if
  IP 2(3): other_if

  IP 1(2): LINK_STATUS  = SYMMETRIC, LINK_COST=<cost A-B on VLAN 1>
  IP 1(1): OTHER_NEIGHB = SYMMETRIC, LINK_COST=<cost A-B on VLAN 2>
  IP 1(3): OTHER_NEIGHB = SYMMETRIC, LINK_COST=<cost B-C on VLAN 3>

If A has recorded that the link A-B through VLAN 2 has the interface index 1 
at B, this should be enough to keep the links of B appart.

If "duplicate IP usage" is only allowed for non-routable IPs we might even 
don't need to put the interface index into the TCs of OLSRv2.

Comments ?

Henning Rogge

Diplom Informatiker Henning Rogge

---

From: Henning Rogge <[email-masked]>
Date: Wed, 2 Sep 2009 07:49:22 +0200

> Or use another method for uniqueness.
Hmm... so we could use link-local IP, but we need to find a better way to 
guarantee that they are two-hop unique on the same link (frequency for 
example). In addition to this the link-local addresses must change if to 
stations get in range which have choosen the same link-local IP some time ago.

But maybe we should concentrate how we could solve the "same IP" problem on 
different links as VLANs or PPPoE-tunnels.

Henning Rogge

---

From: "Teco Boot" <[email-masked]>
Date: Wed, 2 Sep 2009 10:25:02 +0200

Hi Henning,

|> And we should support same address on different interfaces.
|Let's see if we can specify a "problem scenario":
|
|We have two nodes A and B connected by two VLAN 1 and 2, using the same
|IPs.
|In addition to this B is connected to a node C (on a third interface)
|which is
|using one of the IPs used by A. All nodes use linkquality extensions.
|The numbers in brackets behind the IPs are the interface indices.
|
|----------*              *-------------------*              *-----------
|   IP 1(1)+--- VLAN 1 ---+IP 2(2)     IP 2(3)+--- VLAN 3 ---+IP 1(1)
|A         |              |         B         |              |       C
|   IP 1(2)+--- VLAN 2 ---+IP 2(1)            |              |
|----------*              *-------------------*              *-----------
|
|This configuration does not contradict the "no conflicting IPs on the
|same
|link".

Yes, but there must be unique RouterIDs. This could be addresses (not
Prefixes, in NHDP this is mixed up).

|The Hello-message of B received by A through VLAN 1 looks something like
|this:
|
|HELLO (originator B):
|  IP 2: this_if
|  IP 2: other_if
|  IP 2: other_if

Here, the "not routing domain wide addresses" are used as router 
identifiers. This introduces problems. My suggestion would be:

Hello rcvd on A, from B:
  Originator: B
    Neighbor list:
      A: this_if
      A: other_if
      C: other_if

|  IP 1: LINK_STATUS  = SYMMETRIC, LINK_COST=<cost A-B on VLAN 1>
|  IP 1: OTHER_NEIGHB = SYMMETRIC, LINK_COST=<cost A-B on VLAN 2>
|  IP 1: OTHER_NEIGHB = SYMMETRIC, LINK_COST=<cost B-C on VLAN 3>
|
|In this case A cannot know which of the two "OTHER_NEIGHB" entries is
|his link
|to B (if any) and which is a real 2-hop neighbor.
|
|If we include the local interface index into the hello we get:
|
|HELLO (originator B):
|  IP 2(2): this_if
|  IP 2(1): other_if
|  IP 2(3): other_if
|
|  IP 1(2): LINK_STATUS  = SYMMETRIC, LINK_COST=<cost A-B on VLAN 1>
|  IP 1(1): OTHER_NEIGHB = SYMMETRIC, LINK_COST=<cost A-B on VLAN 2>
|  IP 1(3): OTHER_NEIGHB = SYMMETRIC, LINK_COST=<cost B-C on VLAN 3>
|
|If A has recorded that the link A-B through VLAN 2 has the interface
|index 1
|at B, this should be enough to keep the links of B appart.
|
|If "duplicate IP usage" is only allowed for non-routable IPs we might
|even
|don't need to put the interface index into the TCs of OLSRv2.

Using my suggestion for the hello message, the full state for A, B 
and C would be:

A:
==
ifIndex 1:
  Neighbor B; SYMMETRIC, LINK_COST=cost A-B for this link
    This_if 2hop neighbor A, SYMMETRIC
    Other_if 2hop neighbor A, SYMMETRIC
    Other_if 2hop neighbor C, SYMMETRIC
ifIndex 2:
  Neighbor B; SYMMETRIC, LINK_COST=cost A-B for this link
    This_if 2hop neighbor A, SYMMETRIC
    Other_if 2hop neighbor A, SYMMETRIC
    Other_if 2hop neighbor C, SYMMETRIC
B:
==
ifIndex 1:
  Neighbor A; SYMMETRIC, LINK_COST=cost B-A for this link
    This_if 2hop neighbor B, SYMMETRIC
    Other_if 2hop neighbor B, SYMMETRIC
ifIndex 2:
  Neighbor A; SYMMETRIC, LINK_COST=cost B-A for this link
    This_if 2hop neighbor B, SYMMETRIC
    Other_if 2hop neighbor B, SYMMETRIC
ifIndex 3:
  Neighbor C; SYMMETRIC, LINK_COST=cost B-C for this link
    This_if 2hop neighbor B, SYMMETRIC
C:
==
ifIndex 1:
  Neighbor B; SYMMETRIC, LINK_COST=cost C-B for this link
    This_if 2hop neighbor C, SYMMETRIC
    Other_if 2hop neighbor A, SYMMETRIC

Now, we need only one identifier, instead of "all addresses". Also,
the received information is maintained "per interface". This is exactly 
what is needed.
It requires minor or no changes in NHDP and OLSRv2 in messages and
information bases. Important: OLSR N_willingness, N_mpr and N_mpr_selector
need transfer from Neighbor_set to Link_Set. 
Btw, I still do not feel comfortable with "per interface flooding",
I'll demonstrate failing MPR flooding one day with just some Ethernet
switches. I suggested some improvements for this, and I wait for a new
OLSR draft to see what is accepted and what is not.

Comments?

Teco.

---

From: "Teco Boot" <[email-masked]>
Date: Wed, 2 Sep 2009 14:12:23 +0200

Hi Henning,

|> |This configuration does not contradict the "no conflicting IPs on the
|> |same
|> |link".
|>
|> Yes, but there must be unique RouterIDs. This could be addresses (not
|> Prefixes, in NHDP this is mixed up).
|okay, let's try a new graphics.
|
|We have two nodes A and B connected by two VLAN 1 and 2, using the same
|IPs.
|In addition to this B is connected to a node C (on a third interface)
|which is
|using one of the IPs used by A. All nodes use linkquality extensions.
|
|IP 1,2,3 are linklocal addresses, IP A,B,C are global unique IPs or
|router-
|IDs. The numbers in brackets behind the IPs are the interface indices.
|
|----------*              *-------------------*              *-----------
|   IP 1(1)+--- VLAN 1 ---+IP 2(2)     IP 2(3)+--- VLAN 3 ---+IP 1(1)
|          |              |                   |              |
|IP A      |              |       IP B        |              |       IP C
|          |              |                   |              |
|   IP 1(2)+--- VLAN 2 ---+IP 2(1)            |              |
|----------*              *-------------------*              *-----------
|
|> Hello rcvd on A, from B:
|>   Originator: B
|>     Neighbor list:
|>       A: this_if
|>       A: other_if
|>       C: other_if
|
|> Using my suggestion for the hello message, the full state for A, B
|> and C would be:
|
|> B:
|> ==
|> ifIndex 1:
|>   Neighbor A; SYMMETRIC, LINK_COST=cost B-A for this link
|>     This_if 2hop neighbor B, SYMMETRIC
|>     Other_if 2hop neighbor B, SYMMETRIC
|> ifIndex 2:
|>   Neighbor A; SYMMETRIC, LINK_COST=cost B-A for this link
|>     This_if 2hop neighbor B, SYMMETRIC
|>     Other_if 2hop neighbor B, SYMMETRIC
|> ifIndex 3:
|>   Neighbor C; SYMMETRIC, LINK_COST=cost B-C for this link
|>     This_if 2hop neighbor B, SYMMETRIC
|
|I don't think I understand what you mean with this. This data structure
|seems
|to contain redundant information. Is this the Hello from B ? If yes,
|which one
|(Hellos are different on each interface in NHDP) ?

It is a representation of the information base for B.
There is not much redundancy. The node itself is listed as 2hop neighbor,
this is found in Link_Set and 2-Hop_Set. If you prefer another data
structure,
that is OK for me. I did not intent to fully work out or specify these 
data structures.
And of course there is the reflection of the redundant link.

Another idea: the RouterID's A, B and C could be used as source addresses.
One way of doing this is IP unnumbered, where for example the identifying 
address is configured on a management interface (e.g. "loopback interface",
see RFC5375) and the MANET interfaces "borrow" that address. This takes
away the need for adding msg-orig-addr in NHDP messages. But I think we 
better not mandate using IP unnumbered and allow the configuration above.
Another way is using a single globally unique link-local address on all 
interfaces, for example with interface-ID with u-bit set. Again, let's
not mandate such.

Teco.

---

From: Henning Rogge <[email-masked]>
Date: Wed, 2 Sep 2009 13:03:58 +0200

> Prefixes, in NHDP this is mixed up).
okay, let's try a new graphics.

IP 1,2,3 are linklocal addresses, IP A,B,C are global unique IPs or router-
IDs. The numbers in brackets behind the IPs are the interface indices.

          |              |                   |              |
IP A      |              |       IP B        |              |       IP C
          |              |                   |              |

>     This_if 2hop neighbor B, SYMMETRIC

I don't think I understand what you mean with this. This data structure seems 
to contain redundant information. Is this the Hello from B ? If yes, which one 
(Hellos are different on each interface in NHDP) ?

Henning Rogge

---

From: "Justin Dean" <[email-masked]>
Date: Tue, 1 Sep 2009 11:34:44 -0400

I think there is currently some confusion regarding how links are formed and
stored.  Hello message generation is done per interface and link information
(Link Set) is recorded per interface.  Here is what a hello message exchange
might look like starting with A(1), B(1), C(1), B(2), A(2), B(3), C(1)

A(1) Hello message 
LOCAL_IF:THIS_IF ONE,A
LOCAL_IF:OTHER_IF (could include ONE and A but its redundant and not
important for this example)
(B(1) receives this and adds (ONE,A) to its Link Set with HEARD)

B(1) Hello message
LOCAL_IF:THIS_IF TWO,B
LOCAL_IF:OTHER 
LINK_STATUS:HEARD ONE,A
(A(1) receives this and adds (TWO,B) as a neighbor in the Neighbor Set and
as SYMMETRIC in the Link Set of interface 1)

C(1) Hello message
LOCAL_IF:THIS_IF ONE,C
(B(3) receives this and adds (ONE,C) to its Link Set with HEARD)

B(2) Hello message
LOCAL_IF:THIS_IF TWO,B
LOCAL_IF:OTHER_IF
(Note that B(2) Hello message does not include information yet about the
HEARD A, ONE (from interface B(1)) because it has its own Link Set which is
empty)
(A(2) receives this and adds (TWO,B) to its Link Set with HEARD)

A(2) Hello message
LOCAL_IF:THIS_IF ONE,A
LOCAL_IF:OTHER_IF 
LINK_STATUS:HEARD TWO,B  (from the B(2) hello message (Link Set))
OTHER_NEIGHB_SYMMETRIC TWO,B (from the Neighbor Set populated by interface 1
because of hello message from B(1))
(B(2) receives this and adds (ONE,A) as a neighbor in the Neighbor Set and
as SYMMETRIC in the Link Set of interface 2)

B(3) Hello message
LOCAL_IF:THIS_IF TWO,B
LOCAL_IF:OTHER_IF 
LINK_STATUS:HEARD ONE,C (from the C(1) hello message (Link Set))
OTHER_NEIGHB_SYMMETRIC ONE,A (from the Neighbor Set populated by interface 2
because of hello message from A(2))
(C(1) receives this and adds (TWO,B) as a neighbor in the Neighbor Set and
as SYMMETRIC in the Link Set of interface 1)

C(1) Hello message
LOCAL_IF:THIS_IF ONE,C
LOCAL_IF:OTHER_IF
LINK_STATUS:SYMMETRIC TWO,B
OTHER_NEIGHB_SYMMETRIC (addresses TWO and B are not included because they
are included in the LINK_STATUS:SYMMETRIC even though they are in the
Neighbor Set of router C)
(B(3) receives this and updates the (ONE,A) tuple in the Neighbor Set by
removing A and adding C.  It does this because it is assuming that a router
has dropped the A address and added the C address (the ONE gives a match))

>  IP ONE(1)+--- VLAN 1 ---+IP TWO(1) IP TWO(3)+--- VLAN 3 ---+IP ONE(1)
>           |              |                   |              |
> IP A      |              |       IP B        |              |       IP C
>           |              |                   |              |
>  IP ONE(2)+--- VLAN 2 ---+IP TWO(2)          |              |

At this point not all link sets have symmetric entries but hopefully this
helped illustrate how NHDP would handle this situation.  IMO only the last
step is "wrong" otherwise links are kept on a per interface basis even with
multiple interfaces using the same IP address.  The issue is with having two
different routers with the same address.  One solution would be to require
that only unique addresses are included in hello messages.  This would
remove the possibility of NHDP being used to advertize anycast addresses.
Another method would be to tag non-unique addresses (LOCAL_IF:NON-UNIQUE)
and store them apart from the other addresses in the neighbor tuple.

Justin

---

From: Henning Rogge <[email-masked]>
Date: Mon, 7 Sep 2009 20:56:50 +0200

Am Dienstag 01 September 2009 17:34:44 schrieb Justin Dean:
> multiple interfaces using the same IP address.  The issue is with having
>  two different routers with the same address.  One solution would be to
>  require that only unique addresses are included in hello messages.  This
>  would remove the possibility of NHDP being used to advertize anycast
>  addresses. Another method would be to tag non-unique addresses
>  (LOCAL_IF:NON-UNIQUE) and store them apart from the other addresses in the
>  neighbor tuple.
Maybe I have an suggestion how we can add the "same IP multiple times on 
different interfaces" without any overhead for normal operation in the 
messages.

new TLV (both message TLV and address block TLV):
IF_INDEX including a value of 1 bytes. The value must be 1 or higher.
(this supports up to 255 interfaces with the same IP, which should be more 
than enough)

---------

Every Node having the same IP multiple times add an IF_INDEX TLV as a message 
TLV to HELLOS with with the duplicate IPs as interface IP.

instead of working with "neighbor_interface_ip", NHDP will always use a pair 
of "neighbor_interface_ip" and "neighbor_interface_index". This will guarantee 
that the pair is unique. If no IF_INDEX is attached to an interface IP, it's 
considered 0.

All neighbor_interface IPs put into an HELLO will contain an IF_INDEX TLV, 
unless the stored index is 0.

---------

If we would run NHDP this way with no duplicate IPs, there will be no change 
in the message structure at all. All interfaces will add "0" as the default 
if_index to their identification pair, but this don't need to be transmitted 
to neighbors.

What do you think about it ?

Henning Rogge

---

From: Henning Rogge <[email-masked]>
Date: Wed, 16 Sep 2009 08:32:47 +0200

Am Mon September 7 2009 20:56:50 schrieb Henning Rogge:
> Every Node having the same IP multiple times add an IF_INDEX TLV as a
> message TLV to HELLOS with with the duplicate IPs as interface IP.
>
> instead of working with "neighbor_interface_ip", NHDP will always use a
> pair of "neighbor_interface_ip" and "neighbor_interface_index". This will
> guarantee that the pair is unique. If no IF_INDEX is attached to an
> interface IP, it's considered 0.
>
> If we would run NHDP this way with no duplicate IPs, there will be no
> change in the message structure at all. All interfaces will add "0" as the
> default if_index to their identification pair, but this don't need to be
> transmitted to neighbors.
Just another thought about this.

If we add an interface index to the IPs in the hellos, NHDP and the MPR 
algorithm of OLSRv2 will be able to see what group of interface IPs belong to 
the same physical interface, which might help to do a better MPR calculation.

Henning Rogge

-- 
Diplom-Informatiker Henning Rogge , Fraunhofer-Institut für
Kommunikation, Informationsverarbeitung und Ergonomie FKIE
Kommunikationssysteme (KOM)
Neuenahrer Straße 20, 53343 Wachtberg, Germany
Telefon +49 228 9435-263,   Fax +49 228 9435 685
mailto:[email-masked] http://www.fkie.fraunhofer.de
GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0

---

From: "Justin Dean" <[email-masked]>
Date: Thu, 17 Sep 2009 11:34:09 -0400

While the idea of having optional "index" (they would have to be static and unchanging even if other interfaces went up and down unlike normal system index's) values and TLVs would help differentiate physically different interfaces to other routers it really isn't necessary.  The example I gave illustrates how NHDP would work with unnumbered interfaces without any changes.  The one caveat is that NHDP as is works with unnumbered interfaces as long as those interfaces do not "interfere" with each other, having two interfaces (w/ same IP) on the same channel wouldn't allow other routers to distinguish from which interface the hello message was generated.  As long as this isn't the case nothing needs to be added.  The only deployment situation that I can think of that this might be the case is with directional antennas, but even this would work if the physical interfaces of the same medium/address were arrogated together into a virtual interface.  (virtualizing multiple different interfaces, running on different media, into one WILL BREAK NHDP).  

An alternate proposal:
NHDP interfaces of a router which running on the same medium must be uniquely addressed.  
NHDP interfaces of a router running on differing mediums may be addressed the same (their "identifying," THIS_IF, address sets MUST match completely.)
NHDP may be run on a virtual interface comprised of identically addressed interfaces which are all running over the same medium.
NHDP cannot be run on a virtual interface comprised of differently addressed interfaces.
NHDP cannot be run on a virtual interface comprised of identically addressed interfaces which are running on differing mediums.

This allows for most deployments which I can think of without adding overhead or protocol complexity.  And it only adds complexity to those who would want to run a non "standard" network deployment and helps them do it in a way which would not break NHDP.  If there are deployments which others know about in which this would not allow NHDP to work correctly please speak up.

As I mentioned in my previous email the issue I saw was not with multiple interfaces with the same address but with differing routers sharing the same "identifying" address in their interface address list.  A simple fix is to disallow non-network-wide-unique addresses to be listed with the THIS_IF TLV value in a hello message.

Justin

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Henning Rogge
> Sent: Wednesday, September 16, 2009 2:33 AM
> To: [email-masked]
> > Maybe I have an suggestion how we can add the "same IP multiple times
> > on different interfaces" without any overhead for normal operation in
> > the messages.
> >
> > (this supports up to 255 interfaces with the same IP, which should be
> > more than enough)
> >
> > ---------
> >
> > instead of working with "neighbor_interface_ip", NHDP will always use
> > a pair of "neighbor_interface_ip" and "neighbor_interface_index".
> This
> > will guarantee that the pair is unique. If no IF_INDEX is attached to
> > an interface IP, it's considered 0.
> >
> > All neighbor_interface IPs put into an HELLO will contain an IF_INDEX
> > TLV, unless the stored index is 0.
> >
> > ---------
> >
> > change in the message structure at all. All interfaces will add "0"
> as
> > the default if_index to their identification pair, but this don't
> need
> > to be transmitted to neighbors.
> algorithm of OLSRv2 will be able to see what group of interface IPs
> belong to the same physical interface, which might help to do a better
> MPR calculation.
> 
> Henning Rogge
> 
> --
> Kommunikationssysteme (KOM) Neuenahrer Straße 20, 53343 Wachtberg,
> Germany

---

From: Henning Rogge <[email-masked]>
Date: Thu, 17 Sep 2009 18:00:52 +0200

Am Donnerstag 17 September 2009 17:34:09 schrieb Justin Dean:
> NHDP interfaces of a router running on differing
> mediums may be addressed the same (their "identifying," THIS_IF, address
> sets MUST match completely.)

I'm not sure if this will be enough with link quality together (or other link 
specific information in the hellos).

Assume a chain of three nodes, A=B-C. There are two different sepparate 
channels between A and B, but only one between B and C (on a third channel).

If C receives a hello from B, it cannot tell the link metrics values of the 
two connections between A and B appart, they have the same IP. 

Maybe I am missing something here ?

Henning

---

From: "Teco Boot" <[email-masked]>
Date: Thu, 17 Sep 2009 20:04:51 +0200

Now metrics join the game. Currently not part of NHDP, while this
is strongly related to neighborhood. Metrics would be used not only
by OLSR (e.g. distance in DYMO).

Another thought: is it up to NHDP to keep track metrics for the link 
to the 2-hop neighbor? If not, I think there is no problem.

And a remark on the address uniqueness: is anycast permitted? And what 
if a lot of duplicates are in the network, all on different media?
I was present at an event with some ad hoc networking. I saw a lot of
192.168.0.0/24 networks. Luckily, nobody was shot.

Teco.

|-----Oorspronkelijk bericht-----
|Van: [email-masked] [mailto:[email-masked]] Namens
|Henning Rogge
|Verzonden: donderdag 17 september 2009 18:01
|Aan: [email-masked]
|Onderwerp: Re: [manet] draft-ietf-manet-nhdp-10.txt - WGLC - Oct 5th
|2009
|
|Am Donnerstag 17 September 2009 17:34:09 schrieb Justin Dean:
|> An alternate proposal:
|> NHDP interfaces of a router which running on the same medium must be
|> uniquely addressed.
|> NHDP interfaces of a router running on differing
|> mediums may be addressed the same (their "identifying," THIS_IF,
|address
|> sets MUST match completely.)
|
|I'm not sure if this will be enough with link quality together (or other
|link
|specific information in the hellos).
|
|Assume a chain of three nodes, A=B-C. There are two different sepparate
|channels between A and B, but only one between B and C (on a third
|channel).
|
|If C receives a hello from B, it cannot tell the link metrics values of
|the
|two connections between A and B appart, they have the same IP.
|
|Maybe I am missing something here ?
|
|Henning

---

From: Henning Rogge <[email-masked]>
Date: Thu, 17 Sep 2009 20:32:26 +0200

Am Donnerstag 17 September 2009 20:04:51 schrieb Teco Boot:
> 192.168.0.0/24 networks.
Hmm... I think anycast/multicast addresses received from your one-hop 
neighbors should never appear inside your own Hello message, only your own 
anycast/multicast ips (as LOCAL_IF = OTHER_IF). This would solve the problem, 
but NHDP would be unable to tell you anycast/multicast membership more than 
one hop away.

> Luckily, nobody was shot.
;)

Henning

---

From: "Justin Dean" <[email-masked]>
Date: Thu, 17 Sep 2009 14:55:11 -0400

Metrics are not currently part of NHDP the way you might be thinking.  There
are up threshold/metric concepts along with state machines which dictate
behavior with regard to these and bringing links up and down but there is no
prebuilt way for calculating these link metrics.  I believe that OLSRv2 will
have some method of doing this (easily done on a two hop basis with
packetbb/NHDP methods) 

Anycast and multicast are currently not supported directly, the issue NHDP
has with this situation is illustrated in my previous example.  If an
anycast/multicast address is included in a hello message with a LOCAL_IF
type TLV (with value either THIS_IF or OTHER_IF) then that address will be
used upon reception to identify the entry in the receiving routers
N_neighbor_addr_list.  This will cause the routers which are transmitting
these addresses to write over each other's "Neighbor Tuple" entry in
receiving routers N_neighbor_addr_list.

A simple fix to this would be with the addition of a different TLV type (say
OTHER_IP), or with a new LOCAL_IF value (say OTHER_IP).  The first case is
cleaner as having a value of OTHER_IP as an entry of the LOCAL_IF list.
Furthermore if a different type was used it could be done as an add on to
NHDP and provide even greater functionality with differing values (say
anycast vs multicast destination vs source).  I am open to thoughts
preferences on this.

Justin

> Of Teco Boot
> Sent: Thursday, September 17, 2009 2:05 PM
> To: 'Henning Rogge'; [email-masked]
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Fri, 18 Sep 2009 10:38:11 +0100

First, my apologies, I'm going to just drop a couple of comments,
then won't see any responses for a week.

> have some method of doing this (easily done on a two hop basis with

See the latest version of draft-dearlove-olsrv2-metrics for how
we are planning to add metrics to OLSRv2, including to HELLO
messages. Fundamentally we report direct and best metrics to an
address, the latter possibly using another link. But this is
OLSRv2, not NHDP. Other users of MHDP may not need metrics, and
thus should not be burdened with them.

We are working on the addrssing issue. Basically, without the
need for on the wire interface IDs, as long as a router can map
a HELLO message to the corresponding Interface Information
Base (which may use an interface ID, but NHDP doesn't need to get
into that detail, it just needs the concept I just mentioned)
then duplicate addresses on different interface are possible
IF messages from these interfaces cannot be received by the same
neighbour interface. This is the case in Stan's example, and is
the case for e.g. a node with two 802.11 interfaces (and possibly
Ethernet interfaces also) if the 802.11 interfaces use different
channels. This I think gets the gain in the cases of real interest
without added complexity and bandwidth.

With regard to how many addresses to advertise, there is an NHDP
and an OLSRv2 answer. For pure NHDP use, each interface needs
at least one address, and also to report any address that it may
use as the source address of an IP datagram carrying NHDP information.
(In practice you can probably ensure the same address is always used.)
For OLSRv2 use that needs to be extended to also include any addresses
the router wants to make globally available as a destination. (Stronger
requirements, that result in added information, is explicitly noted
as permitted, it has to be in order to build e.g. OLSRv2 or SMF.)

Fundamentally, all that needs to change in NHDP is
- A relaxation of address reuse, but with the important caveat above.
- A relaxation of required address inclusion, with the condition
  noted above.

(There are of course details to get right, as ever.)