Subject: [Autoconf] link definitions

From: Thomas Narten <[email-masked]>
Date: Wed, 19 Nov 2008 09:40:27 -0500

It is very important that we are clear and precise about
terminology. I suspect that 80% of the confusion we have had stems
from folk using terminology loosely, causing the listener to think
something completely different from what the speaker intends. (I saw
clear examples of this in yesterday's meeting). That helps no one and
keeps us going in circles.

Let's start with "link". Even the term "link" is unclear. Are we
talking about an "IP link" or what most of us would consider an "L2
link"? (They are not necessarily the same.)

>From RFC 2460, link is defined as:

   link        - a communication facility or medium over which nodes can
                 communicate at the link layer, i.e., the layer
                 immediately below IPv6.  Examples are Ethernets (simple
                 or bridged); PPP links; X.25, Frame Relay, or ATM
                 networks; and internet (or higher) layer "tunnels",
                 such as tunnels over IPv4 or IPv6 itself.

What is unstated (but assumed) above is that all the nodes in the link
can reach each other. Note also that the above is really an L2
definition. It means that a node attached to the link can send a
packet to another node on the link (and vice versa). How that is done
(whether via a shared wire, or via packet switches doing routing, a
bridged ethernet, etc.) doesn't matter. The important thing is the
abstraction, that every node on the link can reach every other node on
the link.

If we up-level to what IP sees, an "IP link" has a similar
definition. It is assumed that all nodes on the link can directly send
an IP datagram to another node on the link, and it will get
delivered. Whether the underlying link has bridges/packet
switches/etc. doesn't matter. From IP's perspective, it sends a packet
and it gets deliverd without the TTL being decremented. That is what
IP cares about.

Also, by definition. for an "IP link", link-local multicast/broadcast
means that the packet is delivered everywhere without decrementing a
TTL. It has never made sense to me to say that "IP-level LL broadcast"
doesn't work in a MANET, because that is calling something an "IP
link" that does not have the properties to be a "IP link" in the
normal sense.

When talking about a "MANET link", we should (first) be talking about
what is happening below IP (i.e., either  at L2, or maybe L2.5, if one
wants to think of running the MANET protocols over the interface to
provide IP with an "IP link" abstraction). Exactly what are the
features of such a link?

A key question is what is the definition of a MANET Link? Previous
documents/conversations have suggested to me that some folk want to
make the entire collection of nodes running MANET form a MANET link. 

Looking at chart 37 of ThomasC's presentation yesterday, for example,
is the entire white cloud (i.e. all the routers) considered to be one
link? To me that raises the following questions:

If the entire cloud is a link, why are we doing that? What desireable
properties result from that? How does it make solving our problems any
easier?

If instead, we view the white cloud as collection of individual links
(e.g., with a link defined by the set of neighbors within radio range
of each other), we get a very different link model. This model
presumably also has some important properties. What are they? How do
they compare to the other model?  Does the model make it easier or
harder to solve certain problems?

To me, the narrower defintion of a link seems more natural because I I
have a good idea of how to map that into the "IP link" model in a way
that is compatable with existing IP assumptions.

For the former model to work with IP, we may well need to have a
sub-layer between the raw links and IP that convert the raw links
into an abstract link that has the properties that IP assumes will be
there (like bi-directional connectivity). Neither model is "right" or
"wrong", its just that they have different implications and
engineering tradeoffs.

In my mind, the excercise of defining a "MANET link" is all about
being able to talk about different abstract models (like the two
above) and then be able to talk (in specific engineering terms) about
which one makes more sense to use in trying to make IP work well over
MANETs.

Thomas
_______________________________________________
Autoconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/autoconf

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 19 Nov 2008 08:46:01 -0800

Thomas Narten wrote:
> definition.

Are you renaming the above term "link" to be named "IP link"?

> It means that a node attached to the link can send a

By "packet" are you talking about an (arbitrary) L2 frame, i.e., 
something which might not be an IP packet?

> and it gets deliverd without the TTL being decremented. That is what

AFAIU your use of "IP link" and "l2 link" I can't think of a useful case 
when they would differ. Do you see cases when they would differ?
(If there are L3 routers which forward packets without decrementing TTL 
then they would differ, but that is not useful and presumably violates 
the router requirements RFC.)

> link" that does not have the properties to be a "IP link" in the

Agreed.

> make the entire collection of nodes running MANET form a MANET link. 

I don't think we need a separate definition of a Manet Link.

> link? 

That doesn't make sense to me. I got the impression that this approach 
was taken to  try to preserve that a subnet prefix corresponds to a 
piece of topology where ttl isn't decremented, and I think that isn't 
something we need to preserve when the subnet prefix isn't advertised as 
"on link".

    Erik

---

From: Thomas Narten <[email-masked]>
Date: Wed, 19 Nov 2008 12:00:32 -0500

> Are you renaming the above term "link" to be named "IP link"?

Probably.. :-)

But I think it is useful to keep in mind that it is not a
_requirement_ to have a one-to-one mapping between an "IP link" and an
"L2 link". I don't think it makes sense in very many (if any?) cases,
but one difficulty I have had in understanding MANETs is that I don't
get a clear sense the WG has that agreement. (I'd love to learn I'm
wrong, of course).

> something which might not be an IP packet?

Correct. But of course, if one were to send an IP packet in such an L2
frame, it would be delivered without the need to decrement the IP
TTL. 

> when they would differ. Do you see cases when they would differ?

Well, in the autoconf discussions, I sometimes get the sense we are
talking about two different "links": one as viewed at the IP layer and
one that viewed from the perspective of describing a "manet link"
(more generically), where it is NOT immediately clear (to me) that
they are the same. I say that because at the MANET link level, there
is talk about packets being forwarded through intermediate routers
(with a decremented TTL), with this also somehow being an IP link
(which I think is not legal by the definition of an IP link per below).

> I don't think we need a separate definition of a Manet Link.

Well, we need to agree whether they can be the same definition or not
(I'd prefer they are the same!). But if not, we get into the need to
describe the properties of such a link (which presumably do not match
the needed properties of an IP link) so that we can talk about how to
transform such a link into something IP can work across.

> something we need to preserve when the subnet prefix isn't advertised as 

Right. I think I agree with this as well.

But as always, the challenge has been whether the WG overall has a
consistent view/understanding of these sorts of key archtictural
points.

Thomas

---

From: "Teco Boot" <[email-masked]>
Date: Wed, 19 Nov 2008 18:40:07 +0100

> abstraction, that every node on the link can reach every other node on

Although I agree this is the general case, there may be exceptions. Think of
private VLANs and hub&spoke NBMA networks where routers perform
spoke-to-spoke forwarding functions (hairpinning).

See also my posting on STD IEEE802.11-2007 on 3.16 (BSS), it clearly states
that the assumption is false. I think the issues is more related to IBSS
than BSS (or ESS).
For those who do not know, most 802 standards can be downloaded on:
http://standards.ieee.org/getieee802/

The question here is, do we want to support IPv6 on systems like 802.11 in
IBSS mode? 
I think: yes, we do.

Another question: do we want to repair asymmetric reachability (both
unidirectional and non-transitive) at the IP layer?
I think: yes we do, and that MANET protocols are designed doing so. I would
say this is for routers only, not for hosts.

Here may start some confusing. Because MANET protocol designers are so proud
on their efforts (thanks folks!), they may forget that there are
"well-behaving L2 systems" as well. And I can agree with the assumed
intention of Thomas Narten: solve problems at the layer that introduced it.
However, the question is: is this optimal?. I can demonstrate a layer-2
solution based on STP, but performance is not quite good. STP / RSTP is not
designed with mobility in mind. I am not the expert in 802.11s, but I assume
they reuse what is designed in the IETF MANET WG. And it is homogeneous.
An advantage of a L3-MANET is that a heterogeneous networking infrastructure
is supported. See also RFC2501 section 5.

> make the entire collection of nodes running MANET form a MANET link.

OK, we discussed this in the meeting and had consensus to step towards
defining a MANET link model that meets the IP link requirements, e.g.
link-local delivery, no TTL decrement and so on.

There was a comment on wording in RFC4861. 
   interface   - a node's attachment to a link.
                                        ^
The "a" hurts.
In RFC4861, a link is a "medium". Now, we decided to redefine this for
MANETs.

> harder to solve certain problems?

I tried to come up with a definition for "collection of individual links"
A MANET Interface has a single outbound unidirectional P2MP link to a set of
neighbors, a set of inbound unidirectional P2MP links from a set of
neighbors, a set of bi-directional P2P links with a set of neighbors and a
set of unidirectional P2P links from a set of neighbors. The sets of
neighbors and the link qualities vary over time and link metrics may be
asymmetric. Furthermore, links between the MANET Interfaces could be
non-transitive. A characteristic of MANET Links is interference, i.e. a
transmission from a MANET Interface could influence other MANET Links.
<<<

Maybe I should use broadcast instead of P2MP.

On "certain problems": the target of the MANET routing protocols is solve
those problems. This implies that there cannot be hosts on the MANET Link,
as hosts do not routing.

> which one makes more sense to use in trying to make IP work well over

Can we scope down towards trying to make MANET Routing Protocols work well?
For unicast routing, there are solutions and we are working on standard
track protocols.
For multicast routing, this is somewhat harder, but work in progress and
solutions are out there.
We have to work on link layer address resolving (ND), in my opinion this is
relatively easy.
And the real Autoconf work: Address Autoconfiguration with MANET and / or
globally unique addresses.

Teco.

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 19 Nov 2008 15:52:27 -0800

> (which I think is not legal by the definition of an IP link per below).

Yes, but I don't think that makes any sense.
But even if there was such a thing as a "manet link" my understanding is 
that it wouldn't match your definition of "IP link", since AFAIK the 
manet routers decrement ttl.

It is useful for manet, as well as 6lowpan, to have a prefix (which I 
think of a subnet prefix) span more than one link, because it allows 
nodes to move around inside the subnet without having to change their IP 
address and the whole think can be aggregated into a single route that 
is announced externally to the manet.

We have many of the parts we need for this (RAs don't have to advertise 
any on-link prefixes), but one would need to do duplicate address 
detection differently.

Agreed.

> consistent view/understanding of these sorts of key archtictural

I can't speak for the WG, but to me there has been two pieces missing:
  - the motivation for why it makes sense to define the link as what is 
within radio reachability
  - the terminology confusion where manet has described things as not 
having/needing any "links" since they just use "interfaces".

Defining the link as "radio reachability" provides a definition which is 
both useful and consistent with (my understanding of) manet operational 
practices.

(Of course, one can additionally have links that are glued onto the 
manet routers; these are the links between the "H" and "R" in Thomas' 
presentation.)

    Erik

---

From: Paul Lambert <[email-masked]>
Date: Wed, 19 Nov 2008 16:41:41 -0800

> both useful and consistent with (my understanding of) manet operational

Radio reachability is an incomplete definition. Please consider that all Wi-Fi links that use current mechanisms for 802.11 security require explicit establishment of the security association (Two - four way exchanges).  Radio reachability does not imply link connectivity.  Link connectivity is always arbitrary and reachability is only one aspect.

I'm also finding that the explicit initial establishment of a "link" versus implicit reachability provides solutions in this architectural space rather than more constraints.  The ability to have a clarity in the process of joining a network or creating a link enables better autoconf-like solutions.  Specifically, the IP address assignment can be made an atomic operation with the addition of the link from the perspective of the network services.

Paul

---

From: "Teco Boot" <[email-masked]>
Date: Thu, 20 Nov 2008 02:07:19 +0100

> is announced externally to the manet.
 
I am not sure if we need this "wide prefix subnet". For the MANET Routers,
we would use host prefixes (/128) on loopback interfaces, or maybe on the
MANET interface itself if someone thinks this is a better approach. 
Configuring a /128 prefix on an interface would make the interface look like
stub (not sure on this completely).

Agreed on the aggregation prefix for the MANET. With multi-homing, we could
have multiple aggregation prefixes. 

Teco.

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 19 Nov 2008 18:20:37 -0800

> Radio reachability is an incomplete definition. Please consider that all Wi-Fi links that use current mechanisms for 802.11 security require explicit establishment of the security association (Two…

I agree that the term "radio reachability" is the wrong one to capture 
the security aspects for such technologies. What I mean (and I don't 
have a good term) is that if node A sends an L2 packet it arrives at 
node B, including any CRC or security checks.

> I'm also finding that the explicit initial establishment of a "link" versus implicit reachability provides solutions in this architectural space rather than more constraints.  The ability to have a…

I don't see how you can this without either making assumptions about the 
capabilities of the L2 technology, or inventing some new L3 attachment 
protocol.

    Erik

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 19 Nov 2008 18:21:22 -0800

> stub (not sure on this completely).

Which prefix are you going to allocate addresses from?

That is the prefix I'm talking about.

    Erik

---

From: Ulrich Herberg <[email-masked]>
Date: Wed, 19 Nov 2008 20:23:05 -0600

> have multiple aggregation prefixes. 

As I am rather new to this working group, please forgive me (and correct
me) if I do not know the whole history of the WG or do misunderstand
something.
In my opinion, it is wrong to have a MANET-wide subnet. As said by
Thomas, having a subnet for the whole MANET -- considering we understand
where the boundaries of "a" MANET are -- would mean that every router
can reach each other without decrementing TTL. As far as I understood
MANETs, this is not the case. Being on the same subnet means IMHO that
you can assume to reach every other node without decrementing TTL, which
is only the case for the router itself or subordinate hosts attached to
it. However, this does not avoid aggregating prefixes -- you can still
aggregate using shorter prefixes than the defined subnets.

I do have a hard time understanding the history of the autoconf WG. I
understand that it was asked by some people in the WG to define a link
type for better understanding of the assumptions in a MANET. However, in
the mailing list and during the meeting I rather had the impression that
there is not much interest in the document, or at least that there is no
consensus that this draft goes into the right direction. Even though I
personally rather agree with Thomas' document, there might be a reason
that it is wrong. However, for having a fruitful discussion, it would
help a lot to have competing drafts from other WG members that disagree
with the draft. It would be a lot easier for myself understanding the
different possible views of "a link" and "a MANET", if there were
different drafts that detail certain assumptions. Often the devil's in
the details, so for me to understand the whole issue, it could help a
lot not just talking about the definition of a link, but to write
something down. I really would hope that those who have strong
counter-arguments against the presented draft could write an ID, so that
WG members could have an impression about different architectural views
until IETF'74.

Best regards,
Ulrich

---

From: Paul Lambert <[email-masked]>
Date: Wed, 19 Nov 2008 19:00:12 -0800

> Behalf Of Ulrich Herberg

....
> MANETs, this is not the case.

I am new too .. but also confused on these definitions ...

On the reachability, it is possible for the network layer to view the peer MANET devices as reachable without TTL decrementing if the link layer is bridging or is configured as a link layer mesh.

The definitions (IMHO) are flawed in that they do not match well existing definitions of links and link layer service architectures (at least for 802 link layers).

Paul

---

From: "Teco Boot" <[email-masked]>
Date: Thu, 20 Nov 2008 05:21:15 +0100

> >> nodes to move around inside the subnet without having to change
> their
> >> IP

OK, maybe I was confused by wording. 
c/subnet/summary/ and I am fine.

But the host prefix does not span more than one link.

Teco.

---

From: "Teco Boot" <[email-masked]>
Date: Thu, 20 Nov 2008 06:31:59 +0100

> aggregate using shorter prefixes than the defined subnets.
 
We are on the same page. But be careful with the term subnet. I prefer using
routing prefix if we discuss routing.

> WG members could have an impression about different architectural views
 
I had the feeling that there was some misunderstanding on "link"
terminology. I think it makes sense to converge to some unambiguous
definitions. And I think we are not far from that. 
Then we can continue our work on problem statement and follow-up.

Teco.

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 21 Nov 2008 15:06:58 -0800

> routing prefix if we discuss routing.

I'm starting to get the feeling we should stay away from "subnet" or 
"subnet prefix", since "subnet" has too much historical stuff associated 
with it.

But the prefix will presumably be used for address configuration in 
addition to routing, thus "routing prefix" might be too specific.

How about something like this:
One (or more) IP address prefixes is assigned to a Manet. The IP address 
autoconfiguration is used to configure addresses from that/those 
prefixes, and typically the whole Manet is represented externally as a 
single aggregated route for each of those prefixes.

The above definition doesn't preclude different parts ot the Manet to be 
allocated sub-prefixes or additional prefixes. Such prefixes can be 
assigned to fixed/wired/static links attached to Manet routers.

    Erik

---

From: "Teco Boot" <[email-masked]>
Date: Sat, 22 Nov 2008 18:22:01 +0100

Hi Erik,

> -----Oorspronkelijk bericht-----
> Van: Erik Nordmark [mailto:[email-masked]]
> Verzonden: zaterdag 22 november 2008 0:07
> Aan: Teco Boot
> CC: 'Ulrich Herberg'; [email-masked]
> Onderwerp: Re: [Autoconf] link definitions
> 
> Teco Boot wrote:
> 
 
I don't see that much a problem using "prefix", as the issues were we are
working on is handled by routers. Hosts in a MANET (e.g. connected to a
MANET Router via Ethernet or infrastructure mode WLAN) MUST be provided a ND
service as specified in RFC4861 / RFC4862.

Routers shall be able to handle address prefixes, including host prefixes
(alias for address, but more related to a router).

> single aggregated route for each of those prefixes.

OK, but I don't agree on "_single_ aggregated route".
I think multi-homing SHOULD be supported. 
And it is not that difficult (here another advertisement for
BRDP-Based-Routing).

Teco.

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 24 Nov 2008 14:56:10 -0800

> (alias for address, but more related to a router).

I agree that "prefix" is ok; I think "routing prefix" might be too 
specific. So I think we are in agreement.

> I think multi-homing SHOULD be supported. 

Sure.
What I meant is that all the addresses that fall in a given prefix is 
normally represented externally as a single route. That doesn't prevent
1) addresses being allocated from multiple prefixes (resulting in 
multiple routes being advertised), or
2) multiple routers (at the "edge" of the Manet) announcing that/those 
route(s)

    Erik