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

From: Ian Chakeres <[email-masked]>
Date: Sun, 30 Aug 2009 08:45:41 -0400

This note announces the WG Last Call for comments on
draft-ietf-manet-nhdp-10.txt, "MANET Neighborhood Discovery Protocol".

The document can be found at:
http://www.ietf.org/internet-drafts/draft-ietf-manet-nhdp-10.txt

The document is intended to be submitted for publication as an
proposed standard document.

Please review the document carefully and send your comments to the
MANET list and document authors.

This last call ends Sunday Oct 5th.

Thanks,
Ian Chakeres

---

From: Ian Chakeres <[email-masked]>
Date: Mon, 31 Aug 2009 09:45:00 -0400

I am glad that several of the concerns I voiced last week are being
discussed. Based on the discussion, I believe that some of these
issues will be addressed in the next revision of NHDP (e.g. allow
unicast).

I feel the following are important and have not yet been resolved.

1) Words of wisdom for creating NHDP extensions, especially those
learned from OLSRv2 & SMF.

2) Administrative separation of information over wireless
communication, previously described as "instances" or "areas".

3) NHDP node identifiers.

4) Identifying interfaces, when they use the same address.

5) Some more tutorial information on why certain design decisions were
made that are not obvious to people outside MANET, especially as the
complexity relates to 2-way neighboring interfaces and 2-hop
neighboring information.

I encourage people to read the NHDP I-D and provide comments to the
authors on list.

Thanks.
Ian Chakeres

---

From: Thomas Heide Clausen <[email-masked]>
Date: Mon, 31 Aug 2009 16:03:51 +0200

> issues will be addressed in the next revision of NHDP (e.g. allow

Huh? I don't believe that there's been any support for unicast, but  
rather that we've all said that it's something that specifically does  
*not* warrant any explicit addressing in NHDP.

> learned from OLSRv2 & SMF.

The way of designing extensions is not proper to NHDP, but to the  
whole grouping of RFC5444/RFC5498/NHDP/current-WG-protocols. In a  
sense, you suggest recording the "collective wisdom of the WG" -- not  
sure that we can do that ;) and certainly not in NHDP.

I therefore oppose adding such to the NHDP specification.

We can discuss (outside of this WGLC) if this is something that'd  
warrant being documented in an informational or BCP submission, though?

> communication, previously described as "instances" or "areas".

Strongly disagree, the arguments have been presented previously.

> 3) NHDP node identifiers.

Strongly disagree, Justin has argued this well.

> 4) Identifying interfaces, when they use the same address.

Strongly disagree, Justin has argued this well.

> complexity relates to 2-way neighboring interfaces and 2-hop

Strongly disagree, the arguments have been presented previously.

> I encourage people to read the NHDP I-D and provide comments to the

On that, I agree 100% - reviews and constructive comments on [email-masked] 
  very welcome.

Thomas

---

From: Henning Rogge <[email-masked]>
Date: Mon, 31 Aug 2009 16:04:12 +0200

> learned from OLSRv2 & SMF.
SMF & OLSRv2 use NHDP as a "TLV transport service" to transport their own 
neighbor-specific data. I don't think they really change/extend the behavior 
of NHDP (maybe I'm wrong)...

> 3) NHDP node identifiers.
(I assume that you are talking about something like the originator-address in 
OLSR)

I talked with Thomas about this at the IETF meeting and he proposed that 
originator-IPs/router-IDs can be required by the OLSRv2 specification. They 
are not absolutely necessary for NHDP, but might help in some scenarios with 
multiple interfaces using the same IP.

> 4) Identifying interfaces, when they use the same address.
I see two different scenarios here:

4a) one node with multiple interfaces, some of them using the same IP.

This is a bad idea, but I personally know there are users of OLSRv1 out there 
doing this, because it helps with certain routing problems. There is lots of 
trouble hidden with this configuration for NHDP, because cannot keep 
differentiate between incoming messages from interfaces with sharing IPs 
without additional information in the NHDP message.

4b) two different nodes with an interface configured to the same IP.

Shoot your admins... do it now !
I don't think there is much we can do in this case.

Henning Rogge

---

From: Thomas Heide Clausen <[email-masked]>
Date: Mon, 31 Aug 2009 16:13:04 +0200

Henning,

> of NHDP (maybe I'm wrong)...

That's pretty accurate, yeah. OLSRv2 and SMF do not modify the  
behavior of NHDP -- but stick information into NHDP to associate with  
information already carried by NHDP.

> multiple interfaces using the same IP.

Actually (and Henning, I owe you an apology for not following up --  
actually took a couple of weeks off-line post-IETF this year),  
Christopher and I discussed this and a couple of auxiliary issues with  
Henning and Teco at the last IETF, and we've spent a bunch of time  
working it over. It's an OLSRv2 issue only, and the coming version of  
OLSRv2 will take this on-board as you guys suggested.

However, we'll discuss that OLSRv2 update outside of this NHDP WGLC  
when the updated I-D is out (the "weeks off-line post-IETF" are the  
reason that I-D has not emerged fully yet).

So that is an OLSRv2 issue, specifically NOT an NHDP issue.

> Shoot your admins... do it now !

Well, I'd suggest something just a notch less drastic -- but the net  
result should be unique IP addresses ;)

> I don't think there is much we can do in this case.

Agree.

Thomas

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

---

From: Stan Ratliff <[email-masked]>
Date: Mon, 31 Aug 2009 10:18:44 -0400

One comment inline.

On Aug 31, 2009, at 10:03 AM, Thomas Heide Clausen wrote:

> rather that we've all said that it's something that specifically  
> does *not* warrant any explicit addressing in NHDP.
>
> sense, you suggest recording the "collective wisdom of the WG" --  
> not sure that we can do that ;) and certainly not in NHDP.
>

Some of our deployments use ip unnumbered interfaces. It has to do  
with the type of radio deployed (radios implementing RFC4938), and use  
of PPPoE in the router. I'd hate to preclude use of NHDP in these  
deployments.

Regards,
Stan

---

From: Thomas Heide Clausen <[email-masked]>
Date: Mon, 31 Aug 2009 16:27:28 +0200

On Aug 31, 2009, at 4:18 PM, Stan Ratliff wrote:

> with the type of radio deployed (radios implementing RFC4938), and  
> use of PPPoE in the router. I'd hate to preclude use of NHDP in  
> these deployments.
>
> Regards,
> Stan
>

Stan,

Your thoughts are usually worth listening to -- can you be a little  
more explicit, does NHDP as-is somehow contradict the deployments that  
you target?

IOW, would NHDP as currently described work or not-work for you?

I suspect that NHDP would work, and that making it do so would be a  
deployment issue -- but as I do not know details of your deployments,  
I'd like to make sure that they're actually covered?

Thanks,

Thomas

---

From: Stan Ratliff <[email-masked]>
Date: Mon, 31 Aug 2009 11:09:58 -0400

Thomas,

As I understood the earlier thread (and my apologies for not speaking  
up sooner), there are some NHDP issues that Ian expressed when using  
the same ip address on multiple interfaces, via "ip unnumbered". This  
is what we do in some deployments, when using RFC4938-compliant  
radios. In these deployments, the radio establishes a point-to-point  
session (by some mechanism unknown to me) for each radio partner. That  
session is represented in the router by a PPPoE session, with its own  
logical interface. All of these PPPoE interfaces have the same local  
IP address.

So if two router/radio units decide to establish multiple sessions  
with each other (not currently the case, but could happen in the  
future), I think there would be a problem with NHDP (again, as I  
understood Ian's email).

Or, does NHDP handle this?

Regards,
Stan

On Aug 31, 2009, at 10:27 AM, Thomas Heide Clausen wrote:

> more explicit, does NHDP as-is somehow contradict the deployments  
> that you target?
>
> deployment issue -- but as I do not know details of your  
> deployments, I'd like to make sure that they're actually covered?
>
> Thanks,
>
> Thomas

---

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

I agree with Ian and Stan on topics #3 and #4 (identifying routers,
interfaces).
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 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.
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.

On Henning his 4b (same address on different routers):
OSPF has no problem with this.
Many admins that configured anycast want to stay alive.
I am one of them!

On Justin's argument:
> Furthermore things get even more complicated when these 
> identifier addresses change or disappear but the underlying
> addressing does not.
My major concern is ever changing addresses. Identifiers would be
stable (or MUST be, as specified in the MIB drafts).

Teco.

=========

Van: [email-masked] [mailto:[email-masked]] Namens Stan
Ratliff
Verzonden: maandag 31 augustus 2009 17:10
Aan: Thomas Heide Clausen
CC: Christopher Dearlove; MANET IETF
Onderwerp: Re: [manet] draft-ietf-manet-nhdp-10.txt - WGLC - Oct 5th 2009

Thomas, 

As I understood the earlier thread (and my apologies for not speaking up
sooner), there are some NHDP issues that Ian expressed when using the same
ip address on multiple interfaces, via "ip unnumbered". This is what we do
in some deployments, when using RFC4938-compliant radios. In these
deployments, the radio establishes a point-to-point session (by some
mechanism unknown to me) for each radio partner. That session is represented
in the router by a PPPoE session, with its own logical interface. All of
these PPPoE interfaces have the same local IP address.

So if two router/radio units decide to establish multiple sessions with each
other (not currently the case, but could happen in the future), I think
there would be a problem with NHDP (again, as I understood Ian's email). 

Regards,
Stan

One comment inline.

Some of our deployments use ip unnumbered interfaces. It has to do with the
type of radio deployed (radios implementing RFC4938), and use of PPPoE in
the router. I'd hate to preclude use of NHDP in these deployments.

Regards,
Stan

Stan,

Your thoughts are usually worth listening to -- can you be a little more
explicit, does NHDP as-is somehow contradict the deployments that you
target?

I suspect that NHDP would work, and that making it do so would be a
deployment issue -- but as I do not know details of your deployments, I'd
like to make sure that they're actually covered?

Thanks,

Thomas