Subject: [Int-area] About draft-baccelli-manet-multihop-communication-04

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 16 Jan 2015 19:02:57 +0100

Hello to intarea,

I have read again draft-baccelli-manet-multihop-communication-04:

https://tools.ietf.org/html/draft-baccelli-manet-multihop-communication-04

I think it is worth pursuing as knowledge shared by people with 
extensive experience in IP on wireless-LAN networks to people working on 
newer generation short-range wireless networks (BTLE, 802.15.4, more).

Essentially, the document reads that [contrary to typical wired links]
in wireless links it is difficult to make the otherwise intuitive
assumption that if A hears B then B hears A.  Similar to this 
assumption, there are 2 or 3 other assumptions not to make.

This has immediate effect on protocols such as ND: DAD would
fail because even if B receives NS from A, A would not receive the reply
NA from B, and would thus think it's alone on that link (whereas, in
truth, there is a duplicate - B).

Since this document was first issued, I worked on a number of projects 
and interacted with a number of people trying to make IP networks out of 
devices with a single radio interface.  Building a wifi range extender 
is the typical endeavour with some success, but many disillusions as 
well.  The effort is always laudable, especially because it brings in IP.

I am happy the document does not go as far as making a recommendation,
because, sensing the intent, I would disagree with the recommendation.

Reading the document, and thinking what the recommendation could be, my 
own comment - IMHO - is to not give up using IP on new-generation 
wireless links, but to improve the layers below IP such as to have IP 
run unmodified.  Second, is to use two radio interfaces on whatever is 
called an IP Router.  This applies to many current works at IETF.

That said, I believe this document is in good shape, has good language, 
is easy to read and agree with.

If there are any comments from the community on this document I will be 
happy to discuss about it on the intarea list.

Alex

---

From: Charlie Perkins <[email-masked]>
Date: Fri, 16 Jan 2015 10:37:13 -0800

Hello Alex,

Thanks for reviewing the document!

Follow-up below:

On 1/16/2015 10:02 AM, Alexandru Petrescu wrote:
> Reading the document, and thinking what the recommendation could be, 
> my own comment - IMHO - is to not give up using IP on new-generation 

In fact, I wholeheartedly support using IP over wireless links, new
generation or otherwise.  In fact, IP can just as well be used in
routers with a single radio interface, as long as the effects collected
in the document are observed.

Regards,
Charlie P.

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 17 Jan 2015 08:16:27 +1300

Alex,

> but to improve the layers below IP such as to have IP run unmodified. 

In the general case that is impossible, because the SDO that develops
the lower layer isn't interested. If the lower layer is intrinsically
NBMA then for sure ARP or ND+DAD will not work as designed. If the lower
layer doesn't support a physical MTU of at least 1280 IPv6 will not work
as designed. So in the general case both an adaptation layer and an
NBMA solution are required. And as you know, there are other "Ethernet"
assumptions that don't apply in a low-power wireless scenario.

Of course the goal is "IP over Everything" but that isn't the same as
"Everything must be like Ethernet", which you seem to imply.

In fact when you read draft-baccelli-manet-multihop-communication
(and imagine what its security section will say when it's been
written), I think the conclusion is that a great many things have
to change, not in the IP packet format, but in the ecosystem
currently provided by ARP/DHCP or RA/ND/DAD/SLAAC/DHCPv6.

  Brian

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 16 Jan 2015 20:04:59 +0000

+1

> -----Original Message-----
> From: Int-area [mailto:[email-masked]] On Behalf Of Brian E Carpenter
> Sent: Friday, January 16, 2015 11:16 AM
> To: Alexandru Petrescu; [email-masked]
> Subject: Re: [Int-area] About draft-baccelli-manet-multihop-communication-04
> 
> Alex,
> 
> _______________________________________________
> Int-area mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/int-area

---

From: Joe Touch <[email-masked]>
Date: Fri, 16 Jan 2015 12:58:27 -0800

FYI, there's an RFC explaining all this already: 3819

Joe

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 16 Jan 2015 21:09:04 +0000

Hi Joe,

> FYI, there's an RFC explaining all this already: 3819

PILC is indeed a fundamental reference, and I cite it whenever possible.

Thanks - Fred
[email-masked]

> From: Joe Touch [mailto:[email-masked]]
> Sent: Friday, January 16, 2015 12:58 PM
> To: Templin, Fred L; Brian E Carpenter; Alexandru Petrescu; [email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 17 Jan 2015 10:42:58 +1300

> PILC is indeed a fundamental reference, and I cite it whenever possible.

Indeed. I taught a module on this topic some years ago and the PILC work
was really all I needed then. The draft in question would do well to cite
the PILC work, but I think it's timely to revisit the topic and see
what guidelines would be useful for today's work. It does seem like
an Intarea WG topic.

    Brian

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 19 Jan 2015 17:19:31 +0100

Hello Charlie,

> in the document are observed.

There is one point not collected in the document about using 
single-interface routers: constant interference, systematic bandwidth 
reduction.  Such a router systematically repeats on same channel what it 
hears there, and bandwidth is systematically dropping.

(this is contrary to the typical random uncontrollable interference 
events - here we're sure about it).

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 19 Jan 2015 17:48:21 +0100

Brian,

Le 16/01/2015 20:16, Brian E Carpenter a écrit :
> In the general case that is impossible, because the SDO that
> develops the lower layer isn't interested. If the lower layer is
> intrinsically NBMA then for sure ARP or ND+DAD will not work as
> designed. If the lower layer doesn't support a physical MTU of at
> least 1280 IPv6 will not work as designed. So in the general case
> both an adaptation layer and an NBMA solution are required. And as
> you know, there are other "Ethernet" assumptions that don't apply in
> a low-power wireless scenario.
>
> Of course the goal is "IP over Everything" but that isn't the same
> as "Everything must be like Ethernet", which you seem to imply.
>
> written), I think the conclusion is that a great many things have to
> change, not in the IP packet format, but in the ecosystem currently
> provided by ARP/DHCP or RA/ND/DAD/SLAAC/DHCPv6.

In a sense I agree.

Adapting these IP protocols to these links (instead of improving MAC or
adaptation layers) seem to bring it Middle Boxes, break bidirectional
reachability from across globe, break security, hurt IP packet
analyzers, and more.

But certainly yes there are (1) some parameters in these IP protocols
(timers, preference values and (2) some protocol options (unsolicited
NA) which, when tweaked, make IP run better on these links.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 19 Jan 2015 18:08:54 +0100

> FYI, there's an RFC explaining all this already: 3819

I think this RFC can cover some of the issues raised in this draft, but 
it deserves a better treatment of peculiarities of wireless subnetworks.

For example, the hidden-terminal problem of wifi is not described in 
this RFC, and no advice provided.  Should WiFi non-wired IP routers 
prefer to use 2 interfaces?

Some wireless networks are special in other ways, not mentioned in the 
draft, pushing the mobility support to an extreme.  802.11p is 
completely silent (no link-layer messages other than announcing the 
time) to allow fast connection establishment. If so, how is the Host 
determining the MTU?  It _MUST_ send an RS on these links, it is no 
longer optional.  That being the advice.  Also, how to have NTP on these 
links?

NFC is a request-response link - should one use ICMP because small 
footprint?  Or TCP because reliable?

These are some of the questions one may confront with.

Alex

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 19 Jan 2015 17:19:57 +0000

> If so, how is the Host determining the MTU?

Each node sees an assured 1280 (or 1280-ENCAPS if an encapsulation header
is included). If the node wants to try for larger sizes, it can use RFC4821.

When you configure an NBMA tunnel virtual overlay over the underlying
wireless interfaces, there is no need for mutli-hop ND or DHCPv6 over the
underlying interfaces. Instead, standard unicast single-hop ND and DHCPv6
are used over the NBMA tunnel virtual interface.

Thanks - Fred

> From: Alexandru Petrescu [mailto:[email-masked]]
> Sent: Monday, January 19, 2015 9:09 AM
> To: Joe Touch; Templin, Fred L; Brian E Carpenter; [email-masked]

---

From: Joe Touch <[email-masked]>
Date: Mon, 19 Jan 2015 09:57:56 -0800

> it deserves a better treatment of peculiarities of wireless subnetworks.

There are other relevant BCPs that cover some of these points, e.g., 
3449, 6275, etc.

A full scan of existing RFCs would help before jumping in and assuming 
the IETF hasn't addressed these issues before, but certainly where they 
haven't been issued, new treatment would be warranted.

Joe

---

From: Joe Touch <[email-masked]>
Date: Mon, 19 Jan 2015 10:11:19 -0800

> NA) which, when tweaked, make IP run better on these links.

And some additional mechanisms that can be used here just as they have 
been other NBMA subnets, which already address the protocol issues above.

If IP has broader issues because of the persistent need for these 
mechanisms, then they should be dealt with. But so far I haven't heard 
anything sufficiently new for this environment to drive that discussion.

Joe

---

From: Emmanuel Baccelli <[email-masked]>
Date: Mon, 19 Jan 2015 21:35:50 +0100

Hi Joe,

PILC is a great ref that should be cited indeed. Another relevant ref is
RFC 5889. One of the recommendations that RFC boils down to:  *do not* use
on-link prefixes *at all* on interfaces to multi-hop wireless networks --
the subject of the draft we discuss now.

The reason is: there is no planned structure at link-layer and you cannot
guarantee anything in terms of connectivity over such wireless interfaces
-- which does not however mean that these interfaces are useless!

In short: this is not yet another simple case of NBMA. Ergo the need for
this draft.

Best,

Emmanuel

On Fri, Jan 16, 2015 at 9:58 PM, Joe Touch <[email-masked]> wrote:

> >> Subject: Re: [Int-area] About
> draft-baccelli-manet-multihop-communication-04
> >>
> >> Alex,
> >>

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 19 Jan 2015 21:00:14 +0000

As I understand it, your draft is trying to establish the notion of a multi-hop link but
that is not architecturally correct – I think that was the point of the PILC comment.

Instead of a multi-hop “link”, what you have is a multi-hop “subnetwork” with
link segments joined together by  subnetwork routing protocols. To establish
a link in the normal sense, configure an NBMA tunnel virtual overlay over the
subnetwork. IPv6 ND and DHCPv6 then work as-expected.

Thanks – Fred

From: [email-masked] [mailto:[email-masked]] On Behalf Of Emmanuel Baccelli
Sent: Monday, January 19, 2015 12:36 PM
To: Joe Touch
Cc: Templin, Fred L; Brian E Carpenter; Alexandru Petrescu; [email-masked]
Subject: Re: [Int-area] About draft-baccelli-manet-multihop-communication-04

Hi Joe,

PILC is a great ref that should be cited indeed. Another relevant ref is RFC 5889. One of the recommendations that RFC boils down to:  *do not* use on-link prefixes *at all* on interfaces to multi-hop wireless networks -- the subject of the draft we discuss now.

The reason is: there is no planned structure at link-layer and you cannot guarantee anything in terms of connectivity over such wireless interfaces -- which does not however mean that these interfaces are useless!

In short: this is not yet another simple case of NBMA. Ergo the need for this draft.

Best,

Emmanuel

On Fri, Jan 16, 2015 at 9:58 PM, Joe Touch <[email-masked]<mailto:[email-masked]>> wrote:
FYI, there's an RFC explaining all this already: 3819

Joe

On 1/16/2015 12:04 PM, Templin, Fred L wrote:
>> From: Int-area [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Brian E Carpenter
>> To: Alexandru Petrescu; [email-masked]<mailto:[email-masked]>
>> [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>

_______________________________________________
Int-area mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/int-area

---

From: Emmanuel Baccelli <[email-masked]>
Date: Mon, 19 Jan 2015 22:15:14 +0100

Hi Fred,

On Mon, Jan 19, 2015 at 10:00 PM, Templin, Fred L <[email-masked]
> wrote:

> that is not architecturally correct – I think that was the point of the

By design, the draft does not introduce any architectural notion. The goal
of the draft is rather to describe the physical reality experienced over
such networks. Once this is clearly documented, we might indeed have
debates about which architecture to adopt over such network above link
layer ;) But in a separate draft.

Best

Emmanuel

> *From:* [email-masked] [mailto:[email-masked]] *On
> Behalf Of *Emmanuel Baccelli
> *Sent:* Monday, January 19, 2015 12:36 PM
> *To:* Joe Touch
> *Cc:* Templin, Fred L; Brian E Carpenter; Alexandru Petrescu;
> [email-masked]
>
> *Subject:* Re: [Int-area] About

---

From: Joe Touch <[email-masked]>
Date: Mon, 19 Jan 2015 13:45:37 -0800

+1

A link layer that cannot reach all its members isn't a link layer - it's multiple link layers that need interconnection.  That's what routers are for. 

Full multihop reachability is common in link layers that are complete. 

Again, it'd be useful to show something the RFCs haven't already described.  Otherwise this would be better served by a collection of existing approaches. 

Joe

> On Jan 19, 2015, at 1:00 PM, Templin, Fred L <[email-masked]> wrote:
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 20 Jan 2015 18:00:05 +0100

Le 19/01/2015 18:57, Joe Touch a écrit :
>> I think this RFC can cover some of the issues raised in this draft,
>> but it deserves a better treatment of peculiarities of wireless
>> subnetworks.
>

TCP for assymmetric links and Mobile IP are good suggestions for LLNs.
However, I have never seen them mentioned in these groups - they are
completely overlooked.

> A full scan of existing RFCs would help before jumping in and
> assuming the IETF hasn't addressed these issues before,

Yes, for example we have ROHC and IP-over-802154 HC, two different things.

But I think we have no RFC warning there's a hidden terminal problem in
WiFi ad-hoc mode, or that radio range (power levels) is a determining 
factor.

> but certainly where they haven't been issued, new treatment would be
> warranted.

I agree.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 20 Jan 2015 18:08:11 +0100

Le 19/01/2015 22:00, Templin, Fred L a écrit :
> As I understand it, your draft is trying to establish the notion of
> a multi-hop link but that is not architecturally correct

I tend to agree Fred.  I think we need to clarify the word 'hop'.

A multi-IP-hop link does not really exist - it's an IP network.

A multi-subIP-hop link is made into a single-IP-hop by some subnetwork
non-IP 'routing' protocol.

'Route-over' and 'mesh-under' are hard to digest terms.  'Route-over' 
should have been called 'IP-over-subnet' and 'mesh-under' should have 
been called 'subIP switching'.

> – I think that was the point of the PILC comment.
>
> Instead of a multi-hop “link”, what you have is a multi-hop
> “subnetwork” with link segments joined together by  subnetwork
> routing protocols.

I agree.

> To establish a link in the normal sense, configure an NBMA tunnel
> virtual overlay over the subnetwork. IPv6 ND and DHCPv6 then work
> as-expected.

That[NBMA tunnel virtual overlay] is one way of making a multi-subIP-hop 
link into a good IP subnet.  There are other ways: RPL tries to do the 
same, and some times RIP-inspired below IP.

Alex

> *From:[email-masked]
> [mailto:[email-masked]] *On Behalf Of *Emmanuel Baccelli
> *Sent:* Monday, January 19, 2015 12:36 PM *To:* Joe Touch *Cc:*
> Templin, Fred L; Brian E Carpenter; Alexandru Petrescu;
> [email-masked] *Subject:* Re: [Int-area] About
> PILC is a great ref that should be cited indeed. Another relevant
> ref is RFC 5889. One of the recommendations that RFC boils down to:
> *do not* use on-link prefixes *at all* on interfaces to multi-hop
> wireless networks -- the subject of the draft we discuss now.
>
> The reason is: there is no planned structure at link-layer and you
> cannot guarantee anything in terms of connectivity over such
> wireless interfaces -- which does not however mean that these
> interfaces are useless!
>
>>> -----Original Message----- From: Int-area
>>> [mailto:[email-masked]
> <mailto:[email-masked]>] On Behalf Of Brian E Carpenter
>>> Sent: Friday, January 16, 2015 11:16 AM To: Alexandru Petrescu;
>>> [email-masked] <mailto:[email-masked]> Subject: Re:
>>> [Int-area] About
> develops
>>> as designed. So in the general case both an adaptation layer and
>>> an NBMA solution are required. And as you know, there are other
> "Ethernet"
>>> _______________________________________________ Int-area mailing
>>> list [email-masked] <mailto:[email-masked]>
>> _______________________________________________ Int-area mailing
>> list [email-masked] <mailto:[email-masked]>
> _______________________________________________ Int-area mailing list
> [email-masked] <mailto:[email-masked]>

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 20 Jan 2015 18:11:07 +0100

Le 19/01/2015 22:15, Emmanuel Baccelli a écrit :
> Hi Fred,
>
> On Mon, Jan 19, 2015 at 10:00 PM, Templin, Fred L
> <[email-masked] <mailto:[email-masked]>>
> wrote:
>
> As I understand it, your draft is trying to establish the notion of a
> multi-hop link but____
>
> that is not architecturally correct – I think that was the point of
> the PILC comment.____
>
> __
>
>
> By design, the draft does not introduce any architectural notion. The
>  goal of the draft is rather to describe the physical reality
> experienced over such networks.

I agree, that is a physical reality I also encountered.

I just am afraid of the conclusion.

When I say physical reality is that - by physics - 1 distanced listener 
will hardly hear the exchanges between 2 computers close to each other. 
  Unless some above-PHY layer provides some extension.  Just do not 
recommend that to be IP.

> Once this is clearly documented, we
> might indeed have debates about which architecture to adopt over such
> network above link layer ;) But in a separate draft.

I agree.

Alex

> __
> “subnetwork” with____
> link segments joined together by  subnetwork routing protocols. To
> establish____
>
> a link in the normal sense, configure an NBMA tunnel virtual overlay
> over the____
>
> subnetwork. IPv6 ND and DHCPv6 then work as-expected.____
>
> __ __
>
> Thanks – Fred____
>
> [email-masked] <mailto:[email-masked]>____
>
> __ __
>
> <mailto:[email-masked]>
> [mailto:[email-masked]
> <mailto:[email-masked]>] *On Behalf Of *Emmanuel
> Baccelli *Sent:* Monday, January 19, 2015 12:36 PM *To:* Joe Touch
> [email-masked] <mailto:[email-masked]>
>
>
> draft-baccelli-manet-multihop-communication-04____
>
> __ __
>
> Hi Joe,____
>
> __ __
>
> PILC is a great ref that should be cited indeed. Another relevant ref
> is RFC 5889. One of the recommendations that RFC boils down to: *do
> not* use on-link prefixes *at all* on interfaces to multi-hop
> wireless networks -- the subject of the draft we discuss now. ____
>
> __ __
>
> cannot guarantee anything in terms of connectivity over such wireless
> interfaces -- which does not however mean that these interfaces are
> useless!____
>
> __ __
>
> In short: this is not yet another simple case of NBMA. Ergo the need
> for this draft.____
>
> __ __
>
> Best,____
>
> __ __
>
> Emmanuel____
>
> __ __
>
> On Fri, Jan 16, 2015 at 9:58 PM, Joe Touch <[email-masked]
> <mailto:[email-masked]>> wrote:____
>
> Joe____
> <mailto:[email-masked]>
>>> In fact when you read
> draft-baccelli-manet-multihop-communication
> https://www.ietf.org/mailman/listinfo/int-area____
>
> __ __
>
>

---

From: Joe Touch <[email-masked]>
Date: Tue, 20 Jan 2015 09:16:12 -0800

> WiFi ad-hoc mode, or that radio range (power levels) is a determining

There's no RFC warning about unplugged ethernets either.

However, WiFi ad-hoc is just an NBMA subnet. If its multihop can't reach 
every party, then it's a disconnected subnet.

Neither of these are new.

Joe

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 20 Jan 2015 18:18:13 +0100

Le 19/01/2015 22:45, Joe Touch a écrit :
> +1
>
> A link layer that cannot reach all its members isn't a link layer - it's
> multiple link layers that need interconnection.  That's what routers are
> for.

I agree.

But we have no document that tells that a Router must have two 
interfaces, and hence Routers with 1 interface are built and hence the 
confusion of 'multi-hop' which needs a clarification in the form of the 
statement you put above.

> Again, it'd be useful to show something the RFCs haven't already
> described.  Otherwise this would be better served by a collection of
> existing approaches.

I think that's the only draft that describes the hidden terminal problem 
in wifi environments.

The draft also describes radio range limitations which are common in 
WiFi, but have no related description in other RFC.  I don't mean the 
problem has no wired counterpart problem, but that they are not 
described in existing RFCs.

WiFi has a range of 50meter (depending mainly on regulating aspects by 
geo-political, indoors/outdoors and other quirks like military 
restrictions).  By comparison, Ethernet cables of Category6 have a 
maximum length of 100meter beyond which attenuation reduces effective 
bandwidth by a certain amount.

This WiFi range problem is described only in this draft.

This Ethernet length problem is not described in any RFC.

Alex

>
> Joe
>
>
> On Jan 19, 2015, at 1:00 PM, Templin, Fred L <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>> multi-hop link but
>> the PILC comment.
>> “subnetwork” with
>> establish
>> over the
>> [email-masked] <mailto:[email-masked]>
>>
>> not* use on-link prefixes *at all* on interfaces to multi-hop wireless
>> networks -- the subject of the draft we discuss now.
>>
>> useless!
>> for this draft.
>> <mailto:[email-masked]>> wrote:
>>
>>     >> From: Int-area [mailto:[email-masked]

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 20 Jan 2015 18:24:50 +0100

> There's no RFC warning about unplugged ethernets either.

Before unplugging there's a range steps... which are easily noticed in WiFi.

I agree.

> Neither of these are new.

In a sense yes, these are not new.  But their description should be 
adapted to wifi.

Maybe we need a document that tells what's a disconnected subnet.

Alex

---

From: Joe Touch <[email-masked]>
Date: Tue, 20 Jan 2015 09:33:02 -0800

On 1/20/2015 9:18 AM, Alexandru Petrescu wrote:
> interfaces,

That's because that requirement does not exist.

A router can exist with one interface, e.g.:

	- to forward between devices on the same subnet
		forwarding involves both outgoing interface
		AND
		destination IP

	- to perform filtering in the process of forwarding
		e.g.,

		--> A --> B
			A sends all traffic NOT coming from
			B's interface and IP to B
	
		A <-- B
			B sends some subset of the traffic
			it receives to A, and dumps the rest

		<--A
			A uses a different table to forward
			all traffic received from B

> and hence Routers with 1 interface are built and hence the

In L3, hop is always to an IP address. It never corresponds 1:1 to a 
subnet link unless the link is unicast.

> I think that's the only draft that describes the hidden terminal problem

Hidden terminal in Wifi is an L2 issue. The L3 issue is broadcast 
reachability. PILC already discusses the hazards when a subnet doesn't 
support (true) broadcast.

I.e., in a wifi net with hidden terminal issues, you no longer have true 
broadcast, and shouldn't assume so. But that's also why most of our 
protocols have shifted from use of broadcast to multicast -- which would 
work fine with hidden terminal IF the subnet layer managed it properly.

> described in existing RFCs.

You would then be describing the impact of existing RFCs in terms of 
Wifi. That might be useful, but I don't think it warrants creating new 
mechanisms or solutions unless you can demonstrate they don't exist 
elsewhere.

However, limited radio range has been an issue for Internet protocols 
since the ARPAnet days.

...
> This Ethernet length problem is not described in any RFC.

Right. The point is that there's a reason we don't bother with the 
ethernet range issue in an RFC, and that same reason may apply here to 
your wifi observations.

Joe

---

From: Joe Touch <[email-masked]>
Date: Tue, 20 Jan 2015 09:33:28 -0800

On 1/20/2015 9:24 AM, Alexandru Petrescu wrote:
...
> Maybe we need a document that tells what's a disconnected subnet.

April 1 is coming soon...

Joe

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 20 Jan 2015 17:42:50 +0000

> However, limited radio range has been an issue for Internet protocols

Hah! When I worked at SRI, they had the packet radio van parked out back:

http://ed-thelen.org/comp-hist/CORE-3-1-SRI-TCP-IP.html

Thanks - Fred

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 20 Jan 2015 19:04:00 +0100

Le 20/01/2015 18:33, Joe Touch a écrit :
>>> A link layer that cannot reach all its members isn't a link
>>> layer - it's multiple link layers that need interconnection.
>>> That's what routers are for.
>>
>> I agree.
>>
> - to forward between devices on the same subnet forwarding involves
> both outgoing interface AND destination IP

That leads to undetermined and 'disconnected' subnets as long each
machine in it IP routes.  And prefixes are off-link (RFC number).

> - to perform filtering in the process of forwarding e.g.,

Right, but filtering should come after the subnet is established.

[...]
>> confusion of 'multi-hop' which needs a clarification in the form
>> of the statement you put above.
>
> In L3, hop is always to an IP address.

YEs, but the problem is when L3 and L2 are mixed by 1-interface routers
making up L2 subnets: two nodes in range are 1-hop away from each other,
be it a MAC hop or an IP hop.  But when out of range they're 2 IP-hops 
from each other, although they're still 1 MAC-hop away.

At this point it's hard to distinguish multi-hop from single subnet.

> It never corresponds 1:1 to a subnet link unless the link is
> unicast.
>
>>>  described.  Otherwise this would be better served by a
>>> collection of existing approaches.
>>
>> I think that's the only draft that describes the hidden terminal
>> problem in wifi environments.
>
> reachability. PILC already discusses the hazards when a subnet
> doesn't support (true) broadcast.
>
> I.e., in a wifi net with hidden terminal issues, you no longer have
> true broadcast, and shouldn't assume so. But that's also why most of
> our protocols have shifted from use of broadcast to multicast --
> which would work fine with hidden terminal IF the subnet layer
> managed it properly.

Hmm, I agree with the first part.  But if true broadcast is absent in 
hidden-terminal wifi networks, multicast would be difficult to ensure as 
well.
>
>> The draft also describes radio range limitations which are common
>> in WiFi, but have no related description in other RFC.  I don't
>> mean the problem has no wired counterpart problem, but that they
>> are not described in existing RFCs.
>
> Wifi. That might be useful, but I don't think it warrants creating
> new mechanisms or solutions unless you can demonstrate they don't
> exist elsewhere.
>
> However, limited radio range has been an issue for Internet
> protocols since the ARPAnet days.

Uh?  I guess when they came up with IP routing to offer range extension 
the notion of IP subnet did not exist?

> ethernet range issue in an RFC, and that same reason may apply here
> to your wifi observations.

Maybe we need to explain in this draft this: why it would be good to 
give less consideration to range issues, in wifi.  Or to explain that 
range is dictated by regulated power and spectrum sharing agreements.  I 
dont know?

Alex

---

From: Joe Touch <[email-masked]>
Date: Tue, 20 Jan 2015 10:23:08 -0800

On 1/20/2015 10:04 AM, Alexandru Petrescu wrote:
> machine in it IP routes.And prefixes are off-link (RFC number).

Please see RFC1812.

This method is used in exchange points, among other places.

...
> be it a MAC hop or an IP hop.

Link layer hops don't necessarily have anything to do with L3 hops.

> But when out of range they're 2 IP-hops

That's an issue for L2.

...
> hidden-terminal wifi networks, multicast would be difficult to ensure as

In that case, multicast support would be provided by unicast 
reachability in L3.

> the notion of IP subnet did not exist?

IP subnets have been around a very long time, but not all mechanisms are 
developed in the context of what has already been done before. That's 
what I'm suggesting should be avoided in this case.

> range is dictated by regulated power and spectrum sharing agreements.  I

These all sound like L2 (or maybe even L1) issues, and out of scope for 
RFCs AFAICT.

Joe

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 22 Jan 2015 13:10:51 +0100

>> machine in it IP routes.And prefixes are off-link (RFC number).

This RFC1812 "reqs for Routers" does not talk explicitely 1-interface 
routers, although it does mention logical and physical interfaces.

I agree that a Router can forward between two logical interfaces, both 
attached to a sole physical interface.  And that it can run forward 
between a sole physical interface, absent logical interfaces.

But it is not a good way for WiFi subnets.

The best way for wifi adhoc subnets is to separate subnets guided by 
power their range, with a different channel on each subnet, and a 
different on-link prefix, and use 2-physical-interface routers.  And 
each router to route between 2 physical interfaces.

This, of course, assumes relatively stable mouvement patterns, i.e. 
devices stay within the planned ranges.

Not surprisingly, staying stable within planned range is a 
characteristic found in many deployments.  Devices just dont move 
haphazardly.

> This method is used in exchange points, among other places.

I guess that means deep in the core network, whereas here we are at the 
edge.

> Link layer hops don't necessarily have anything to do with L3 hops.

I agree, but they are mixed together when using 1-interface routers.

I agree.

But I still do not know whether IP routing protocols should be used at 
MAC level.

It is however better to assume that a subnet is built and maintained by 
MAC protocols, rather than by IP protocols.

With 802.15.4 networks, one rather assumes the subnet is maintained by 
that MAC, and run IP over it as if it were one single hop, rather than 
running RPL.

> what I'm suggesting should be avoided in this case.

Ok.

> These all sound like L2 (or maybe even L1) issues, and out of scope for

Some times I think that is a very good advice.

But there are many recent RFCs that do L2 matters.

In the not so distant past, only PPP and ARP were famous for doing L2 in 
an RFC.  But recently there are very many RFCs doing L2 matters, 
especially in the field of IoT.

Alex

---

From: Joe Touch <[email-masked]>
Date: Thu, 22 Jan 2015 07:56:48 -0800

...
> routers, although it does mention logical and physical interfaces.

Section 5.2.1.2 indicates that forwarding selects next-hop IP address, 
THEN selects outgoing interface for that IP address. Because an 
interface can access multiple IP addresses, the number of interfaces 
does not limit forwarding.

> But it is not a good way for WiFi subnets.

Using a single interface works fine; it may not be efficient, but it 
does allow the router to provide a function that might not be possible 
at other routers (e.g., filtering).

So there's no one "best" way, but yes, it's not bandwidth-efficient to 
ever forward using a single interface.

> each router to route between 2 physical interfaces.

Yes. The best way is to have each wifi subnet connected by a router.

> devices stay within the planned ranges.

Certainly; IP doesn't react well to change ;-)

> characteristic found in many deployments.  Devices just dont move

Yes, but when that interferes with the definition of a subnet, that is 
an L2 problem. L3 expects a relatively stable L2.

> I guess that means deep in the core network, whereas here we are at the

Exchange points can be anywhere. Wifi subnets can be anywhere.

> I agree, but they are mixed together when using 1-interface routers.

They really aren't. L3 thinks every next-hop IP address is (by 
definition) one L3 hop away. How many L2 - or L1 - hops that takes is 
not relevant or visible, except as a cost metric added by a network 
operator.

> But I still do not know whether IP routing protocols should be used at

L3 protocols are just algorithms. Whether they're appropriate for a 
given L2 depends on the properties of the algorithm and the L2. E.g., 
TRILL extends ethernet L2 to allow use of IS-IS routing - the extension 
is needed because IS-IS doesn't avoid transient forwarding loops, and 
ethernet does not react well to those.

> MAC protocols, rather than by IP protocols.

I'm not sure I follow. L3 assumes L2 works; it doesn't fix deficiencies 
in a broken L2.

> that MAC, and run IP over it as if it were one single hop, rather than

That's true for all L2s.

...
> Some times I think that is a very good advice.

It may be, but the WIFI people need to read it, and they read the IEEE 
specs.

> But there are many recent RFCs that do L2 matters.

L2 interactions with L3. That's not the case here. What you're 
describing is an L2 that nobody - even L2 - can't really use. You can't 
have a native L2 protocol that used a WIFI network that had a hidden 
terminal issue, could you?

> especially in the field of IoT.

All, AFAICT, relate to necessary interactions between L2 and L3. What 
you're describing is how to build an L2 that isn't inherently broken. 
That seems out of scope IMO.

Joe

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 22 Jan 2015 17:45:52 +0100

Sorry for chiming in late; I haven't read the draft yet.
But the discussion raises an issue I ran into repeatedly.

On 2015-01-19 21:35, Emmanuel Baccelli wrote:
> Hi Joe,
> 
> PILC is a great ref that should be cited indeed. 

Indeed, RFC 3819 is a great basis for teaching, and I have also used it
a lot for that.  It's usefulness has strangely grown with age, like an
old wine.  It was written before we embraced RFC 5889, though, so those
considerations have to be added.

> Another relevant ref is
> RFC 5889. One of the recommendations that RFC boils down to:  *do not*
> use on-link prefixes *at all* on interfaces to multi-hop wireless

Yes.  We have a whole architecture that is based on off-link membership
of hosts to a subnet.  What makes this different is indeed:

> interfaces -- which does not however mean that these interfaces are useless!

It is important to understand the differences in lifetimes of subnets
and links.  Subnets are planned and stay for a while; mobility in this
model does *not* involve moving between subnets*).  Links are almost
ephemeral; they come and go with mobility (and other spontaneous changes
in radio characteristics).  Links are never "complete", indeed.  Routers
route on paths through links that are all in the same subnet (until, of
course, a border router is crossed and we are in a different subnet).

Completely different from the old idea of an NBMA, which is a
single-link subnet where nodes just aren't able to find each other via
multicast.

In continuation of the hard-to-root-out "all the world is an Ethernet"
thinking, I have also repeatedly run into assumptions not taking into
account RFC 5889-style networks, somehow implying that nothing has
changed from ATM-style NBMAs.  I'm sorry, it's all different.

Grüße, Carsten

*) Yes, you can *add* traditional inter-subnet mobility as an additional
service.  That, indeed, is about as well-understood as mobility always
has been...

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 22 Jan 2015 18:35:56 +0000

Hi ,

IP runs over "links" as specified in "IP-over-(foo)" documents. What the document in question
is describing is a "multi-link" which is not a candidate for "IP-over-(foo)".

Thanks - Fred

---

From: Emmanuel Baccelli <[email-masked]>
Date: Thu, 22 Jan 2015 22:54:14 +0100

Hi Fred

Le 22 janv. 2015 19:36, "Templin, Fred L" <[email-masked]> a
> is describing is a "multi-link" which is not a candidate for
"IP-over-(foo)".

Nevertheless, people (MANET, ROLL, AUTOCONF, 6LOWPAN...) have been running
IP over interfaces with connectivity as described in this draft. It's
difficult and it yields specific protocol design decisions because of the
unique characteristics of such connectivity, but it's doable.

More people (6LO, CORE, LWIG...) want to design more protocols running over
such networks. There is a risk that protocol design decisions that are made
do not capitalize on available knowledge about the characteristics of such
networks. Actually, the fact that we are having this argument right now
shows that:

- there is no such document available yet (except this draft)
- there is a need for such a document

Best,

Emmanuel

---

From: Charlie Perkins <[email-masked]>
Date: Thu, 22 Jan 2015 14:30:12 -0800

Hello Joe,

We aren't claiming that the effects described in the draft are new.
But they are relevant to IP.  Moreover, as other people have said, this
internet draft was motivated in response to recurring problems that
were noticed in other working groups.

After reviewing PILC, I find that there is not much overlap with our
draft.  Much of PILC could be understood as proposing techniques
suggested for improvement of upper layers, not explaining the
problems at the lower layers.  If people understand the kinds of
problems that may be encountered over wireless links, they are less
likely to make the mistakes that have caused problems up until now.
That's not to say anything negative about PILC -- it's a tremendous
document that was very rewarding to read again.  The lack of
broadcast capability described in PILC could be seen as the main
area of overlap with our document.

The word "subnet" does not appear in our document, and that is
intentional.  We were motivated to identify effects that really do
matter for multihop communications.  Yes, these effects are due to
the characteristics of wireless media below IP, and IP does not need
to change in order to operate properly.  But these effects do have an
impact on IP routing, and that was the main motivation for us to
develop the document.  I think the effects are far more subtle and
worthy of careful explanation compared to simply unplugging an
Ethernet.

In fact, we do not propose any techniques for dealing with the
problems.  Our intended scope is far, far narrower than the broad
scope of PILC.

Regards,
Charlie P.

On 1/19/2015 1:45 PM, Joe Touch wrote:
> +1
>
> A link layer that cannot reach all its members isn't a link layer - 
> it's multiple link layers that need interconnection.  That's what 
> routers are for.
>
> On Jan 19, 2015, at 1:00 PM, Templin, Fred L 
> <[email-masked] <mailto:[email-masked]>> wrote:
>

---

From: Joe Touch <[email-masked]>
Date: Thu, 22 Jan 2015 16:25:55 -0800

On 1/22/2015 2:30 PM, Charlie Perkins wrote:
> But they are relevant to IP.

I'm baffled as to how.

The doc starts off on the wrong foot by introducing a new term for 
reachability - "detects"? IP doesn't "detect" anything; it communicates 
between IP addresses. Either they're reachable or not. Reachability for 
L2 subnets is determined by ARP or an emulated equivalent.

And IP doesn't care whether L2 had to forward or store that message as 
part of that delivery. It simply is irrelevant to L3.

...
> draft.

If you're expecting the same kind of obscure terminology, there wouldn't be.

What you're describing is an unstable set of unidirectional L2 paths, 
and you want to call that an L2 network. It isn't.

I agree that PILC doesn't address unidirectional links, but most of IP 
doesn't either. Unidirectional links inhibit most Internet protocols.

So if that's where you're going, it'd help to explain what you hope to 
accomplish other than saying "don't try to use most Internet protocols 
here".

> worthy of careful explanation compared to simply unplugging an

That may be true, but so far all the doc succeeds in describing is a 
fundamentally broken L2 IMO. Whether that's what actually happens or 
not, it's not very useful to consider it a single anything.

> problems.  Our intended scope is far, far narrower than the broad

It would help if you would start by using existing terminology and 
explaining what you hope to achieve in this document - IN the draft itself.

Joe

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 23 Jan 2015 16:41:14 +0000

Hi Emmanuel,

From: [email-masked] [mailto:[email-masked]] On Behalf Of Emmanuel Baccelli
Sent: Thursday, January 22, 2015 1:54 PM
To: Templin, Fred L; Internet Area
Cc: Joe Touch; Carsten Bormann
Subject: RE: [Int-area] About draft-baccelli-manet-multihop-communication-04

Hi Fred

> is describing is a "multi-link" which is not a candidate for "IP-over-(foo)".

Nevertheless, people (MANET, ROLL, AUTOCONF, 6LOWPAN...) have been running IP over interfaces with connectivity as described in this draft. It's difficult and it yields specific protocol design decisions because of the unique characteristics of such connectivity, but it's doable.

I know a little bit about MANET and AUTOCONF. My understanding was that standard routing protocols like OLSR and OSPF-MANET are used to connect these kinds of links into multilink subnetworks (note I did NOT say “subnet”) and that IP can be run  by configuring an NBMA tunnel that sees the subnetwork as a fully connected link. IP then runs in the normal fashion over the NBMA tunnel. You can write an “IP-over-(foo)” document about a tunnel of that nature. But, this document cannot present itself as an “IP-over-(foo)” document.

Thanks - Fred

More people (6LO, CORE, LWIG...) want to design more protocols running over such networks. There is a risk that protocol design decisions that are made do not capitalize on available knowledge about the characteristics of such networks. Actually, the fact that we are having this argument right now shows that:

Best,

Emmanuel

> Thanks - Fred
>[email-masked]<mailto:[email-masked]>

---

From: Charlie Perkins <[email-masked]>
Date: Fri, 23 Jan 2015 11:25:44 -0800

Hello Joe,

>> But they are relevant to IP.

O.K...  it would be more accurate to say that the effects are
relevant to people interested in designing protocols that run
over IP.

> reachability - "detects"? IP doesn't "detect" anything; it 
> communicates between IP addresses. Either they're reachable or not. 
> Reachability for L2 subnets is determined by ARP or an emulated 
> equivalent.

Well, that term "reachable" is itself debatable, as discussed in the
document.  In fact the ambiguity surrounding "reachability" was a
motivating factor for writing the document.   We thought that "detect"
was a term easily understandable by the intended audience, and up
until now it seems that the document is pretty unambiguous using
that term.  The document does not suggest that IP "detects" packets.

> part of that delivery. It simply is irrelevant to L3.

Well, again, you are correct that my email ascribing "caring" and
"relevance" to IP was slightly inaccurate.

> If you're expecting the same kind of obscure terminology, there 

Many terms in common use have been found to be ambiguous, so
unambiguous terminology is then naturally less common.  But "obscure"?
Can you suggest some unambiguous terminology that would be preferable?

> and you want to call that an L2 network. It isn't.

We very definitely do *not* want to claim it is an L2 network.

> doesn't either. Unidirectional links inhibit most Internet protocols.

This is precisely our point.  For people that want to design Internet
protocols that work well, the effects in the draft have to be kept in mind.

> accomplish other than saying "don't try to use most Internet protocols 

We are trying to encourage better designs for Internet protocols,
and equally well to encourage improvements for existing protocols
to enable them to run over such (multihop) networks.

And, our message is not as quoted.  Instead, the message is "It is O.K.
to design Internet protocols here, but please keep these points in mind".

> explaining what you hope to achieve in this document - IN the draft 

That is exactly our goal.  I hope you can suggest ways that we can
do that.

Regards,
Charlie P.

---

From: Joe Touch <[email-masked]>
Date: Fri, 23 Jan 2015 11:44:15 -0800

Charlie,

...
> document.

It really isn't unless you're being anthropomorphic, and that's not useful.

Connectivity is all that matters, and it's either simplex or duplex, 
single-point or multipoint, etc.

> In fact the ambiguity surrounding "reachability" was a

Is there an effect you cannot state in terms of existing descriptions of 
L2 links?

i.e., simplex/duplex, single-point/multipoint?

Note that links* always exist, whether they're up or down; having links 
whose up/down state varies over time is already part of exstingn 
descriptions too.

*"link", to L3, means something that provides communication between two 
L2 endpoints. It has nothing to do with how many hops that takes at L2.

...
> unambiguous terminology is then naturally less common.  But "obscure"?

Anthropomorphic at best.

> Can you suggest some unambiguous terminology that would be preferable?

See above.

> We very definitely do *not* want to claim it is an L2 network.

Then what is it? A set of L2 networks? Those are interconnected by what 
L3 calls routers.

> protocols that work well, the effects in the draft have to be kept in mind.

What exactly would you do with an endpoint that was reachable only as an 
L3 destination?

Is that the only issue? Then what you're talking about is "how to model 
source-only or sink-only hosts in the Internet" - note I was able to say 
this without needing any reference to a L2.

However, I think those are a bit useless, from the standpoint of 
fundamental communications. Once there is loss, they become irrelevant 
because you don't know whether anything in either direction ever gets 
anywhere.

If you're talking about nodes that are sometimes connected in one 
direction then later connected in the other, that's just long-timescale 
changes to links that affect communication - there's a whole area of 
work addressing that (DTN).

> to enable them to run over such (multihop) networks.

Can you explain how your net is different from:

	a) source-only or sink-only nodes
	(which aren't relevant in a comm system)

	b) DTN

?

Joe

---

From: Charlie Perkins <[email-masked]>
Date: Fri, 23 Jan 2015 12:18:31 -0800

Hello Joe,

Follow-up inline...

> It really isn't unless you're being anthropomorphic, and that's not 

I'd like to hear from other people about this...

Nowhere in the draft is there an attempt to be anthropomorphic.
In particular, "detection" is often used without anthropomorphism.

> single-point or multipoint, etc.

The "etc." really matters.  Even the term "connectivity"
needs modifiers as you have noted.

> Is there an effect you cannot state in terms of existing descriptions 
> of L2 links?

The effects in the draft are stated in terms of existing descriptions
of L2 links.  I am not sure I get your point here.

>
> Note that links* always exist, whether they're up or down; having 
> links whose up/down state varies over time is already part of exstingn 
> descriptions too.
>
> *"link", to L3, means something that provides communication between 
> two L2 endpoints. It has nothing to do with how many hops that takes 
> at L2.

Check.

>> unambiguous terminology is then naturally less common.  But "obscure"?

Which terms are anthropomorphic?

> Then what is it? A set of L2 networks? Those are interconnected by 
> what L3 calls routers.

Well, in [manet] we are dealing with routers to establish multihop
connectivity between endpoints.  So, I am agreeing with your latter
sentence, but I would hesitate to call the nodes participating in
ad hoc networks to be "L2 networks" if each such "L2 network" only
has a single node...

>
> What exactly would you do with an endpoint that was reachable only as 
> an L3 destination?

That would be a strange endpoint.  Surely it would have
interfaces that would receive packets over layer 2...?

>
> Is that the only issue? Then what you're talking about is "how to 
> model source-only or sink-only hosts in the Internet" - note I was 
> able to say this without needing any reference to a L2.

That is not our message at all.  I don't think those terms appear
anywhere in the document, or in the discussions leading up to the
document in the other working groups.

> direction then later connected in the other, that's just 
> long-timescale changes to links that affect communication - there's a 
> whole area of work addressing that (DTN).

I was not aware of any DTN discussion about this.  Do you have
a pointer to a document?  We are not dealing with long-timescale
changes, in fact just the opposite.

>     (which aren't relevant in a comm system)

I am somewhat at a loss, but I will try.

First, the effects described are not restricted to "my" net.

For (a): as one example, ad hoc networks contain the kinds of
nodes that are described in the document.  Ad hoc networks *may*
also contain source-only or sink-only nodes, but that is not very
relevant to the discussion in the draft.

For (b): delay tolerance is not described in the draft.  You might
characterize some of the effects as "disruption", but I don't think
that would lead to proper understanding.

So, I feel I am missing your point, or else there is a need for a
longer discussion about ad hoc networks.  And yet, there are likely
other kinds of networks that would also benefit from understanding
the effects described in our draft.  This is not to say that the effects
are new.  Again, our experience motivates the need, and I believe
that that the draft properly documents effects that (even though
not new) are relevant to the design of Internet protocols.

Regards,
Charlie P.

---

From: Joe Touch <[email-masked]>
Date: Fri, 23 Jan 2015 12:54:39 -0800

Charlie,

Regarding anthropomorphisms to avoid, they include:

	detect
	reaches
	hears

The term you should be using is "can transfer an IP datagram to".

Regarding other things to consider before assuming this is a new problem:

	L2VPN

	DTN (which is more than about delay)
		if your delays/disruptions are brief enough,
		that's covered by existing dynamic routing

...
> connectivity between endpoints.

That's an L2VPN.

At the L2VPN layer, you're using L3 to transit L2 between disconnected 
islands of reachability. L2 frames between those islands are carried 
inside L3 packets that go over L2.

When you run IP over that, IP thinks it's a single L2 subnet.

---

(to repeat) In order to claim there's something worthwhile here, you 
need to explain how what you're doing hasn't already been addressed in 
existing RFCs.

Joe

---

From: Charlie Perkins <[email-masked]>
Date: Fri, 23 Jan 2015 13:17:14 -0800

Hello Joe,

> Regarding anthropomorphisms to avoid, they include:

Non-human devices do "detect" signals.  Many radios have
been built using "detectors",whatever. See:
http://en.wikipedia.org/wiki/Cat%27s-whisker_detector

>     hears

We use these as examples of terminology that has been used,
but we don't recommend them as an unambiguous terms.

> The term you should be using is "can transfer an IP datagram to".

Isn't that pretty verbose?  I'll see if I can work with it, thanks for the
suggestion...

> Regarding other things to consider before assuming this is a new problem:

We are definitely not dealing with VPNs.

>         that's covered by existing dynamic routing

Well, the dynamic routing protocols haven't been suitable
for ad hoc networks for various reasons.  That discussion
could fill volumes.  Much of the reason is because they do
not easily handle the problems outlined in the draft.  That's
a terribly long discussion.

> When you run IP over that, IP thinks it's a single L2 subnet.

We don't propose that an ad hoc network is a single L2 subnet,
and I'm pretty darned sure that L2VPN would not work for them.
Similarly for other networks as mentioned.  Have you looked at
ad hoc networks?  Please do, and see if you think L2VPN would work.

> need to explain how what you're doing hasn't already been addressed in 

I don't know of any RFCs that do describe these problems,
that's just the point.  Sorry if you feel this is repetitious...!
I am trying to be responsive to your discussion.

Regards,
Charlie P.

---

From: Joe Touch <[email-masked]>
Date: Fri, 23 Jan 2015 13:27:37 -0800

Charlie,

> Hello Joe,
..
> a terribly long discussion.

Yes - it can, and does, fill books, and it's not a useful point to try 
to summarize in an RFC.

> ad hoc networks?  Please do, and see if you think L2VPN would work.

I'm struggling to find out what you want to do other than make us all 
understand that what you want to do is really hard, that it makes IP 
hard, and that you haven't explained it yet.

Let's focus on the hidden receiver problem. So? It's reachable from some 
nodes but not others. If it's truly hidden to the point where it's only 
a sink, then that's what it is (and we've already discussed why this 
isn't the primary concern here).

If not, then other nodes can relay traffic to it. Yes, that's hard. Yes, 
that requires complicated routing. And yes, that's entirely a problem 
within a single L2 *IF* it can be solved there.

If it cannot, but that sort of bidirectional reachability can be solved 
using a L3 relay, then that's an L2VPN.

Is there a third case here? The only one left is a network that you 
can't fix inside L2 and can't be fixed with L3 relay. That's just 
"disconnected" and there's no need to fix it.

If you have a problem that isn't described above, it is you who need to 
describe it. The burden of proof is on you to explain what's new. The 
rest of us (broadly speaking) already know what's not.

Joe

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 24 Jan 2015 10:33:59 +1300

...
> Then what is it? A set of L2 networks? Those are interconnected by what L3 calls routers.

Not always. They are sometimes connected by what L2 calls bridges or
switches. In the case of 802.11 they might be connected by intermediate
wire L2 802.3 networks. The whole thing may then pretend to be a single
broadcast L2 segment but it isn't, and it doesn't perform like one.

There are many ramifications and some of them are clearer now than they
were during the PILC study.

    Brian

---

From: Joe Touch <[email-masked]>
Date: Fri, 23 Jan 2015 13:44:04 -0800

> broadcast L2 segment but it isn't, and it doesn't perform like one.

L3 considers all of these a single L2 network. L3 hasn't assumed that
all L2 nets are broadcast for a long time.

> were during the PILC study.

The main ramifications are:
	- deprecating subnet broadcast (RFC2644)
	- assuming that multicast needs IGMP snooping at L2 (RFC4541)

One was known before PILC, one shortly after.

Yes, there's been a lot of work in this area since then too - L2VPNs,
TRILL, and many others.

Again, what's new?

Explaining "hidden terminal" isn't useful; we have RFC3753 (and many
textbooks) for that.

Clearly and specifically highlighting that would be useful, but I
haven't seen that yet.

Joe

---

From: Charlie Perkins <[email-masked]>
Date: Fri, 23 Jan 2015 13:54:02 -0800

Hello Joe,

Follow-up below...

> Yes - it can, and does, fill books, and it's not a useful point to try 

Of course we are not trying to summarize why older protocols
don't easily work in the environment where nodes exhibit the
effects described in the draft.  We are simply trying to point out
that the effects do matter, and are worthy of consideration when
designing IP protocols.

> hard, and that you haven't explained it yet.

IP does work over these node populations (I have to be careful
not to use "network" in that clause if it might be misinterpreted
as in earlier emails).  The result of IP working over such a population
of nodes is an IP network.  We don't way it's hard, we say you have
to be careful.

>
> Let's focus on the hidden receiver problem. So? It's reachable from 
> some nodes but not others. If it's truly hidden to the point where 
> it's only a sink, then that's what it is (and we've already discussed 
> why this isn't the primary concern here).

Check.

>
> If not, then other nodes can relay traffic to it. Yes, that's hard. 
> Yes, that requires complicated routing. And yes, that's entirely a 
> problem within a single L2 *IF* it can be solved there.

In context, I am not quite sure what you mean by "a single L2". Regarding
sink nodes, the main problem is that by definition they can't provide much
protocol signaling with other nodes.  Somehow that doesn't seem relevant
here, though...

>
> If it cannot, but that sort of bidirectional reachability can be 
> solved using a L3 relay, then that's an L2VPN.

Well, I don't recall very much fixation on sink nodes in ad hoc networks
even though they could certainly exist.  And, I really doubt that L2VPN
would work for ad hoc networks or other cases involving nodes exhibiting
the effects described in the draft.

> "disconnected" and there's no need to fix it.

We are not offering fixes.  We are offering a description of some common
effects in wireless multihop networks which matter when designing protocols.

>
> If you have a problem that isn't described above, it is you who need 
> to describe it. The burden of proof is on you to explain what's new.

What's new is collecting together these important matters
into a document that can be helpful.  The lack of such a document
motivated the writing of the draft under discussion.  Our indication
that it was needed came from experience in other working groups.

> The rest of us (broadly speaking) already know what's not.

It seems to me that proposing L2VPN as a solution for ad hoc
networks (and probably other examples) is an example to show
that the document is needed.  But maybe L2VPN has evolved
beyond VPN use cases.  I'll have to check.  Besides that, there are
other people who have encouraged us to produce this document,
and so I infer that some people see the need.

Regards,
Charlie P.

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 26 Jan 2015 13:38:58 +0100

> http://en.wikipedia.org/wiki/Cat%27s-whisker_detector

In that sense, "detect" is a PHY operation.

In WiFi MAC terms we'd say "create a non-empty list by a scan 
operation", or otherwise "receive Beacon, or Association Reply".

There is no WiFi operation called "detect", other than maybe some GUI, 
but just some.  It is not a widespread term.

> but we don't recommend them as an unambiguous terms.

I think we could be more specific about these terms, and not use 
'reaches' nor 'hears' because they mean different things to different 
people.

Maybe we could use the WiFi terms used in standards, or the names of CLI 
widely used tools, or their parameters.

Alex

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 26 Jan 2015 13:33:02 +0000

Joe Touch

> The term you should be using is "can transfer an IP datagram to".

Not the same. If A can hear/detect B, that does not tell you that you can transfer an IP datagram to. Opposite directions. See for example NHDP (RFC 6130), which uses one of those terms.

Joe Touch
> Charles Perkins

> That's an L2VPN.

A MANET is definitely not an L2VPN.

********************************************************************
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: Joe Touch <[email-masked]>
Date: Mon, 26 Jan 2015 07:55:13 -0800

On 1/26/2015 5:33 AM, Dearlove, Christopher (UK) wrote:
> Not the same. If A can hear/detect B, that does not tell you that you
> can transfer an IP datagram to. Opposite directions.

OK, to be more precise, "can receive an IP datagram from"

> See for
> exampleNHDP (RFC 6130), which uses one of those terms.

That doc is defining a routing protocol. You're trying to define a L2 
network, AFAICT.

In the case of NHDP, "HEARS" is a routing protocol event when an IP 
packet is received. See section 10.1.1 which explains that HELLO 
messages occur in IP datagraph. Take that description and use it to 
understand the meaning of HEARS, LINK, and SYMMETRIC LINK and you will 
end up with the definitions I gave - despite the fact that 
unidirectional link and bidirectional link are the common terms for what 
that document redefines.

Note also that, strictly interpreted, NHDP creates a topology that might 
never forward data packets. HEARS is defined in terms of receiving a 
specific kind of IP datagram, rather than IP datagrams in general.

IMO, that's not useful. Even though that doc describes a routing 
protocol, it could - and should - have used widely-used terms for it's 
particulars.

> A MANET is definitely not an L2VPN.

Agreed. MANETs don't need L3 devices for internal transit. If you don't 
either, then why are you not just a MANET?

Joe

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 26 Jan 2015 16:04:45 +0000

Joe Touch

> OK, to be more precise, "can receive an IP datagram from"

Even that may be saying too much, that may be a necessary but not sufficient condition for routing.

> That doc is defining a routing protocol. You're trying to define a L2 

I'm not sure of the context of the latter sentence above, but it is not so in any context I can see. The whole point of RFC 6130 (and RFC 7181) is to be L2 agnostic, and even able to run over a heterogeneous collection of L2 links.

> unidirectional link and bidirectional link are the common terms for what 

I actually understand that RFC quite well.

> specific kind of IP datagram, rather than IP datagrams in general.

Precisely. That's why hears is not the same as can receive an IP datagram from.

> protocol, it could - and should - have used widely-used terms for it's 

I'm not sure what you are saying is not useful. Assuming you just mean the terminology, the terms had prior art in the MANET community. RFC 3626 for a start.

---

From: Joe Touch <[email-masked]>
Date: Mon, 26 Jan 2015 08:15:15 -0800

On 1/26/2015 8:04 AM, Dearlove, Christopher (UK) wrote:
>>>> Regarding anthropomorphisms to avoid, they include: detect
>>>> reaches hears
>>>
>>> Not the same. If A can hear/detect B, that does not tell you that
>>> you can transfer an IP datagram to. Opposite directions.
>

It's a necessary and sufficient condition to define a unidirectional
link capable of being used by IP as L3.

Routing is the transitive closure of unidirectional reachability.

>>> See for exampleNHDP (RFC 6130), which uses one of those terms.
>
>> That doc is defining a routing protocol. You're trying to define a
>> L2 network, AFAICT.
>
> I'm not sure of the context of the latter sentence above, but it is
> not so in any context I can see. The whole point of RFC 6130 (and RFC
> 7181) is to be L2 agnostic, and even able to run over a heterogeneous
> collection of L2 links.

Routing protocols that run over IP (as RFC6130 does) are L2 agnostic, 
yes. Thus that doc is defining (more specifically) a L3 routing protocol.

>> In the case of NHDP, "HEARS" is a routing protocol event when an
>> IP packet is received. See section 10.1.1 which explains that
>> HELLO messages occur in IP datagraph. Take that description and use
>> it to understand the meaning of HEARS, LINK, and SYMMETRIC LINK and
>> you will end up with the definitions I gave - despite the fact
>> that unidirectional link and bidirectional link are the common
>> terms for what that document redefines.
>
>> Note also that, strictly interpreted, NHDP creates a topology that
>> might never forward data packets. HEARS is defined in terms of
>> receiving a specific kind of IP datagram, rather than IP datagrams
>> in general.
>

Well, in *that* RFC, if you can't hear an IP datagram, you can't get a 
HELLO, so you don't HEAR any endpoints.

Yes, there could be an odd situation where IP HELLO datagrams can 
transit a link where other IP datagrams cannot, but in that case RFC6130 
would determine forwarding entries that wouldn't do much good.

That RFC does imply that control message reachability implies IP 
reachability.

Yes, you could have an L2 where that's not the case - where L2 
reachability is determined by a mechanism that doesn't transfer an IP 
datagram. But L3 doesn't care HOW that information is obtained; all it 
cares about is what is L3-reachable.

>> protocol, it could - and should - have used widely-used terms for
>> it's particulars.
>
> I'm not sure what you are saying is not useful. Assuming you just
> mean the terminology, the terms had prior art in the MANET community.
> RFC 3626 for a start.

The MANET community didn't create networking; it existed for decades 
before they got started. The fact that they redefined well-known terms 
from a community with decades of history isn't helpful to either them or 
those they're trying to communicate with.

If you want to repeat that mistake, please take your work to the MANET WG.

Joe

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 26 Jan 2015 16:41:42 +0000

Joe Touch
> Routing is the transitive closure of unidirectional reachability.

You need known and usable unidirectional reachability. If A can reach B, but A has no idea of that, then that's not usable for routing.

> would determine forwarding entries that wouldn't do much good.

(That is in fact a real problem when using IEEE 802.11 as your L2, but that's not the point here.)

And there's another issue that happens in RFC 6130 and ad hoc routing protocols. You don't know who can hear you until they let you know. You find them using local broadcast.

> That RFC does imply that control message reachability implies IP 

Not until you've confirmed a return path, so, no to the above.

---

From: Joe Touch <[email-masked]>
Date: Mon, 26 Jan 2015 08:56:18 -0800

On 1/26/2015 8:41 AM, Dearlove, Christopher (UK) wrote:
> You need known and usable unidirectional reachability. If A can reach
> B, but A has no idea of that, then that's not usable for routing.

That's also known. Unidirectional links have been part of routing for a 
very long time.

> (That is in fact a real problem when using IEEE 802.11 as your L2, but that's not the point here.)

802.11 has a problem when *L2* reachability signals don't translate to 
L3 reachability. RFC6130 gets around that by using control messages that 
are sent inside L3.

Unless you have some sort of filter in place, if HELLO in IP gets there 
then IP gets there.

> And there's another issue that happens in RFC 6130 and ad hoc
> routingprotocols. You don't know who can hear you until they let you know.

Some routing protocols assume bidirectional communication, i.e., if you 
can send an IP datagram to me then I can send one to you. But that's 
only a subset of routing protocols; routing protocols that support 
unidirectional links have also been around for a long time.

 > You find them using local broadcast.

The PILC doc explains why this is a bad idea unless L2 is known to 
support broadcast. The L2 you're describing fails that assumption.

> Not until you've confirmed a return path, so, no to the above.

The RFC implies that control reachability implies IP reachability.

It does not imply that unidirectional reachability implies bidirectional 
reachability. When B receives a HELLO from A, then B knows it can get IP 
datagrams from A (that's a leap that the doc makes because it HELLOs are 
sent inside IP datagrams).

No, local reachability information does not magically imply global 
reachability information; that's what a routing protocol determines and 
exchanges.

-----

It might help us understand what you want to do if you just say it:

	A- are you trying to describe an L2?

	B- are you trying to describe a L2 routing protocol?

	C- are you trying to describe an L3 routing protocol?

Please pick *one* and start there. If you want to do (B) for an (A) that 
hasn't been described, then start with (A).

Again, I still have not seen anything yet that's new.

Also, please do this in an update to your draft. You're asking us to do 
your work at this point.

Joe

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 26 Jan 2015 17:17:23 +0000

Joe Touch
> L3 reachability. RFC6130 gets around that by using control messages that 

Actually that's not the whole story for IEEE 802.11.

> Unless you have some sort of filter in place, if HELLO in IP gets there 

Nor is that. If you care (but this is an aside from the point here) I'd Google about the 802.11 "grey zone" problem.

But in the general case, ignore that.

> unidirectional links have also been around for a long time.

In a MANET, they are definitely not the easiest things to do with any degree of reliability.

Joe Touch

> support broadcast. The L2 you're describing fails that assumption.

Which L2 I'm describing? I haven't described an L2. (I made an aside about 802.11, which actually does support local broadcast, so you can't mean that.)

> The RFC implies that control reachability implies IP reachability.

No, it really doesn't for routing purposes (e.g. RFC 7181 - RFC 6130 is not itself a routing protocol). Because A can locally broadcast and it reaches B, who A may not even know exists, does not make a unicast link A to B useful.

> sent inside IP datagrams).

It knows it can get locally broadcast IP datagrams from A. Not sufficient.

> It might help us understand what you want to do if you just say it:

You realise I'm not an author of the current document? I'm just pointing out you're missing things when you're attempting to say "nothing new here, all completely understood". We have experience that's not so.

---

From: Joe Touch <[email-masked]>
Date: Mon, 26 Jan 2015 10:31:12 -0800

> Actually that's not the whole story for IEEE 802.11.

Let me be more clear.

The whole story for IP (L3) is:

	(A)- an L2 subnet is *defined* as a L2 network in which
	every endpoint can reach every other one
	(directly or indirectly)

	(B)- any group of L2 nodes that does not have property (A)
	is a set of one or more L2 subnets.

	(C) - Those subnets can be internetworked using L3 (routers)
	ONLY where they overlap (i.e., share a node).

> But in the general case, ignore that.

Agreed; that problem is one where the routing protocol doesn't 
fate-share the regular IP datagram path, and that's also a well-known 
problem.

> In a MANET, they are definitely not the easiest things to do with any degree of reliability.

Routing protocols don't need reliable links. The reliability of E2E 
paths does depend on a variety of properties, and certainly maintaining 
E2E reliability with wildly fluctuating links is a problem, but it is 
addressed by using a different routing protocol (at best).

> Which L2 I'm describing? I haven't described an L2. (I made an aside
> about 802.11, which actually does support local broadcast, so you can't
> mean that.)

(I should have said "the L2 described in the draft")

> No, it really doesn't for routing purposes (e.g. RFC 7181 - RFC 6130
> is not itself a routing protocol).

It does as described in RFC6130. That doc makes no mention of the 802.11 
gray zone issue of using a different encoding.

Again, it's well-understood that routing protocols need to fate-share 
reachability of IP data packets. That's the assumption behind the 
section I cited (HELLOs go in IP packets; if the HELLO gets there, an IP 
packet got there).

 > Because A can locally broadcast and
> it reaches B, who A may not even know exists, does not make a unicast
> link A to B useful.

I said "The RFC implies that control reachability implies IP 
reachability." I didn't say that resulted in bidirectional reachability 
- that's for a routing protocol to determine based on unicast discovery.

(though RFC6130 isn't quite a full routing protocol; it's just the 
discovery portion)

> It knows it can get locally broadcast IP datagrams from A. Not sufficient.

Agreed - 6130 isn't a full routing protocol; the full protocol is 
required to take the *unidirectional* reachability of 6130 and determine 
bidirectional reachability.
> You realise I'm not an author of the current document?  I'm just
> pointing out you're missing things when you're attempting to say
> "nothing new here, all completely understood". We have experience that's
> not so.

So far, "your" experience (you, the authors, the MANET community) keeps 
asserting that there's something magic about that environment that the 
Internet architecture and protocols haven't considered.

That has still not proven to be the case.

Joe

---

From: Charlie Perkins <[email-masked]>
Date: Mon, 26 Jan 2015 13:52:12 -0800

Hello Joe,

Follow-up below:

On 1/26/2015 10:31 AM, Joe Touch wrote:
> .....

This isn't true for routers that route over links that are not
part of a subnet.

......................

> So far, "your" experience (you, the authors, the MANET community) 
> keeps asserting that there's something magic about that environment 
> that the Internet architecture and protocols haven't considered.

It's not magic.  That's the point.  And we don't say that the problems
have never been considered.  From earlier email:

>      ...        We are simply trying to point out

Regards,
Charlie P.

---

From: Joe Touch <[email-masked]>
Date: Mon, 26 Jan 2015 14:03:08 -0800

> This isn't true for routers that route over links that are not

That link acts like it's own 2-node L2 subnet that thus overlaps with
the two subnets it bridges on each side.

I didn't say all the subnets need to be composed of the same technology.

I'd be glad to see a new version of the ID that accomplishes this. There
have been no points raised in email so far that accomplish this, though.

Joe

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 26 Jan 2015 22:05:33 +0000

Hi Charlie,

> From: Int-area [mailto:[email-masked]] On Behalf Of Charlie Perkins
> Sent: Monday, January 26, 2015 1:52 PM
> To: Joe Touch; Dearlove, Christopher (UK)
> Cc: [email-masked]

I think what you have is a (possibly) dynamically changing collection of links that
are stitched together by routers, right? I use the term "subnetwork" to describe
that (which is intentionally distinct from "subnet"), since subnetwork does
not imply a multilink subnet.

Thanks - Fred

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 27 Jan 2015 15:52:53 +0100

Le 26/01/2015 19:31, Joe Touch a écrit :
>> Nor is that. If you care (but this is an aside from the point here)
>> I'd Google about the 802.11 "grey zone" problem.
>>

Maybe we should document what is fate-sharing with routing protocols 
(ref.) and tell how MANET routing protocols don't really do fate-sharing 
when applied in a WiFi ad-hoc mode network.

> addressed by using a different routing protocol (at best).

I agree routing protocols dont need reliable links.  When a link flaps a 
routing protocol declares it as off.

There are some gray zones in which links are characterized by their 
bandwidth instead of on/off (OSPF).  But there are no metrics which 
characterize wifi links as this draft characterizes them.

E.g. a metric 'link ends kind' could value 1 if both its ends where 
hidden terminals, 0 otherwise.

> Internet architecture and protocols haven't considered.

I work in these environments.  I know they are different than wired, 
even though maybe not magic.

The problem with MANET routing protocols is that they try to accommodate 
all possible kinds of networks made of wireless links, with purely 
arbitrary mouvement patterns.

Whereas most wireless links are designed with particular topologies and 
use-cases in mind.  There's not a single 'universal' wireless link. 
Some apps are possible on some links and other apps on other links.

That said, I still think a draft about the peculiar behaviour of WiFi, 
especially in ad-hoc mode, is worth documenting, because it has 
implications on other protocols.

Of course its contents and potential recommendation should be agreed on.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 27 Jan 2015 16:02:58 +0100

Le 27/01/2015 15:52, Alexandru Petrescu a écrit :
>>>> 802.11 has a problem when *L2* reachability signals don't
>>>> translate to L3 reachability. RFC6130 gets around that by using
>>>> control messages that are sent inside L3.
>>>
>> (A)- an L2 subnet is *defined* as a L2 network in which every
>> endpoint can reach every other one (directly or indirectly)
>>
>> (B)- any group of L2 nodes that does not have property (A) is a set
>> of one or more L2 subnets.
>>
>> (C) - Those subnets can be internetworked using L3 (routers) ONLY
>> where they overlap (i.e., share a node).
>>
>>>> Unless you have some sort of filter in place, if HELLO in IP
>>>> gets there then IP gets there.
>>>
>>> Nor is that. If you care (but this is an aside from the point
>>> here) I'd Google about the 802.11 "grey zone" problem.
>>>
>> fate-share the regular IP datagram path, and that's also a
>> well-known problem.
>
>  (ref.) and tell how MANET routing protocols don't really do
> fate-sharing when applied in a WiFi ad-hoc mode network.
>
>>>> Some routing protocols assume bidirectional communication,
>>>> i.e., if you can send an IP datagram to me then I can send one
>>>> to you. But that's only a subset of routing protocols; routing
>>>> protocols that support unidirectional links have also been
>>>> around for a long time.
>>>
>> Routing protocols don't need reliable links. The reliability of
>> E2E paths does depend on a variety of properties, and certainly
>> maintaining E2E reliability with wildly fluctuating links is a
>> problem, but it is addressed by using a different routing protocol
>> (at best).
>
> I agree routing protocols dont need reliable links.  When a link
> flaps a routing protocol declares it as off.
>
>>>> The PILC doc explains why this is a bad idea unless L2 is known
>>>> to support broadcast. The L2 you're describing fails that
>>>> assumption.
>>>
>>> Which L2 I'm describing? I haven't described an L2. (I made an
>>> aside about 802.11, which actually does support local broadcast,
>>> so you can't mean that.)
>>
>>> No, it really doesn't for routing purposes (e.g. RFC 7181 - RFC
>>> 6130 is not itself a routing protocol).
>>
>> It does as described in RFC6130. That doc makes no mention of the
>> 802.11 gray zone issue of using a different encoding.
>>
>> Again, it's well-understood that routing protocols need to
>> fate-share reachability of IP data packets. That's the assumption
>> behind the section I cited (HELLOs go in IP packets; if the HELLO
>> gets there, an IP packet got there).
>>
>>> Because A can locally broadcast and it reaches B, who A may not
>>> even know exists, does not make a unicast link A to B useful.
>>
>> reachability." I didn't say that resulted in bidirectional
>> reachability - that's for a routing protocol to determine based on
>> unicast discovery.
>>
>>>> It does not imply that unidirectional reachability implies
>>>> bidirectional reachability. When B receives a HELLO from A,
>>>> then B knows it can get IP datagrams from A (that's a leap that
>>>> the doc makes because it HELLOs are sent inside IP datagrams).
>>>
>> required to take the *unidirectional* reachability of 6130 and
>> determine bidirectional reachability.
>>>
>>> "nothing new here, all completely understood". We have experience
>>> that's not so.
>>
> The problem with MANET routing protocols is that they try to
> accommodate all possible kinds of networks made of wireless links,
> with purely arbitrary mouvement patterns.
>
> Whereas most wireless links are designed with particular topologies
> and use-cases in mind.  There's not a single 'universal' wireless
> link. Some apps are possible on some links and other apps on other
> links.
>
> That said, I still think a draft about the peculiar behaviour of
> WiFi, especially in ad-hoc mode, is worth documenting, because it has

Addition: new wifi links on the market since this draft was 
experimented, show other new behaviours unkown until now to wired 
counterparts.

For example, 802.11ac not only offers more bandwidth, but comes by 
default with 2 ready to use independent channels, as two independent 
links on 2.4 and 5.x bands.

This is like if each Ethernet cable were actually made of two 
independent cables.  You'd need to stitch both their ends together by 
some software to use the available bandwidth.

Hidden terminal problem may exhibit on one channel but not on the other, 
whereas in WiFi it was present on all channels.

Also, 802.11p links have particularities because they dont feature 
'cells', do not use scanning.

Alex

>> list [email-masked]
> list [email-masked]

---

From: Joe Touch <[email-masked]>
Date: Tue, 27 Jan 2015 07:41:16 -0800

On 1/27/2015 7:02 AM, Alexandru Petrescu wrote:
...
> some software to use the available bandwidth.

If only there were an existing link model for this.

Oh, right - there is. It is called channel bonding.

I'm not saying that MANETs operate using wired-link assumptions, but 
rather that wireless links - and everything that encompasses - have been 
part of the Internet architecture for decades.

It's far too early to discuss whether this doc could *become* a useful 
WG doc; in it's current form, there's simply no hint of that yet. IMO, 
the authors should take another shot at it, and then we can see if 
there's really anything useful to pursue here. The current doc does NOT 
make that case yet.

Joe

---

From: Emmanuel Baccelli <[email-masked]>
Date: Tue, 27 Jan 2015 17:45:38 +0100

Hi Joe

On Tue, Jan 27, 2015 at 4:41 PM, Joe Touch <[email-masked]> wrote:

>
>
> It's far too early to discuss whether this doc could *become* a useful WG
> doc; in it's current form, there's simply no hint of that yet. IMO, the
> authors should take another shot at it, and then we can see if there's
> really anything useful to pursue here. The current doc does NOT make that
> case yet.
>
>
>
>

Can you be more specific? Apparently there is some misunderstanding. There
are two parts in this discussion. One part is polemic, another part is
non-polemic:

(1) the non-polemic part is about the *physical connectivity* that is
experienced on networks tackled by MANET, ROLL, 6Lo and a slew of other
working groups in this domain. This physical connectivity is pretty well
described in the draft, and I think it should be easy to get consensus on
that, with minimal changes.

(2) the polemic part is about what link model / architecture /solution
applies best to such physical connectivity. This discussion, as well as
previous discussions in AUTOCONF, show that it is not trivial to agree on
something.

However: the chances of agreeing on a solution for (2) are significantly
lower if (1) has not concluded with a clear documentation of the *beast* to
be tamed.

This is why a document such as the draft discussed -- which addresses only
the *non-polemic* part of the discussion -- would be useful.
Do you disagree with the above? If so, why? This is unclear.

Best,

Emmanuel

---

From: Joe Touch <[email-masked]>
Date: Tue, 27 Jan 2015 09:06:26 -0800

On 1/27/2015 8:45 AM, Emmanuel Baccelli wrote:
> Hi Joe
>
> On Tue, Jan 27, 2015 at 4:41 PM, Joe Touch <[email-masked]
>     It's far too early to discuss whether this doc could *become* a
>     useful WG doc; in it's current form, there's simply no hint of that
>     yet. IMO, the authors should take another shot at it, and then we
>     can see if there's really anything useful to pursue here. The
>     current doc does NOT make that case yet.
>
> Can you be more specific?

I've tried. If what I've said so far isn't sufficient, then the draft 
needs substantial revision and we'll see from there.

Again, the onus is on the draft to be clear.

> Apparently there is some misunderstanding.
> There are two parts in this discussion. One part is polemic, another
> part is non-polemic:
>
> described in the draft, and I think it should be easy to get consensus
> on that, with minimal changes.

I disagree, and have already explained why that's not true in detail.

> previous discussions in AUTOCONF, show that it is not trivial to agree
> on something.

If this is just about describing a physical layer, IMO it's not relevant 
to the IETF. The implications on L3 and above need to be part of this 
doc, otherwise there's no point in discussing it here.

> lower if (1) has not concluded with a clear documentation of the *beast*
> to be tamed.
>
> This is why a document such as the draft discussed -- which addresses
> only the *non-polemic* part of the discussion -- would be useful.

The current doc is essentially vacuous regarding new information on 
wireless subnets. We all already know they are composed of links that 
vary highly and that the links can be unidirectional.

Please tell us something we haven't known and dealt with for decades.

Joe

---

From: Emmanuel Baccelli <[email-masked]>
Date: Tue, 27 Jan 2015 19:10:23 +0100

Hi Joe

> Again, the onus is on the draft to be clear.

The draft is rather clear, but you are arguing that it is unuseful because
it should include architectural considerations. Others say it is useful
without architectural considerations.

This is not necessarily a conflict. Why not have architectural
considerations in another, subsequent draft?

> The current doc is essentially vacuous regarding new information on
wireless subnets. We all already know they are composed of links that vary
highly and that the links can be unidirectional.
> Please tell us something we haven't known and dealt with for decades.

If everything is common knowledge since ages, why don't we have an obvious
ref to point to, with a link model people agree on?

Best,

Emmanuel

---

From: Joe Touch <[email-masked]>
Date: Tue, 27 Jan 2015 10:28:13 -0800

On 1/27/2015 10:10 AM, Emmanuel Baccelli wrote:
> Hi Joe
> 
> Le 27 janv. 2015 18:08, "Joe Touch" <[email-masked]
> <mailto:[email-masked]>> a écrit :
>>
>>
>>
> <mailto:[email-masked]>
>>> <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>>>
>>>
>>>
> The draft is rather clear,

Clearness is determined by the reader, and as a reader I've already
indicated how and why that is not true.

> but you are arguing that it is unuseful
> because it should include architectural considerations. Others say it is
> useful without architectural considerations.
> 

This draft is - at best - setup to an arch considerations doc. It's a
preface, an intro - maybe just a definitions section.

There's no point to it without the arch part.

...
> If everything is common knowledge since ages, why don't we have an
> obvious ref to point to, with a link model people agree on?

We do (PILC and some of the other docs already cited). You claim that
it's insufficient, so again the onus is on you to *prove* that's true.

Joe

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 27 Jan 2015 18:40:56 +0000

Hi,

> obvious ref to point to, with a link model people agree on?

Here is another reference:

"Multi-Link Subnet Issues"
http://www.rfc-editor.org/rfc/rfc4903.txt

What 'draft-baccelli' is describing is a multi-link *subnetwork*, and must not
be leveraged into facilitating a multi-link *subnet*. 

Thanks - Fred

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 27 Jan 2015 19:52:55 +0100

> be leveraged into facilitating a multi-link *subnet*. 

That cat is out of the bag.
(Or, in IETF language, RFC 4903 section 4 is OBE.
That was an informational document anyway, for good reasons.)

Grüße, Carsten

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 27 Jan 2015 19:25:54 +0000

Hi,

> From: Carsten Bormann [mailto:[email-masked]]
> Sent: Tuesday, January 27, 2015 10:53 AM
> To: Templin, Fred L; Emmanuel Baccelli; Joe Touch; Internet Area

It is a document of the Internet Architecture Board, and not obsoleted or
deprecated by any other works I am aware of. It says:

   "A multi-link subnet model should be avoided.  IETF working groups
   using, or considering using, multi-link subnets today should
   investigate moving to one of the other models."

Thanks - Fred

---

From: Emmanuel Baccelli <[email-masked]>
Date: Tue, 27 Jan 2015 20:49:03 +0100

Hi Joe

> preface, an intro - maybe just a definitions section.

Glad to see you finally recognize some informational value to the draft ;)
And by the way: the draft is not going for experimental or standards track,
but for informational.

> it's insufficient, so again the onus is on you to *prove* that's true.

I'm not talking about 100 references that kind of fit, but not really,
because people don't agree on a link model (as shown by this discussion so
far).

I understand your point of view about wanting to bundle both informational
and architectural aspects in the document.

However, I have a different experience: in AUTOCONF we tried to do exactly
that (i.e. bundle both informational and architectural aspects in the
document), but never converged, partly because we did not have such an
informational document to refer to -- to keep the discussion "grounded". I
say: let's not make the same mistake twice. Let's first agree on how to
describe what we observed, then publish a document on that. Until then,
experience shows we are not ready to debate on applicable architectures.

Best,
Emmanuel

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 27 Jan 2015 21:36:07 +0100

>    investigate moving to one of the other models."

Sure.  We knew about the problems and did investigate whether there were
other models.  RFC 4903 was good advice, indeed.  But, in the end,
divorcing the ephemeral link concept from the more permanent subnet was
the right way to run constrained node networks.

You will notice that many arguments in RFC 4903 are about limits of ND
classic.  So we fixed up ND for our purposes in RFC 6775.  (Some of that
may still flow back to "big" networks in the form of Efficient ND.)

The other thing that we threw overboard was the fiction that you can
have multicast working in every subnet, at the same low expense of a
simple unicast packet.  We gave up on that and now have MPL
(draft-ietf-roll-trickle-mcast) as a (decidedly expensive) alternative,
with some changes in the service model.  (We may still get some more
traditional IP multicast back by using variants of the BIER model, see
e.g., draft-bergmann-bier-ccast.  But the parity of multicast with
unicast is not going to be restored.)

In summary, there were some changes, and some compromises, in the
architecture.  Still, the result is much more livable than the classic
MANET model combined with the Mobile-IP model.

Grüße, Carsten

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 27 Jan 2015 20:44:51 +0000

Hi Carsten,

> Sent: Tuesday, January 27, 2015 12:36 PM

What was done for RFC6775 does not need to spill over to the core Internet
architecture. RFC4903 says that "A multi-link subnet model *should* be
avoided". Because there is one (or maybe a few) instance where it was
unavoidable does not mean that the applicability should be spread widely.

Thanks - Fred

---

From: Joe Touch <[email-masked]>
Date: Tue, 27 Jan 2015 13:22:41 -0800

...
> I understand your point of view about wanting to bundle both
> informational and architectural aspects in the document.
>
> However, I have a different experience: in AUTOCONF we tried to do
> exactly that (i.e. bundle both informational and architectural aspects
> in the document), but never converged, partly because we did not have
> such an informational document to refer to -- to keep the discussion
> "grounded". I say: let's not make the same mistake twice. Let's first
> agree on how to describe what we observed, then publish a document on
> that. Until then, experience shows we are not ready to debate on
> applicable architectures.

Architecture can still be informational.

Regardless, though, it sounds like this is a repeat of AUTOCONF even if 
you split the docs. If you can't present these issues in existing terms 
OR explain clearly and convincingly why new terms are needed, you won't 
ground the discussion here either.

Whether these are one doc or two won't save you from that fate.

Joe

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 28 Jan 2015 16:28:19 +0100

Le 27/01/2015 18:06, Joe Touch a écrit :
>> useful WG doc; in it's current form, there's simply no hint of
>> that yet. IMO, the authors should take another shot at it, and then
>> we can see if there's really anything useful to pursue here. The
>> Apparently there is some misunderstanding. There are two parts in
>> this discussion. One part is polemic, another part is non-polemic:
>>
>> (1) the non-polemic part is about the *physical connectivity* that
>>  is experienced on networks tackled by MANET, ROLL, 6Lo and a slew
>>  of other working groups in this domain. This physical connectivity
>>  is pretty well described in the draft, and I think it should be
>> easy to get consensus on that, with minimal changes.
>
>> (2) the polemic part is about what link model / architecture
>> /solution applies best to such physical connectivity. This
>> discussion, as well as previous discussions in AUTOCONF, show that
>>  it is not trivial to agree on something.
>
> If this is just about describing a physical layer, IMO it's not
> relevant to the IETF. The implications on L3 and above need to be
> part of this doc, otherwise there's no point in discussing it here.
>
>> However: the chances of agreeing on a solution for (2) are
>> significantly lower if (1) has not concluded with a clear
>> documentation of the *beast* to be tamed.
>>
>> This is why a document such as the draft discussed -- which
>> addresses only the *non-polemic* part of the discussion -- would be
>> useful. Do you disagree with the above? If so, why? This is
>> unclear.
>

Hi Joe,

I tend to agree with this invitation.

To further support it I would like to point to "Issues in Packet Radio
Network Design", Proceedings of the IEEE, January 1987.  I can read this
paper because my employer has an institutional subscription.

The paper tells at some point:
> The problem of collisions caused by hidden nodes can be alleviated by
> the use of a busy tone which is transmitted by a node on a separate
> channel to indicate that it is currently receiving a packet.

That is a recommendation for alleviating hidden terminal problems.

IEEE 802.11 also offers methods to alleviate for the hidden terminal
problems (request to send/clear to send).

If this draft were to describe the hidden terminal problem, and suggest
that the IP networking layer should not be used to solve it, would it be
a satisfactory approach?  (instead of saying "may affect the IP layer",
as it currently does).

Another problem described in this draft is the following:
> There may be no indication to the IP layer when a previously
> established communication channel becomes unusable; "link down"
> triggers are generally absent in multi-hop ad hoc wireless networks,
>  since the absence of detectable radio energy (e.g., in carrier
> waves) may simply indicate that neighboring devices are not currently
> transmitting.  Such an absence of detectable radio energy does not
> therefore indicate whether or not transmissions have failed to reach
> the intended destination.

This describes a problem.  If the solution to it were a link-layer
solution, would you agree with the problem per se?

The paper that I cite above gives a solution to that problem, at the
link layer:
> Radio connectivity must be determnined by the two ends of the radio
> link (i.e. the two packet radio units which are connected).  The
> information from each node can be collectd at a central location
> where connectivity is then detemrined, or it can be determined by
> the nodes themselves through a cooperative mechanism, such as
> exchange of the number of transmitted and receveived packets.  [...]
> One set of methodes that can be used to detemrine the existence of a
> link is to directly use measurements made on the radio channel.
> These can include such measurements as signal strength,
> signal-to-noise ratio and bit-error rate.

Alex

---

From: Joe Touch <[email-masked]>
Date: Wed, 28 Jan 2015 10:37:30 -0800

...
> a satisfactory approach?  (instead of saying "may affect the IP layer",

IP should never be used to solve link layer deficiencies. We do not need
an RFC to state that.

The hidden terminal problem has been around since the origins of the
Internet. We do not need an RFC to highlight that this problem exists.

> This describes a problem. 

L3 routing infers link availability by exchanging messages. Link up/down
indicators help routing protocols react more quickly, but are just
optimizations compared to sending explicit discovery messages.

I.e., the problem is that you have a link layer that doesn't optimize.

> If the solution to it were a link-layer

There are hazards to any L2 attempt to determine link availability. In
particular, if the link is deemed available when IP packets cannot
transit, the information provided to L3 isn't helpful.

So maybe this can or should be solved at L2 (which would be outside the
scope of the IETF IMO), but whether it is solved or not should have no
impact on L3 except as a performance tweak.

>> signal-to-noise ratio and bit-error rate.

This is something that belongs in a textbook (and probably already
exists there). Again, you're far from something that warrants an RFC, IMO.

Joe