Subject: Re: [manet] Stability versus gateway specification

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 10 Jan 2013 11:24:54 -0800

Hello Henning (and Joe),

I will try to summarize the Gateway discussion for the Issue Tracker.

Joe said, on Dec. 8:

> while gatewaying reactive is perhaps more difficult and there may
> be multiple strategies i also feel something should be in the base
> specification

It could be argued that the IAR description within AODVv2 is enough
for this purpose.  I've already said that I think the issue is nontrivial.
And, again, while I am not hoping to take responsibility for creating
additional specification in the reactive document, I am (as always)
happy to insert any text that you and/or the rest of the WG agrees
is required.

I need to mention two things:

- If the gateway advertises a default route [e.g. 0/0], then
   any AODVv2 router receiving it won't do Route Discovery.
   The likely result will be that the gateway will become an
   intermediate routing point for every route in the network.
   To me that sounds like a terribly nonscalable design.

- Any network that attaches to the Internet these days needs
    to have various policy knobs.  Do you suggest that we simply
    punt?  Do we make a normative reference for some other
    protocol that the IAR (or "Internet Gateway", or ...)
    MUST implement?

Manet gateways are not an issue specific to reactive protocols.
Any such specification ought to apply to both reactive and
proactive protocols (such as discussed in the document I
submitted earlier for discussion).  Did you have any comments
about that?

Regards,
Charlie P.

On 12/12/2012 11:39 PM, Henning Rogge wrote:
> On 12/12/2012 07:39 PM, Charles E. Perkins wrote:
>>
>> Hello Chris,
>>
>> Yes, if the WG decides to put in something about gateways in the
>> document, that will require more work.  I don't know if you had
>> a look at the expired document that I posted a few days ago on
>> the subject of gateways, but the discussion on the list also in my
>> opinion shows that the matter is not settled for OLSRv2 either.
>> I'm sure you can sift through the emails and find various points
>> that are not settled and still worthy of discussion.
>
> The difference is that OLSRv2 (and OLSRv1) contains the tool to handle 
> all kind of network situations be propagating any kind of prefix 
> through the network. This is the basis of internet uplinks and 
> attached networks.
>
> AODVv2 does not.
>
> Henning Rogge
>
>
>
>
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet

-- 
Regards,
Charlie P.

---

From: Abdussalam Baryun <[email-masked]>
Date: Fri, 11 Jan 2013 01:26:59 +0100

Hi Charlie,

question and comment below in line;

On 1/10/13, Charles E. Perkins <[email-masked]> wrote:
> proactive protocols

Yes this what I suggested as well, a separate work for gateway of manet routing,

>(such as discussed in the document I

Which document you refer to? please give me name and date,

AB

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 10 Jan 2013 17:36:01 -0800

Hello Abdussalam,

> Which document you refer to? please give me name and date,

Here is the information, which I sent out to the [manet] mailing list
on Dec. 10...

> we had quite a lot of discussion about
> the gateway possibilities several years ago.  Here's an old draft (that
> does work) from Ryuji:
> http://tools.ietf.org/id/draft-wakikawa-manet-globalv6-05.txt

-- 
Regards,
Charlie P.

---

From: Henning Rogge <[email-masked]>
Date: Fri, 11 Jan 2013 08:10:06 +0100

>    To me that sounds like a terribly nonscalable design.

One way to resolve the problem of the "default route" would be to 
restrict the addresses of the MANET to a certain prefix and install a 
blackhole route for it. This way the default route would have a hole for 
the host routes of the MANET.

> submitted earlier for discussion).  Did you have any comments

I would expect every routing protocol to be able to deliver all kinds of 
prefixes through its network, including the 0.0.0.0/0 and the ::/0 prefix.

As long as the prefixes do not overlap this is also non-problematic for 
reactive routing protocols.

Henning Rogge

-- 
Diplom-Informatiker Henning Rogge , Fraunhofer-Institut für
Kommunikation, Informationsverarbeitung und Ergonomie FKIE
Kommunikationssysteme (KOM)
Fraunhofer Straße 20, 53343 Wachtberg, Germany
Telefon +49 228 9435-961,   Fax +49 228 9435 685
mailto:[email-masked] http://www.fkie.fraunhofer.de

---

From: Abdussalam Baryun <[email-masked]>
Date: Fri, 11 Jan 2013 11:45:46 +0100

Thanks Charlie, I missed that below message on 10 Dec 2012,
http://www.ietf.org/mail-archive/web/manet/current/msg14394.html

AB

---

From: "Charles E. Perkins" <[email-masked]>
Date: Mon, 14 Jan 2013 22:27:34 -0800

Hello Henning,

Following up your assertion about 0/0...

On 1/10/2013 11:10 PM, Henning Rogge wrote:
> blackhole route for it. This way the default route would have a hole 
> for the host routes of the MANET.

Please say a bit more...

- Who is restricting?
    Does it mean that 0/0 is "not special" but the manet "is special"?
- Who is installing?
- When does the installation occur?
- What about a scenario when previously unrelated nodes decide to
    form an ad hoc network?   <I thought this was somehow relevant>
    What if all they bring to the network is their address or subnet,
    except for perhaps a very few that can occasionally establish an
    expensive link to the Internet?

I'm certainly willing to agree that with enough administrative control
and policy knobs, one can make default routes work.  Is this also your
viewpoint?

But even so, I'm reluctant to go in that direction because there are
quite a few competing designs to enable 0/0, which have the effect
of either (i) making the protocol more complicated or (ii) introducing
more requirement for administrative controls (i.e., not "ad hoc").

>
> I would expect every routing protocol to be able to deliver all kinds 
> of prefixes through its network, including the 0.0.0.0/0 and the ::/0 
> prefix.
>
> As long as the prefixes do not overlap this is also non-problematic 
> for reactive routing protocols.
>

Here's where more administrative controls are also useful.  Any
two routers advertising 0/0 are overlapping.  That's something
unique about 0/0, compared to all other prefixes which would
be likely encountered in the network.

-- 
Regards,
Charlie P.

---

From: Henning Rogge <[email-masked]>
Date: Tue, 15 Jan 2013 07:42:34 +0100

>     Does it mean that 0/0 is "not special" but the manet "is special"?

I think reactive routing protocols need some special care for prefixes. 
Because of their "on demand" aspect, they might miss a route with a 
longer prefix because the shorter prefix is still there.

> - Who is installing?

Could be done by the administrator during the setup of the node.

Something like "this subnet is reserved for host routes, install a 
blackhole route to get no-route-available events".

>     What if all they bring to the network is their address or subnet,

Where do they get the address/subnet from? If they all have the same 
subnet, they could easily install a blackhole route for it.

>     expensive link to the Internet?

I don't think building a network of nodes by different parties and 
giving all of them a totally random network address is a good idea.

> and policy knobs, one can make default routes work.  Is this also your

Its not only default routes, its any kind of routes.

If you have a node that announces a prefix which overlaps with 
host-routes of the network, you are in trouble in reactive protocols.

Henning Rogge

---

From: "Charles E. Perkins" <[email-masked]>
Date: Mon, 14 Jan 2013 23:07:19 -0800

Hello Henning,

On 1/14/2013 10:42 PM, Henning Rogge wrote:
> I think reactive routing protocols need some special care for 
> prefixes. Because of their "on demand" aspect, they might miss a route 
> with a longer prefix because the shorter prefix is still there.

This is exactly my point, restated.

Or, to say it the other way around -- as long as the nodes aren't 
advertising 0/0,
no special care is needed except that the AODVv2 routers have to obey the
universal rule for advertising a subnet prefix.

> Could be done by the administrator during the setup of the node.

As currently specified, AODVv2 does not require any such extra
installation instructions.  Only the address -- that's it.

> blackhole route to get no-route-available events".

Yes, that is exactly my point.  Something like that, or something
like one of the other half-dozen ways of fixing the problem.

> subnet, they could easily install a blackhole route for it.

Please say more about what the requirements are when there are
50 nodes, 10 of which lie on a subnet, and one of the nodes can
have an Internet connection when necessary.

How many nodes get exactly which blackhole route?
Do they all need the same network administrator?

> giving all of them a totally random network address is a good idea.

Well, it absolutely does work.

> Its not only default routes, its any kind of routes.

For all other routes likely to be encountered, the noted
phenomenon of gateway congestion is quite unlikely to
occur.

> host-routes of the network, you are in trouble in reactive protocols.

A router can't advertise a prefix unless it guarantees the
ability to reach nodes with addresses on that prefix.
Otherwise, the router is just spreading falsehoods and
bad things can happen.  Just because it's an ad hoc network
does not mean that a node in the network can wreck the
addressing convention of the address family from which it
takes addresses.

-- 
Regards,
Charlie P.

---

From: Henning Rogge <[email-masked]>
Date: Tue, 15 Jan 2013 08:17:58 +0100

> universal rule for advertising a subnet prefix.

I disagree. (example below)

> like one of the other half-dozen ways of fixing the problem.

Which shows that there IS a problem.

> Well, it absolutely does work.

Which doesn't make it a good idea in my opinion. Especially not if you 
want to support any kind of gateway/prefix announcement.

A better way might be to switch to IPv6 and get your random addresses 
from a global /64 prefix... less chance to get a collision AND an easy 
way to prevent shorter prefixes to block your host routes.

> addressing convention of the address family from which it

Lets take an example.

A network of mesh nodes with random addresses.

One of them is also attached to a local ethernet with the the configured 
prefix 10.0.0.0/8 (a common prefix for a home network) and wants this 
nodes to be available on the mesh.

If it publishes this prefix, it could block other nodes who randomly got 
allocated a host address from this range.

---

The other way around,

if all your nodes grab their random IP address from 10.0.0.0/8, its easy 
to forbid prefixes to be announced from this range AND install a 
blackhole route for 10.0.0.0/8, so even shorter prefixes cannot block 
the "still to be discovered" host routes of the mesh.

Henning Rogge

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 15 Jan 2013 00:35:33 -0800

Hello Henning,

> Which shows that there IS a problem.

Well...  I'm not sure what you're saying here.  I do not personally want
to write the specification for advertising 0/0.  I think it leads to 
problems
that do not require a reactive-protocol-specific solution.

You agree there is a problem.

> want to support any kind of gateway/prefix announcement.

I'd like to support Mobile IP in the ad hoc network...  We did it before
and it works great.  I've already cited the document.

And it works even if the gateway is advertising a prefix.  These are by
no means mutually exclusive functions.

> way to prevent shorter prefixes to block your host routes.

If you're trying to convince me to re-run the playbook from the former
[autoconf] working group, l will just for now claim that this proves my
point that we should delay the matter.

> One of them is also attached to a local ethernet with the the 
> configured prefix 10.0.0.0/8 (a common prefix for a home network) and 
> wants this nodes to be available on the mesh.

The net-10 subnet wants its net-10 addressable nodes to be available
for communications across the entire MANET, if I understand your
hypothesis...

>
> If it publishes this prefix, it could block other nodes who randomly 
> got allocated a host address from this range.

a) it can't publish the prefix if it doesn't own the prefix.

b) you can't mix random addressing and subnets.  This is because
      subnets "own" their address range.

Somehow I feel I must be missing your point.

Are we talking about net-10 allocations from several routers in the
same MANET?  Ouch-e-roonie (to use the technical terminology).
NAT too?  Pour me a double.

>
> The other way around,
>
> if all your nodes grab their random IP address from 10.0.0.0/8, its 
> easy to forbid prefixes to be announced from this range AND install a 

On which of the 50 nodes is the blackhole route installed?
What if the net-10 router only comes up the day after
tomorrow?  Who's administering the other nodes?

It's "easy" if there's a network administrator handy (not too ad-hoc).

Actually, I'm not clear on your scenario, or even whether we mean
the same thing by "blackhole route":
                   http://en.wikipedia.org/wiki/Null_route

And I am really not at all understanding why this is germane to
what needs to be done soon for reactive routing protocol specification.

-- 
Regards,
Charlie P.

---

From: Abdussalam Baryun <[email-masked]>
Date: Tue, 15 Jan 2013 10:45:03 +0100

Hi Charlie,

I want to understand the subject title: stability vs gateway spec,
What you mean by stability, there was no discussion on it in thread.
Do you mean network stability?

AB

On 12/12/12, Charles E. Perkins <[email-masked]> wrote:
> I strongly believe that the subject is important enough to merit
> a separate effort.  And, while it is true that proactive is easier,
> there are many design issues in common, so that a separate
> document could be made to apply to both proactive and reactive.
>
> Perhaps after my local fires (IEEE, etc.) have died down in a few
> more days, I'll write up a requirements draft for Gateways that
> enumerates the issues raised here on the list as well as others
> discussed in the past.  It's not as easy as just saying "0/0".
>
>
>
> On 12/12/2012 10:03 AM, Dearlove, Christopher (UK) wrote:
>> I think given that there was discussion just in the last week or two on
>> the status of gateways, that's just one example where features aren't
>> stable. And I don't believe the WG has actually expressed a view on much
>> of what's in or not in the document.
>>
>
>
> --
> Regards,
> Charlie P.
>

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 15 Jan 2013 08:27:51 -0800

Hello Abdussalam,

I meant "stability of the WG document".

I think that we're pretty close to having a good specification for the
base protocol functionality with a few optional behaviors that have
been published in previous [manet] documents.

Adding the Internet Gateway function will, if history is any guide,
take a good bit longer.

Regards,
Charlie P.

-- 
Regards,
Charlie P.

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 16 Jan 2013 20:19:33 -0500

Henning and Charlie:

Sorry for delay in responding....  

The 10.0.0.0/8 example will occur in the wild. People will pull out their
manet router with factory defaults. 

I have seen routing policy that forbids 10.0.0.0/8 in a network (Henning's
example). 
I have also seen Charlie's example where the people blocked each other.

I'm sorry to be dense here. Your two behaviors simply restate the basics of
routing and policy.
If you allow external route or static route insertion, these are possible. 

I thought the answer you both gave me was:

1) this is insertion of routes into reactive protools is useful but hard, 
2) current manet protocols will go on without prefix insertion, 
3) We'll work next on as a specific topic. 

I look forward to working on the route insertion at the right time with both
of you.

Sue

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Henning Rogge
Sent: Tuesday, January 15, 2013 2:18 AM
To: Charles E. Perkins
Cc: [email-masked]
Subject: Re: [manet] Stability versus gateway specification

On 01/15/2013 08:07 AM, Charles E. Perkins wrote:
> advertising 0/0, no special care is needed except that the AODVv2 
> routers have to obey the universal rule for advertising a subnet 
> prefix.

> Yes, that is exactly my point.  Something like that, or something like 
> one of the other half-dozen ways of fixing the problem.

> 50 nodes, 10 of which lie on a subnet, and one of the nodes can have 
> an Internet connection when necessary.
>

> Well, it absolutely does work.

Which doesn't make it a good idea in my opinion. Especially not if you want
to support any kind of gateway/prefix announcement.

A better way might be to switch to IPv6 and get your random addresses from a
global /64 prefix... less chance to get a collision AND an easy way to
prevent shorter prefixes to block your host routes.

>>> I'm certainly willing to agree that with enough administrative 
>>> control and policy knobs, one can make default routes work.  Is this 
>>> also your viewpoint?
>>
> For all other routes likely to be encountered, the noted phenomenon of 
> gateway congestion is quite unlikely to occur.
 >
> A router can't advertise a prefix unless it guarantees the ability to 
> reach nodes with addresses on that prefix.
> Otherwise, the router is just spreading falsehoods and bad things can 
> happen.  Just because it's an ad hoc network does not mean that a node 
> in the network can wreck the addressing convention of the address 
> family from which it takes addresses.

Lets take an example.

One of them is also attached to a local ethernet with the the configured
prefix 10.0.0.0/8 (a common prefix for a home network) and wants this nodes
to be available on the mesh.

---

The other way around,

if all your nodes grab their random IP address from 10.0.0.0/8, its easy to
forbid prefixes to be announced from this range AND install a blackhole
route for 10.0.0.0/8, so even shorter prefixes cannot block the "still to be
discovered" host routes of the mesh.

Henning Rogge

--
Diplom-Informatiker Henning Rogge , Fraunhofer-Institut für Kommunikation,
Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM)
Fraunhofer Straße 20, 53343 Wachtberg, Germany
Telefon +49 228 9435-961,   Fax +49 228 9435 685
mailto:[email-masked] http://www.fkie.fraunhofer.de

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 16 Jan 2013 20:30:49 -0500

Charlie and Henning:

Perhaps I don't understand your posts, but as far as I can tell you are
discussion two sides of the same problem.

Charlie says: 

[snip]
[snip]

I have seen two nodes publish prefixes they claim to own based on static
route insertion policy. 
(See the SIDR discussion on prefix/Origin AS mapping. )

The point I thought Henning was making is that it will happen so we need
policy to deal with it.  
Charlie's point was it should not occur based on theory. 

Both are true, and should be considered as we work toward external route
insertion.  It is what makes this design so much fun. 

Sue 
 
[warning: 
I am not a zeroconf, netconf, or AODV2 expert]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Charles E. Perkins
Sent: Tuesday, January 15, 2013 3:36 AM
To: Henning Rogge
Cc: [email-masked]
Subject: Spam:******, Re: [manet] Stability versus gateway specification

Hello Henning,

> Which shows that there IS a problem.

Well...  I'm not sure what you're saying here.  I do not personally want to
write the specification for advertising 0/0.  I think it leads to problems
that do not require a reactive-protocol-specific solution.

> want to support any kind of gateway/prefix announcement.

I'd like to support Mobile IP in the ad hoc network...  We did it before and
it works great.  I've already cited the document.

And it works even if the gateway is advertising a prefix.  These are by no
means mutually exclusive functions.

>>>> control and policy knobs, one can make default routes work.  Is 
>>>> this also your viewpoint?
>>>
>> For all other routes likely to be encountered, the noted phenomenon 
>> of gateway congestion is quite unlikely to occur.
> >
>> happen.  Just because it's an ad hoc network does not mean that a 
>> node in the network can wreck the addressing convention of the 
>> address family from which it takes addresses.
>
> Lets take an example.
>

The net-10 subnet wants its net-10 addressable nodes to be available for
communications across the entire MANET, if I understand your hypothesis...

Are we talking about net-10 allocations from several routers in the same
MANET?  Ouch-e-roonie (to use the technical terminology).
NAT too?  Pour me a double.

On which of the 50 nodes is the blackhole route installed?
What if the net-10 router only comes up the day after tomorrow?  Who's
administering the other nodes?

Actually, I'm not clear on your scenario, or even whether we mean the same
thing by "blackhole route":
                   http://en.wikipedia.org/wiki/Null_route

And I am really not at all understanding why this is germane to what needs
to be done soon for reactive routing protocol specification.

--
Regards,
Charlie P.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 16 Jan 2013 17:47:37 -0800

Hello Sue,

I am fine with your three points.

The WG manet protocols are applicable to networks for which
the nodes populating the networks are known to have unique
addresses.  So it would probably break the WG specifications
to have non-unique net-10 addresses.

I think that it probably makes sense to improve the
"Applicability Statement" to restrict AODVv2 for deployment
only in networks where the nodes have unique IP addresses.

Regards,
Charlie P.

-- 
Regards,
Charlie P.

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Thu, 17 Jan 2013 14:57:54 +0000

> only in networks where the nodes have unique IP addresses.

OK, I'm going to admit to writing this response without reading the "down thread" emails (man, we've gotten chatty recently)… 

I'm going to be in complete DISagreement about "writing the problem away" with regard to the above applicability statement. As the thread to this point has shown, address overlap is going to occur. It's extremely prevalent in the networks I work on. Employing a lot of poly-syllabic geek-speak that will parse down to "Don't do that." doesn't help users very much. To be honest, I don't have the answer, but I think this topic deserves some more discussion. I would suggest that we take Sue's point #3 and amend slightly to "We'll work on this some now and see if there's a reasonable approach. If not, it may be something we defer, as it brings up thoughts of the working group whose name shall not be mentioned."… ;-)

Regards,
Stan

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 17 Jan 2013 10:29:01 -0800

Hello Stan,

RFC 5444 doesn't handle address overlap.

Does your comment also apply to address overlap in OLSRv2
and DLEP?

Interestingly, in the scenarios under discussion, we might
have to qualify addresses with *two* prefixes, not just one.
Or, if the problem is multi-level, even more prefixes!

The solutions for address overlap I have encountered can
be applied to [manet], but, as they say, it's complicated.

-- 
Regards,
Charlie P.

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 17 Jan 2013 19:12:40 +0000

What's meant here by address overlap? An example would help.

-- 
Christopher Dearlove
Senior Principal Engineer, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 |  Fax: +44 1245 242124
[email-masked] | http://www.baesystems.com

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: [email-masked] [mailto:[email-masked]] On Behalf Of Charles E. Perkins
Sent: 17 January 2013 18:29
To: Stan Ratliff (sratliff)
Cc: <[email-masked]>
Subject: Re: [manet] Stability versus gateway specification

----------------------! WARNING ! ----------------------
This message originates from outside our organisation,
either from an external partner or from the internet.
Keep this in mind if you answer this message.
Follow the 'Report Suspicious Emails' link on IT matters
for instructions on reporting suspicious email messages.
--------------------------------------------------------

Hello Stan,

On 1/17/2013 6:57 AM, Stan Ratliff (sratliff) wrote:
> I'm going to be in complete DISagreement about "writing the problem away" with regard to the above applicability statement. As the thread to this point has shown, address overlap is going to occur. It's extremely prevalent in the networks I work on. Employing a lot of poly-syllabic geek-speak that will parse down to "Don't do that." doesn't help users very much. To be honest, I don't have the answer, but I think this topic deserves some more discussion. I would suggest that we take Sue's point #3 and amend slightly to "We'll work on this some now and see if there's a reasonable approach. If not, it may be something we defer, as it brings up thoughts of the working group whose name shall not be mentioned.". ;-)
>
>
-- 
Regards,
Charlie P.

********************************************************************
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: "Susan Hares" <[email-masked]>
Date: Thu, 17 Jan 2013 21:20:29 -0500

Stan:

Can you help me with a bit of clarity on your instructions in the email
statement below?  

Neither Charlie nor I have suggested insertion of the prefix cannot be done.
We only asked "do you want to do it now?"

My understanding from the LOADng and from the AODV2 participants was they
were trying to wrap of the document at this stage, and head toward RFC
without the external prefix insertion.   If you want to add prefix insertion
from multiple external points, IHMO based on trying it in another forum
(IEEEE) I suspect you are looking at year+ effort.  If you are looking for
"some", I am concerned to scope the "some" process to some defined set of
objectives. 

A sample set of objectives would be:

 a) create a problem you are trying to solve 
 b) determine solution criteria,
 c) Gap analysis on existing efforts,
 d) summarize the requirements, 
 e) suggest a few solutions, and 
f)  determine if "some" is worth slowing down.  

How does this fit with your design team plans? Can you provide a scope of
work plan and a timeline you'd like to have for the reactive protocol work. 

Thank you, 

Sue Hares

[snip] with email message below:  

I'm going to be in complete DISagreement about "writing the problem away"
with regard to the above applicability statement. As the thread to this
point has shown, address overlap is going to occur. It's extremely prevalent
in the networks I work on. Employing a lot of poly-syllabic geek-speak that
will parse down to "Don't do that." doesn't help users very much. To be
honest, I don't have the answer, but I think this topic deserves some more
discussion. I would suggest that we take Sue's point #3 and amend slightly
to "We'll work on this some now and see if there's a reasonable approach. If
not, it may be something we defer, as it brings up thoughts of the working
group whose name shall not be mentioned.". ;-)
[snip off]

-----Original Message-----
From: Stan Ratliff (sratliff) [mailto:[email-masked]] 
Sent: Thursday, January 17, 2013 9:58 AM
To: Charles E. Perkins
Cc: Susan Hares; <[email-masked]>
Subject: Re: [manet] Stability versus gateway specification

On Jan 16, 2013, at 8:47 PM, Charles E. Perkins wrote:

> The WG manet protocols are applicable to networks for which the nodes 
> populating the networks are known to have unique addresses.  So it 
> would probably break the WG specifications to have non-unique net-10 
> addresses.
> 
> I think that it probably makes sense to improve the "Applicability 
> Statement" to restrict AODVv2 for deployment only in networks where 
> the nodes have unique IP addresses.

OK, I'm going to admit to writing this response without reading the "down
thread" emails (man, we've gotten chatty recently). 

I'm going to be in complete DISagreement about "writing the problem away"
with regard to the above applicability statement. As the thread to this
point has shown, address overlap is going to occur. It's extremely prevalent
in the networks I work on. Employing a lot of poly-syllabic geek-speak that
will parse down to "Don't do that." doesn't help users very much. To be
honest, I don't have the answer, but I think this topic deserves some more
discussion. I would suggest that we take Sue's point #3 and amend slightly
to "We'll work on this some now and see if there's a reasonable approach. If
not, it may be something we defer, as it brings up thoughts of the working
group whose name shall not be mentioned.". ;-)

Regards,
Stan

>> The 10.0.0.0/8 example will occur in the wild. People will pull out 
>> their manet router with factory defaults.
>> 
>> I have seen routing policy that forbids 10.0.0.0/8 in a network 
>> (Henning's example).
>> I'm sorry to be dense here. Your two behaviors simply restate the 
>> basics of routing and policy.
>> I look forward to working on the route insertion at the right time 
>> with both of you.
>> 
>> 
>> Sue
>> 
>> 
> 
> --
> Regards,
> Charlie P.
>

---

From: Henning Rogge <[email-masked]>
Date: Fri, 18 Jan 2013 07:56:09 +0100

> RFC 5444 doesn't handle address overlap.

I am not sure how to parse that statement. RFC5444 "handles" (spells: 
transports) all kind of prefixes, with the option the leave out a full 
length prefix.

> Or, if the problem is multi-level, even more prefixes!

Thats already possible for RFC5444, you just put in both prefixes, both 
with the same address.

As an example, its totally okay to have 0.0.0.0/0 and 0.0.0.0/1 in your 
attached networks on OLSRv2 (we have this in a few Funkfeuer networks 
based on OLSRv1 too).

Henning Rogge

---

From: Henning Rogge <[email-masked]>
Date: Fri, 18 Jan 2013 08:44:24 +0100

> We only asked "do you want to do it now?"

My concern is about section 10 of DYMO draft v25, called "Simple 
Internet Attachment".

Its low on details and I am not convinced it does work without problems 
in all usecases Charly has described for AODVv2.

If the AODVv2 MANET use "randomized addresses", how should the IAR 
decide whats a "Internet Destination" and what not? Thats exactly the 
issue I was talking about when I mentioned "blackhole" routes.

To be sure that an AODVv2 router does NOT respond to a request to a host 
route for the MANET, it either needs to know all MANET addresses or at 
least their common prefix.

Otherwise the RREQ might just get lost towards the real node and the IAR 
will answer the request, blocking further access to the real destination.

Henning Rogge

---

From: Abdussalam Baryun <[email-masked]>
Date: Fri, 18 Jan 2013 17:36:03 +0100

Hi Sue and All,

Thanks for this, I agree that we need this, my comments in line,

> work plan and a timeline you'd like to have for the reactive protocol work.

For me I recommend to have the new reactive protocol done within 6
months milestone to submit, as we already have the ideas checked, but
maybe we need more discussions, however, don't mind what the chair
think best as long they make the decision not later than the next
meeting. My suggestion scope for reactive protocol, is not to include
the gateway issue (which will make the protocol late).

Regarding the WG plan, I think it will start with discussion and end
with new drafts and milestones, even though I am still waiting of the
update of our WG milestones. We ask the WG chairs to answer your
suggestions, regarding planning,

AB