Subject: [6lowpan] Way forward for 6LoWPAN-ND, consensus call

From: Carsten Bormann <[email-masked]>
Date: Thu, 12 Nov 2009 11:50:21 +0900

After the 6LoWPAN meeting, there have been some hallway conversations
on the need for DAD vs. the expense of DAD.  Clearly, the 4861 way of
involving potentially all hosts in that process is not applicable in
most interesting 6LoWPAN configurations.  More generally speaking,
whatever we do here, it should not involve the hosts.

The remaining discussions essentially were about how the "fabric"
(please excuse me using that term, which I'll use for the set of nodes
that are not just hosts) might achieve proper address allocation
and/or validation (DAD).  The right answer seems to depend on the
specific areas of application, network configurations, and
characteristics of that fabric.  For some cases, the centralized
approach with one or more edge routers is the right way to do this;
for others, the additional messages needed for a distributed approach
may be justified by the increased flexibility possible with that.

But the important point is that whatever the fabric does here, the
hosts do not care.  They want to register their addresses with the
fabric (not just for allocation/DAD, but foremost to get routed to),
and couldn't care less how that oracle comes up with "yes" or "no", or
how it derives any allocations requested.  6LoWPAN-ND differs from
4861 in that the host-router interface is fully node-initiated, which
is the only appropriate way to do this with potentially sleeping
nodes.

Keeping that host-router interface simple and interoperable is the
most important concern: There will be billions of these 6LoWPAN host
nodes, and their interface to the network should be based on a stable
specification and isolated from the specifics of the intra-fabric
algorithms.

So the (in hindsight very obvious) way forward is:
-- split off the host-router interface part of 6LoWPAN-ND into one
    document of its own.  This document will contain the router
    discovery and node registration protocol components of
    draft-ietf-6lowpan-nd-07.txt (NR/NC with code != 1, the RA
    parameters/options).  Based on the input from 6man, the ADs and the
    IAB, this will also now make use of the terminology in
    draft-ietf-autoconf-adhoc-addr-model-00.txt that is quickly
    becoming the new consensus for this kind of network.  This part of
    the split is the document that will update RFC 4944 in the way
    envisioned by RFC 4861 section 1.
-- rename the rest of draft-ietf-6lowpan-nd-07.txt, i.e. the
    fabric-side part (relayed NR/NC, Edge Router operation, OIIO) into
    "6LoWPAN Edge Router backend", as a draft separate from the
    above common router discovery/node registration protocol.
-- go ahead and define other backends for those cases that merit it.

Three types of backends beyond the existing Edge-Router based backend
have been mulled over in various hallways so far:

-- a multicast-based backend where all 6LoWPAN routers announce and
    defend their client hosts' addresses between themselves (without
    involving the hosts).  A degenerate case is the simple star
    network, where the single hub node can do all this all by itself.
-- a routing-system based backend, where the management of addresses
    is integrated into the routing protocol (e.g., in RPL by adding
    information to DAO type messages and processing rules).
-- a DHCP-based backend (which could use either of the above for DAD).

This is not saying that we want to actually standardize all three of
these backends.  But we should at least do proof-of-concept ("napkin")
versions of all three to ensure the host-router interface works well
with either of them.

Many thanks to Geoff Mulligan and Thomas Clausen for their help in
identifying this approach, and to Ralph Droms, Jari Arkko, and Dave
Thaler for supplying the missing links.

Geoff Mulligan, who is acting as the chair for this document (because
I'm a co-author), has requested me to announce this and ask the
working group for consensus on this approach.  Please reply by

            November 18, 24:00 UTC

with your concerns, comments, or just plain support that this is
indeed the way forward.

Gruesse, Carsten

---

From: "Anders Brandt" <[email-masked]>
Date: Thu, 12 Nov 2009 10:21:18 +0100

Carsten, Geoff, et al.

>From a standards point of view, I am really fine with clear, limited specifications which do not leave a lot of features optional. While 99% of 6lowPan systems in my corner of this business will have no risk of creating duplicate IP addresses, I do believe that a relevant fraction of the systems may benefit from redundant / geographically distributed edge routers to get
1) Short routes to the backbone when everything works
2) Maintain connectivity when one edge router goes away for whatever reason - maintenance included.
 
In short, yes, there is a need for backbone-coordinated edge routers. I also believe it should be kept really simple to be interesting for low-end market solutions. This points towards simple multicast advertisement - but: and this is the important part: I would hate three options. This would require all vendors to implement all three to be on the safe side. 
 
Thus: One acceptable compromise is more important than an optimized approach which rules out 50% of potential system deployments. And yes, please: Let this be defined in a companion spec, which vendors MAY decide to implement.
 
- Anders

________________________________

Fra: [email-masked] på vegne af Carsten Bormann
Sendt: to 12-11-2009 03:50
Til: 6lowpan
Emne: [6lowpan] Way forward for 6LoWPAN-ND, consensus call

            November 18, 24:00 UTC

Gruesse, Carsten

_______________________________________________
6lowpan mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/6lowpan

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 12 Nov 2009 10:59:05 +0100

Hi Carsten:

I think this is a brilliant proposal, and I'm strongly in favor. It
makes things a lot clearer to the users, and distributes the roles
better.

I understand that the overall content that we agreed to standardize in
Dublin and as currently expressed in ND 07 will not change during the
reorganization.

I'd support additional drafts that explain how this gets mapped onto a
DHCP-based infrastructure. Also how this gets mapped onto a TRILL or a
routing based infra.

Cheers,

Pascal

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On
Behalf Of Carsten Bormann
>Sent: jeudi 12 novembre 2009 03:50
>To: 6lowpan
>Subject: [6lowpan] Way forward for 6LoWPAN-ND, consensus call
>

---

From: "Julien Abeille (jabeille)" <[email-masked]>
Date: Thu, 12 Nov 2009 11:06:55 +0100

Carsten,

We have a strong disagreement on the rationale for the draft. Do you
REALLY think splitting the draft in two drafts solves anything? 

Julien

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Carsten Bormann
> After the 6LoWPAN meeting, there have been some hallway 
> conversations on the need for DAD vs. the expense of DAD.  
> Clearly, the 4861 way of involving potentially all hosts in 
> that process is not applicable in most interesting 6LoWPAN 
> configurations.  More generally speaking, whatever we do 
> here, it should not involve the hosts.
> 
> (please excuse me using that term, which I'll use for the set 
> of nodes that are not just hosts) might achieve proper 
> address allocation and/or validation (DAD).  The right answer 
> seems to depend on the specific areas of application, network 
> configurations, and characteristics of that fabric.  For some 
> cases, the centralized approach with one or more edge routers 
> is the right way to do this; for others, the additional 
> messages needed for a distributed approach may be justified 
> by the increased flexibility possible with that.
> 
> But the important point is that whatever the fabric does 
> here, the hosts do not care.  They want to register their 
> addresses with the fabric (not just for allocation/DAD, but 
> foremost to get routed to), and couldn't care less how that 
> oracle comes up with "yes" or "no", or how it derives any 
> allocations requested.  6LoWPAN-ND differs from
> 4861 in that the host-router interface is fully 
> node-initiated, which is the only appropriate way to do this 
> with potentially sleeping nodes.
> 
> Keeping that host-router interface simple and interoperable 
> is the most important concern: There will be billions of 
> these 6LoWPAN host nodes, and their interface to the network 
> should be based on a stable specification and isolated from 
> the specifics of the intra-fabric algorithms.
> 
> Three types of backends beyond the existing Edge-Router based 
> backend have been mulled over in various hallways so far:
> 
> This is not saying that we want to actually standardize all 
> three of these backends.  But we should at least do 
> proof-of-concept ("napkin") versions of all three to ensure 
> the host-router interface works well with either of them.
> 
> Many thanks to Geoff Mulligan and Thomas Clausen for their 
> help in identifying this approach, and to Ralph Droms, Jari 
> Arkko, and Dave Thaler for supplying the missing links.
> 
> Geoff Mulligan, who is acting as the chair for this document 
> (because I'm a co-author), has requested me to announce this 
> and ask the working group for consensus on this approach.  
> Please reply by
> 
>             November 18, 24:00 UTC
> 
> with your concerns, comments, or just plain support that this 
> is indeed the way forward.
> 
> Gruesse, Carsten
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 12 Nov 2009 11:49:30 +0100

Carsten Bormann a écrit :
[...]
>    becoming the new consensus for this kind of network.

Er?

I can see here two disagreements:

(1) AUTOCONF document draft-ietf-autoconf-adhoc-addr-model-00.txt is not
     such a big consensus you make it sound like.  To me there seem to
     be disagreements on at least one issue: link-local addresses.  Which
     brings point 2 below.

(2) Link-local addresses: the AUTOCONF is vaguely but surely
     recommending against  them:
>    Note that while an IPv6 link-local address is assigned to each
>    interface as per [RFC4291], in general link-local addresses are of
>    limited utility on links with undetermined connectivity, as
>    connnectivity to neighbors may be constantly changing.

whereas the 6LoWPAN ND document says they're supported:
>    Link-local
> 
>       Standard IPv6 link-local scope as defined in [RFC4291] and
>       [RFC4861] is supported by the 6LoWPAN link and subnet model.

I agree with this latter part.

Alex

---

From: Ulrich Herberg <[email-masked]>
Date: Thu, 12 Nov 2009 23:00:24 +0900

Alex,

>    be disagreements on at least one issue: link-local addresses.  Which

I have to disagree. While you personally may not like this document,
the AUTOCONF WG chairs have sensed a consensus of the WG on that
document. Also, some issues about the draft that have been raised
(notably the text about LLs), have been solved during the AUTOCONF
meeting by proposing modifications of the text. The minutes of
AUTOCONF will certainly be released soon. That said, the discussion
about consensus of an AUTOCONF draft is probably of no concern for
6lowpan, so this will be my only response to that topic on this
mailing list.

Ulrich

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 12 Nov 2009 15:55:22 +0100

> 6lowpan, so this will be my only response to that topic on this

Ulrich, ok.

What do you think about the 2nd point?  (the fact that 
draft-ietf-autoconf-adhoc-addr-model-00.txt talks differently about LLs 
than draft-ietf-6lowpan-nd-07.txt does)

Alex

---

From: Zach Shelby <[email-masked]>
Date: Thu, 12 Nov 2009 17:27:18 +0200

On Nov 12, 2009, at 16:55 , Alexandru Petrescu wrote:
> What do you think about the 2nd point?  (the fact that draft-ietf- 
> autoconf-adhoc-addr-model-00.txt talks differently about LLs than  
> draft-ietf-6lowpan-nd-07.txt does)

Keep in mind that -07 uses its own definitions and model, which have  
little chance of living on their own. So don't compare terminology  
from -07 with the autoconf model. In practice, the autoconf model does  
not change how our solution works. The design team is now starting to  
look at that, so please be patient for -08.

A couple clarifications:

1. We will initially only copy the autoconf model for our purposes. If  
it goes forward to an RFC rather quickly, we may theb make a nomative  
reference at some point. I at least strongly support that the autoconf  
model work is moved forward as quickly as possible.

2. The autoconf model very rightly points out that link-local scope  
(and thus addresses) are of limited use. But it does not forbid them.  
We have exactly the same setup in 6lowpan-nd as well.

Let's not speculate too much on the autoconf model until we get -08 of  
our draft out - and then you will see how the pieces fall together.  
Based on my initial analysis it is a nice fit, but the devil is in the  
details still. In practice we came to the same conclusions in this WG,  
but used slightly different terminology (or it turns out we defined  
things like subnets and links when we didn't need to).

Zach

-- 
http://www.sensinode.com
http://zachshelby.org - My blog “On the Internet of Things”
Mobile: +358 40 7796297

Zach Shelby
Head of Research
Sensinode Ltd.
Kidekuja 2
88610 Vuokatti, FINLAND

This e-mail and all attached material are confidential and may contain  
legally privileged information. If you are not the intended recipient,  
please contact the sender and delete the e-mail from your system  
without producing, distributing or retaining copies thereof.

---

From: Ulrich Herberg <[email-masked]>
Date: Fri, 13 Nov 2009 00:47:02 +0900

Alex,

On Thu, Nov 12, 2009 at 11:55 PM, Alexandru Petrescu
<[email-masked]> wrote:
>>[..]
> draft-ietf-autoconf-adhoc-addr-model-00.txt talks differently about LLs than

I have not followed the discussions in 6lowpan closely enough, to
express an opinion on that. 6lowpan may have other assumptions and
another architecture, and the autoconf-addr-model might thus not
directly be applicable in 6lowpans.

Ulrich

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 12 Nov 2009 16:50:45 +0100

Zach Shelby a écrit :
>> draft-ietf-autoconf-adhoc-addr-model-00.txt talks differently about 
>> LLs than draft-ietf-6lowpan-nd-07.txt does)
> 
> little chance of living on their own. So don't compare terminology from 
> -07 with the autoconf model. In practice, the autoconf model does not 
> change how our solution works. The design team is now starting to look 
> at that, so please be patient for -08.
> 
> A couple clarifications:
> 
> 2. The autoconf model very rightly points out that link-local scope (and 
> thus addresses) are of limited use.

YEs - the limit is that link.  No other limit I can imagine.

Especially here, where 802.15.4 is cited upfront.

> But it does not forbid them.

Ok.

> We have 
> exactly the same setup in 6lowpan-nd as well.

I am not sure. Here you do cite 802.15.4 whereas in AUTOCONF there's no 
link suggested.

> things like subnets and links when we didn't need to).

Well - you're questioning here prior agreements.  We did seem to be in 
agreement when defining links in 6lowpan, as of April 2009, see attached 
email.

Now you do not like that anymore.

Why?

I think that links and subnets should be defined.  If AUTOCONF doesn't - 
that's an AUTOCONF issue.  That error shouldn't be done here too.

Alex

>> Alex

Subject: Re: [6lowpan] link definition of rfc4861 to cover wireless non-transitive links as well
From: Zach Shelby <[email-masked]>
To: Alexandru Petrescu <[email-masked]>
Cc: 6lowpan <[email-masked]>
Date: Sat, 25 Apr 2009 16:00:55 +0300

Hi,

I like this, taking the RFC4861 definition and just adding the wireless 
considerations. We should also mention as part of the wireless links 
part the following:

- Wireless links considered by 6LoWPAN may not support native multicast.
- Wireless links are not static, frequent changes are to be expected 
because of radio channel fading or node mobility.

This link definition originates from the ND draft, and was just copied 
into the other drafts for consistency. I will make a ticket to update 
the link definition in nd-03. This was a good solution, thanks.

- Zach

Alexandru Petrescu wrote:
> Previous discussion indicated that link definition of RFC 4861 "Neighbor
> Discovery for IPv6" is pertinent to 6LoWPAN.  I agree with it and
> suggest the following 6LoWPAN definition:
> 
>    link       -  a communication facility or medium over which
>                  nodes can communicate at the link layer, i.e.,
>                  the layer immediately below IP (each node can
>                  communicate to each other in this medium).
> 
>                  Examples are Ethernets (simple or bridged), PPP
>                  links, X.25, Frame Relay, wireless links or ATM
>                  networks as well as Internet-layer (or
>                  higher-layer) "tunnels", such as tunnels over
>                  IPv4 or IPv6 itself.
> 
>                  This is a slightly modified definition of the link
>                  defined in RFC4861, in order to cover also the wireless
>                  links.  Wireless links may be non-transitive (node A
>                  communicates at link layer to both B and C yet B and C
>                  are not on the same link).  Hidden terminal problem in
>                  wireless communications is described in [reference to
>                  individual draft in AUTOCONF]
>                  draft-baccelli-multi-hop-wireless-communication-02
> 
> What do people think about using this link definition in 6LoWPAN?
> 
> Alex
> 
> 
> 

Zach Shelby
Head of Research
Sensinode Ltd.
Kidekuja 2
88610 Vuokatti, FINLAND

This e-mail and all attached material are confidential and may contain 
legally privileged information. If you are not the intended recipient, 
please contact the sender and delete the e-mail from your system without 
producing, distributing or retaining copies thereof.

---

From: Ulrich Herberg <[email-masked]>
Date: Fri, 13 Nov 2009 00:53:46 +0900

Zach,

On Fri, Nov 13, 2009 at 12:27 AM, Zach Shelby <[email-masked]> wrote:
>[...]
> Keep in mind that -07 uses its own definitions and model, which have little
> chance of living on their own. So don't compare terminology from -07 with
> the autoconf model. In practice, the autoconf model does not change how our
> solution works. The design team is now starting to look at that, so please
> be patient for -08.
>
> A couple clarifications:
>
> 1. We will initially only copy the autoconf model for our purposes. If it
> goes forward to an RFC rather quickly, we may theb make a nomative reference
> at some point. I at least strongly support that the autoconf model work is
> moved forward as quickly as possible.

I agree to that.

> thus addresses) are of limited use. But it does not forbid them. We have

I fully agree. LLs are of limited use, but not forbidden in the
autoconf addr-model.

>
> Let's not speculate too much on the autoconf model until we get -08 of our
> draft out - and then you will see how the pieces fall together. Based on my
> initial analysis it is a nice fit, but the devil is in the details still. In
> practice we came to the same conclusions in this WG, but used slightly
> different terminology (or it turns out we defined things like subnets and
> links when we didn't need to).

Yes, another agree.

Ulrich

---

From: Zach Shelby <[email-masked]>
Date: Thu, 12 Nov 2009 17:58:57 +0200

Alex,

> Especially here, where 802.15.4 is cited upfront.

The 6lowpan-nd draft specifically says the link could be 802.15.4 or  
any other suitable link.

> Well - you're questioning here prior agreements.  We did seem to be  
> in agreement when defining links in 6lowpan, as of April 2009, see  
> attached email.

We do appreciate all the help you gave to polish our model in April,  
thanks for that!

> Now you do not like that anymore.

We have feedback from 6man and the ADs to look at using a similar  
model as in autoconf, as the multi-hop subnet model we currently have  
is still pretty controversial (although not-quite-as-bad as a multi- 
link subnet...). Therefore we are looking at that. Let's see what we  
can do with -08. Thanks for your feedback, let's return to that again  
after the next revision.

Zach

> Date: April 25, 2009 16:00:55 GMT+03:00
> I like this, taking the RFC4861 definition and just adding the  
> wireless considerations. We should also mention as part of the  
> wireless links part the following:
>
> This link definition originates from the ND draft, and was just  
> copied into the other drafts for consistency. I will make a ticket  
> to update the link definition in nd-03. This was a good solution,  
> thanks.
>
> - Zach
>
> This e-mail and all attached material are confidential and may  
> contain legally privileged information. If you are not the intended  
> recipient, please contact the sender and delete the e-mail from your  
> system without producing, distributing or retaining copies thereof.
>
>
>
>

Zach Shelby
Head of Research
Sensinode Ltd.
Kidekuja 2
88610 Vuokatti, FINLAND

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 12 Nov 2009 17:17:36 +0100

> The 6lowpan-nd draft specifically says the link could be 802.15.4 or

I think you meant "similar" and not "suitable".  Which makes a huge 
difference.

> We do appreciate all the help you gave to polish our model in April,

And now you're about to remove the link definitions - thanks for
thanking me.

> is still pretty controversial (although not-quite-as-bad as a
> multi-link subnet...). Therefore we are looking at that. Let's see
> what we can do with -08. Thanks for your feedback, let's return to
> that again after the next revision.

Let me tell more then.

Additionally to AUTOCONF draft being against the 6lowpan-ND definition
of link, and of its first phrase in the Bootstrapping section (are you
going to remove that too?), AUTOCONF draft also requires the prefixes to
be /128 exclusively.  Are you thus going to require /128 prefixes
exclusively too in the 6lowpan-ND document?

Are you going to modify the 6lowpan-ND bootstrapping because AUTOCONF
draft requires prefixes /128?

I would rather suggest the other way around - modify the AUTOCONF
addressing model such as to recommend the use of LLs (make them first
class citizens on a link) because 6lowpan-ND needs them while
bootstrapping, and allow for prefixes other than /128 also because
6lowpan-ND needs them in its bootstrapping section.

Alex

---

From: Zach Shelby <[email-masked]>
Date: Fri, 13 Nov 2009 14:06:36 +0200

> And now you're about to remove the link definitions - thanks for

We didn't say that we are going to remove all references to a link. We  
haven't decided how to use the autoconf model yet.  Obviously we would  
need to build around it.

> exclusively too in the 6lowpan-ND document?

As a LoWPAN shares a single prefix, all nodes in a LoWPAN can have is  
a an address. We do not talk about assigning prefixes to nodes in this  
WG. Routers do advertise the prefix used throughout the LoWPAN (using  
RAs). And nodes may then auto-configure addresses based on that.

> draft requires prefixes /128?

It already works like this, no changes necessary. As far as I can  
tell, the autoconf draft requires no functional changes to the base  
mechanisms of our work. Again, we still need to look at the details.

Cheers,
Zach

Zach Shelby
Head of Research
Sensinode Ltd.
Kidekuja 2
88610 Vuokatti, FINLAND

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 13 Nov 2009 18:01:08 +0100

Zach Shelby a écrit :
>>> We do appreciate all the help you gave to polish our model in 
>>> April, thanks for that!
>> 
> We didn't say that we are going to remove all references to a link. 
> We haven't decided how to use the autoconf model yet.  Obviously we 
> would need to build around it.
> 
>> Additionally to AUTOCONF draft being against the 6lowpan-ND 
>> definition of link, and of its first phrase in the Bootstrapping 
>> section (are you going to remove that too?), AUTOCONF draft also 
>> requires the prefixes to be /128 exclusively.  Are you thus going 
>> to require /128 prefixes exclusively too in the 6lowpan-ND 
>> document?
> 
>  a an address.

YEs - that shared single prefix is a /64 with IPv6 over 802.15.4,
because that's what rfc4944 suggests.

And yes, each node in a LoWPAN has an address.

Or, AUTOCONF draft-ietf-autoconf-adhoc-addr-model-00 says this:
> o  A subnet prefix configured on this interface should be of length 
> /128.

I think we either have a terminology problem (what's a "subnet prefix
configured on an interface"?) or a crystalizing incoherency between
AUTOCONF and 6lowpan-nd.

My suggestion, along the way I understand these WGs landscapes, please
modify the AUTOCONF document to no longer suggest that /128 prefixes
assigned to interfaces that way.

If AUTOCONF means "host-based routes" by that "subnet prefix configured
on an interface should be /128" then AUTOCONF please use "host-based
routes" instead in the AUTOCONF recommendations.

AUTOCONF please note that 6lowpan-ND document touches briefly on these
host-based routes aspects when talking "exact match" searches in its 
6LoWPAN Terminology section, and please don't remove that from the 
6lowpan-ND document.

The "exact match" method of search in a routing table (as opposed to 
"longest-prefix match") is terminology similar to "Basic Match" and 
"Longest Match" used in rfc1812.  Although the rfc is only IPv4 it also 
applies to IPv6.

It is however not quite the same thing.

When you want, we can discuss the definition of "exact match" further, 
as useful to implementer.  The 6lowpan-ND definition of "exact match" is 
a good start, IMHO.

> We do not talk about assigning prefixes to nodes in this WG.

YEs, right.

AUTOCONF doesn't talk either: they recommend the assignment of a /128
prefix to an _interface_ (not a node).

Or, 6lowpan-ND does assign a prefix to an interface when doing the
IPv6-over-802154 SLAAC stuff.

> Routers do advertise the prefix used throughout the LoWPAN (using 

YEs, and the auto-configured addresses look like this:

2001:db8::XXXX:XXXX:XXXX:XXXX/64

Note the "/64".

Alex

> 
>> 
>> Are you going to modify the 6lowpan-ND bootstrapping because 
>> AUTOCONF draft requires prefixes /128?
> 
> Cheers, Zach

---

From: Zach Shelby <[email-masked]>
Date: Fri, 13 Nov 2009 21:30:54 +0200

Alex,

(added autoconf to CC)

Now I see what you were concerned about below. Yes I agree, the  
wording of how we assign addresses is slightly different. We are using  
host-based routes with exact match. As the autoconf document uses a  
SHOULD here, 6lowpan-nd can still use a /64 advertised throughout the  
LoWPAN to form addresses. It would be nice if autoconf could update  
their wording somewhat, so let's see if that is possible.

Some comments below.

On Nov 13, 2009, at 19:01 , Alexandru Petrescu wrote:

>>> to require /128 prefixes exclusively too in the 6lowpan-ND document?
>> o  A subnet prefix configured on this interface should be of  
>> length /128.
>
> "Longest Match" used in rfc1812.  Although the rfc is only IPv4 it  
> also applies to IPv6.
>
> When you want, we can discuss the definition of "exact match"  
> further, as useful to implementer.  The 6lowpan-ND definition of  
> "exact match" is a good start, IMHO.
>

I meant interface of course (we usually just have one)...

> IPv6-over-802154 SLAAC stuff.

Not exactly. We only use the advertised /64 to form the address. After  
that we assume everything (except link-local) is off-link. Therefore  
we don't really assign the prefix to the interface. So in practice the  
end result is the same as assigning a /128. Right? So this is just a  
wording difference.

> 2001:db8::XXXX:XXXX:XXXX:XXXX/64

So the autoconf text should say that you can should a /128 or a /64  
when using SLAAC to make that explicitly OK?

Zach

Zach Shelby
Head of Research
Sensinode Ltd.
Kidekuja 2
88610 Vuokatti, FINLAND

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 13 Nov 2009 21:30:53 +0100

[frustrated having to post again on AUTOCONF, especially now I don't
  want to disturb what Carlos has to say in AUTOCONF, but here goes
  Cc AUTOCONF anyways.]

Zach Shelby a écrit :
> wording of how we assign addresses is slightly different. We are
> using host-based routes with exact match. As the autoconf document
> uses a SHOULD here, 6lowpan-nd can still use a /64 advertised
> throughout the LoWPAN to form addresses. It would be nice if autoconf
> could update their wording somewhat, so let's see if that is
> possible.

YEs, let's see.

>>>> And now you're about to remove the link definitions - thanks
>>>> for thanking me.
>>> We didn't say that we are going to remove all references to a
>>> link. We haven't decided how to use the autoconf model yet.
>>> Obviously we would need to build around it.
>>>> definition of link, and of its first phrase in the
>>>> Bootstrapping section (are you going to remove that too?),
>>>> AUTOCONF draft also requires the prefixes to be /128
>>>> exclusively.  Are you thus going to require /128 prefixes
>>> As a LoWPAN shares a single prefix, all nodes in a LoWPAN can
>>> have is a an address.
>> 
>> I think we either have a terminology problem (what's a "subnet
>> prefix configured on an interface"?) or a crystalizing incoherency
>> between AUTOCONF and 6lowpan-nd.
>> 
>> My suggestion, along the way I understand these WGs landscapes,
>> please modify the AUTOCONF document to no longer suggest that /128
>> prefixes assigned to interfaces that way.
>> 
>> If AUTOCONF means "host-based routes" by that "subnet prefix
>> configured on an interface should be /128" then AUTOCONF please use
>> "host-based routes" instead in the AUTOCONF recommendations.
>> 
>> AUTOCONF please note that 6lowpan-ND document touches briefly on
>> these host-based routes aspects when talking "exact match" searches
>> in its 6LoWPAN Terminology section, and please don't remove that
>> from the 6lowpan-ND document.
>> 
>> The "exact match" method of search in a routing table (as opposed
>> to "longest-prefix match") is terminology similar to "Basic Match"
>> and "Longest Match" used in rfc1812.  Although the rfc is only IPv4
>> it also applies to IPv6.
>> 
>> AUTOCONF doesn't talk either: they recommend the assignment of a
>> /128 prefix to an _interface_ (not a node).
> 

Ok.

> Not exactly. We only use the advertised /64 to form the address.
> After that we assume everything (except link-local) is off-link.
> Therefore we

Then you should say so - "off-link".

But in 6lowpan-ND draft you mention that "off-link" has no clear meaning
on non-transitive links.  If "off-link" has no clear meaning, and
"on-link" has no meaning either, then we risk big trouble because these
terms are heavily used by ND.

And you define "non-local".  But that word risks coliding with the
established "link-local".  Another big trouble.

Couldn't we just improve that link definition and make it be
deterministic (no A-B-C problem and yes multicast support as offered by
802.15.5)?

If we did so - then we wouldn't have to say that "off-link" has no clear
meaning, and we subsequently wouldn't have to define the terms
"non-local"/"local" which risk coliding with the established "link-local".

> don't really assign the prefix to the interface. So in practice the

Well, AUTOCONF should recommend the use of host-based routes if that's
their intention.  Host-based routes don't break anything if deployed on 
small scale.  An exact-match search in a routing table is easily 
implementable with current tables and existing "longest-prefix" match 
searches: just enter "/128" destinations in the destination fields of 
that table and it works.

But AUTOCONF please don't recommend assignment of unique "/128" prefixes
on interfaces - that breaks too many things: fe80::/10 is not /128 and
worse, it's not unique and its mandatory; using SLAAC with any prefix 
longer than /64 won't work for IPv6-over-802154 and many other links, 
and more.

If AUTOCONF wants to put a "/128" prefix in an RA L==0 "off-link", then
(1) it should acknowledge the link definition of RFC4861 such that
"link" makes sense in "off-link" and (2) in no case should it configure
that "/128" prefix on any interface (because rfc4861 "off-link" means
the address is not assigned to any interface on specified _link_).

If AUTOCONF can't agree that "link" is what RFC4861 says it to be, then
"off-link" makes no sense, "link-local" makes no sense, and so on.

I can't understand "off-link" without first understanding "link".

Ignore "link" in any one one paragraph below and you break too many
other things:

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

"   Currently, IPv6 continues the IPv4 model in that a subnet prefix is
    associated with one link."

"   All interfaces are required to have at least one Link-Local unicast
    address (see Section 2.8 for additional required addresses)."

"   off-link    - the opposite of "on-link"; an address that is not
                  assigned to any interfaces on the specified link."

"   The details of forming interface identifiers are defined in the
     appropriate "IPv6 over <link>" specification, such as "IPv6 over
     Ethernet" [ETHER], and "IPv6 over FDDI" [FDDI]."

"     scop is a 4-bit multicast scope value used to limit the scope of
       the multicast group.  The values are as follows:

          0  reserved
          1  Interface-Local scope
          2  Link-Local scope"

Or are you about to build a new Internet here in AUTOCONF?

Alex

---

From: Thomas Heide Clausen <[email-masked]>
Date: Sat, 14 Nov 2009 05:43:02 +0900

Zach,

Thanks for Cc'ing [autoconf]. We're pleased that the document also is  
applicable in [6lowpan].

On Nov 14, 2009, at 4:30 AM, Zach Shelby wrote:

> throughout the LoWPAN to form addresses. It would be nice if  
> autoconf could update their wording somewhat, so let's see if that  
> is possible.

One of the comments from [autoconf] this time was to adopt a phrasing  
of "has no on-link prefix", as suggested by Dave Thaler, Sit tight, I  
think that an updated I-D should be forthcoming shortly.
Zach, if you have any additional comments, please do raise them also  
on [autoconf].

Thomas

>> please
>> configured
>> these
>> host-based routes aspects when talking "exact match" searches in  
>> its 6LoWPAN Terminology section, and please don't remove that from  
>> the 6lowpan-ND document.
>>
> Therefore we don't really assign the prefix to the interface. So in  
> practice the end result is the same as assigning a /128. Right? So  
> this is just a wording difference.
>
>>
>>> tell, the autoconf draft requires no functional changes to the  
>>> base mechanisms of our work. Again, we still need to look at the  
>>> details.
>>> Cheers, Zach
>>
>>
>
> -- 
> http://www.sensinode.com

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 13 Nov 2009 23:24:45 +0100

Thomas Heide Clausen a écrit :
> One of the comments from [autoconf] this time was to adopt a phrasing of 
> "has no on-link prefix", as suggested by Dave Thaler, Sit tight, I think 
> that an updated I-D should be forthcoming shortly.

Thomas, Dave - what do you mean by "on-link" prefix?  What do you mean 
by "link"?

"on-link" prefix is understood in settings where "link" is understood. 
Settings where "link" is not understood, "on-link" makes no sense 
whatsoever, as "off-link" doesn't either.

Alex

> Zach, if you have any additional comments, please do raise them also on 
> [autoconf].
> 
> Thomas
> 
> 
>> Some comments below.
>>

---

From: Thomas Heide Clausen <[email-masked]>
Date: Sat, 14 Nov 2009 07:32:14 +0900

On Nov 14, 2009, at 7:24 AM, Alexandru Petrescu wrote:

>> Thanks for Cc'ing [autoconf]. We're pleased that the document also  
>> is applicable in [6lowpan].
>> One of the comments from [autoconf] this time was to adopt a  
>> phrasing of "has no on-link prefix", as suggested by Dave Thaler,  
>> Sit tight, I think that an updated I-D should be forthcoming shortly.
>
> Thomas, Dave - what do you mean by "on-link" prefix?  What do you  
> mean by "link"?
>
> "on-link" prefix is understood in settings where "link" is  
> understood. Settings where "link" is not understood, "on-link" makes  
> no sense whatsoever, as "off-link" doesn't either.
>

Oh, but it does: it's a prefix which is not configured to be on a link  
-- which is a good idea as (as you state) the "link is not  
understood", beyond that we understand it well enough to realize that  
the connectivity properties are undetermined, and that therefore the  
use of an on-link prefix is inappropriate.

Thomas

> Alex
>
>
>> Zach, if you have any additional comments, please do raise them  
>> also on [autoconf].
>> Thomas
>>> Some comments below.
>>>
>>>>> have is
>>>> prefix
>>>> its 6LoWPAN Terminology section, and please don't remove that  
>>>> to "longest-prefix match") is terminology similar to "Basic  
>>>> Match" and "Longest Match" used in rfc1812.  Although the rfc is  
>>>> only IPv4 it also applies to IPv6.
>>>>
>>> Therefore we don't really assign the prefix to the interface. So  
>>> in practice the end result is the same as assigning a /128. Right?  
>>> So this is just a wording difference.
>>>
>>>>
>>>>> Routers do advertise the prefix used throughout the LoWPAN  
>>>>> (using RAs). And nodes may then auto-configure addresses based  
>>>>> on that.
>>>>
>>> So the autoconf text should say that you can should a /128 or a / 
>>> 64 when using SLAAC to make that explicitly OK?
>>>
>>> Zach
>>>
>>>>
>>>> Alex
>>>>
>>>>> It already works like this, no changes necessary. As far as I  
>>>>> can tell, the autoconf draft requires no functional changes to  
>>>>> the base mechanisms of our work. Again, we still need to look at  
>>>>> the details.
>>>>> Cheers, Zach
>>>>
>>>>
>>>
>>> -- 
>>> http://www.sensinode.com
>>> contain legally privileged information. If you are not the  
>>> intended recipient, please contact the sender and delete the e- 
>>> mail from your system without producing, distributing or retaining  
>>> copies thereof.
>>>
>>>
>>>

---

From: Alexandru Petrescu <[email-masked]>
Date: Sat, 14 Nov 2009 00:01:27 +0100

> Oh, but it does: it's a prefix which is not configured to be on a link

On a "link" as rfc4861 understands it?  Or on a "link" which has ABC 
problem?

Is it correct to say AUTOCONF prefix is not configured on a "link having 
A-B-C problem"?   Or is it more correct to say that AUTOCONF prefix is 
not configured on a "link which does not have the A-B-C problem"?

Both are correct?

> -- which is a good idea as (as you state) the "link is not understood", 
> beyond that we understand it well enough to realize that the 
> connectivity properties are undetermined, and that therefore the use of 
> an on-link prefix is inappropriate.

So you say on-link prefix is inappropriate on links we don't understand.

It doesn't imply off-link prefix is appropriate on such links.

BEcause "off-link" is already defined: "an address that is not assigned 
to any interfaces on the specified link", i.e. a link which is understood.

If the link is not understood then we can't say whether somethhing is on 
it or off it.  It may be on it, and also off it.

Alex

---

From: Jonathan Hui <[email-masked]>
Date: Wed, 18 Nov 2009 11:52:56 -0800

Splitting off the host-router portion into its own WG document is a  
good thing to do.

The question for me is what to do with the other half - specifically  
the DAD portion.

First, I do believe that having a completely separate mechanism solely  
for detecting duplicate addresses is unnecessary overhead in real  
production deployments.  In some cases, applications will accept the  
extremely low probability that a duplicate address will exist in the  
network.  In other cases, networks will have other mechanisms in place  
that can (and will) be used to assign unique identifiers (e.g. through  
commissioning, strong security associations, DHCPv6, etc.) within the  
proper scope which may be used to form unique IPv6 addresses.  If the  
identifiers are *assigned* in such a way to be unique, the added  
benefit of *detecting* failures in the assignment mechanism is  
marginal.  For these reasons, I think there is consensus in this  
working group that DAD should be optional at best.

Second, I'm not yet comfortable with the whiteboard mechanism, as  
specified in nd-07, becoming a WG document.  There is consensus in  
this WG that the whiteboard mechanism does not work in all scenarios  
and should be optional at best.  Given that, I think this WG needs to  
think more about the broader effects of specifying a particular way to  
do DAD while making it optional.  Having an option (or multiple  
options) could cause interoperability issues and confusion down the  
line.

Third, I'm not sure, frankly, that the whiteboard mechanism is  
something of broad interest to members of the WG.  Looking through the  
mailing lists, I haven't found much (any?) support for the whiteboard  
outside of the authors.  In fact, I have found more comments of  
concern.  I also don't think we've  even polled the WG about whether  
the whiteboard mechanism should be taken up in a WG document.

--
Jonathan Hui

---

From: JP Vasseur <[email-masked]>
Date: Thu, 19 Nov 2009 15:42:55 +0100

On Nov 18, 2009, at 8:52 PM, Jonathan Hui wrote:

> First, I do believe that having a completely separate mechanism  
> solely for detecting duplicate addresses is unnecessary overhead in  
> real production deployments.  In some cases, applications will  
> accept the extremely low probability that a duplicate address will  
> exist in the network.  In other cases, networks will have other  
> mechanisms in place that can (and will) be used to assign unique  
> identifiers (e.g. through commissioning, strong security  
> associations, DHCPv6, etc.) within the proper scope which may be  
> used to form unique IPv6 addresses.  If the identifiers are  
> *assigned* in such a way to be unique, the added benefit of  
> *detecting* failures in the assignment mechanism is marginal.  For  
> these reasons, I think there is consensus in this working group that  
> DAD should be optional at best.
>
> and should be optional at best.  Given that, I think this WG needs  
> to think more about the broader effects of specifying a particular  
> way to do DAD while making it optional.  Having an option (or  
> multiple options) could cause interoperability issues and confusion  
> down the line.
>
> something of broad interest to members of the WG.  Looking through  
> the mailing lists, I haven't found much (any?) support for the  
> whiteboard outside of the authors.  In fact, I have found more  
> comments of concern.  I also don't think we've  even polled the WG  
> about whether the whiteboard mechanism should be taken up in a WG  
> document.

strongly agreeing with all three points.

Thanks.

JP.

---

From: "Mathilde Durvy (mdurvy)" <[email-masked]>
Date: Thu, 19 Nov 2009 18:08:44 +0100

Hi Jonathan,

I fully agree with you.
Thanks for summarizing the points so well! 
 
Best,
Mathilde

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Jonathan Hui
Sent: mercredi, 18. novembre 2009 20:53
To: Carsten Bormann
Cc: 6lowpan
Subject: Re: [6lowpan] Way forward for 6LoWPAN-ND, consensus call

Splitting off the host-router portion into its own WG document is a good
thing to do.

The question for me is what to do with the other half - specifically the
DAD portion.

First, I do believe that having a completely separate mechanism solely
for detecting duplicate addresses is unnecessary overhead in real
production deployments.  In some cases, applications will accept the
extremely low probability that a duplicate address will exist in the
network.  In other cases, networks will have other mechanisms in place
that can (and will) be used to assign unique identifiers (e.g. through
commissioning, strong security associations, DHCPv6, etc.) within the
proper scope which may be used to form unique IPv6 addresses.  If the
identifiers are *assigned* in such a way to be unique, the added benefit
of *detecting* failures in the assignment mechanism is marginal.  For
these reasons, I think there is consensus in this working group that DAD
should be optional at best.

Second, I'm not yet comfortable with the whiteboard mechanism, as
specified in nd-07, becoming a WG document.  There is consensus in this
WG that the whiteboard mechanism does not work in all scenarios and
should be optional at best.  Given that, I think this WG needs to think
more about the broader effects of specifying a particular way to do DAD
while making it optional.  Having an option (or multiple
options) could cause interoperability issues and confusion down the
line.

Third, I'm not sure, frankly, that the whiteboard mechanism is something
of broad interest to members of the WG.  Looking through the mailing
lists, I haven't found much (any?) support for the whiteboard outside of
the authors.  In fact, I have found more comments of concern.  I also
don't think we've  even polled the WG about whether the whiteboard
mechanism should be taken up in a WG document.

--
Jonathan Hui

---

From: "Julien Abeille (jabeille)" <[email-masked]>
Date: Thu, 19 Nov 2009 18:30:27 +0100

Hi Jonathan, 

I could not have said it better.

Best,
Julien

> [mailto:[email-masked]] On Behalf Of Jonathan Hui
> Sent: mercredi 18 novembre 2009 20:53
> To: Carsten Bormann
> Cc: 6lowpan
> Splitting off the host-router portion into its own WG 
> document is a good thing to do.
> 
> The question for me is what to do with the other half - 
> specifically the DAD portion.
> 
> First, I do believe that having a completely separate 
> mechanism solely for detecting duplicate addresses is 
> unnecessary overhead in real production deployments.  In some 
> cases, applications will accept the extremely low probability 
> that a duplicate address will exist in the network.  In other 
> cases, networks will have other mechanisms in place that can 
> (and will) be used to assign unique identifiers (e.g. through 
> commissioning, strong security associations, DHCPv6, etc.) 
> within the proper scope which may be used to form unique IPv6 
> addresses.  If the identifiers are *assigned* in such a way 
> to be unique, the added benefit of *detecting* failures in 
> the assignment mechanism is marginal.  For these reasons, I 
> think there is consensus in this working group that DAD 
> Second, I'm not yet comfortable with the whiteboard 
> mechanism, as specified in nd-07, becoming a WG document.  
> There is consensus in this WG that the whiteboard mechanism 
> does not work in all scenarios and should be optional at 
> best.  Given that, I think this WG needs to think more about 
> the broader effects of specifying a particular way to do DAD 
> options) could cause interoperability issues and confusion 
> down the line.
> 
> Third, I'm not sure, frankly, that the whiteboard mechanism 
> is something of broad interest to members of the WG.  Looking 
> through the mailing lists, I haven't found much (any?) 
> support for the whiteboard outside of the authors.  In fact, 
> I have found more comments of concern.  I also don't think 
> we've  even polled the WG about whether the whiteboard 
> conversations 
> node-initiated, which 
> three of

---

From: Zach Shelby <[email-masked]>
Date: Thu, 19 Nov 2009 22:55:58 +0200

On Nov 18, 2009, at 21:52 , Jonathan Hui wrote:
> 
> The question for me is what to do with the other half - specifically the DAD portion.

The right question to ask is - What should be the goal of the other half? 

> 
> First, I do believe that having a completely separate mechanism solely for detecting duplicate addresses is unnecessary overhead in real production deployments.  In some cases, applications will accept the extremely low probability that a duplicate address will exist in the network.  In other cases, networks will have other mechanisms in place that can (and will) be used to assign unique identifiers (e.g. through commissioning, strong security associations, DHCPv6, etc.) within the proper scope which may be used to form unique IPv6 addresses.  If the identifiers are *assigned* in such a way to be unique, the added benefit of *detecting* failures in the assignment mechanism is marginal.  For these reasons, I think there is consensus in this working group that DAD should be optional at best.

I agree that uniqueness of addresses within a LoWPAN is necessary, and that can be assured in many ways. There will be networks where the uniqueness of addresses must be checked with some mechanism. The base 6lowpan-nd document shouldn't tell how this uniqueness is determined. But checking for uniqueness should use very strong wording in that document, with an opt-out if you are sure addresses have been assigned properly. Note this must be an opt-out rather than an opt-in. 

> 
> Second, I'm not yet comfortable with the whiteboard mechanism, as specified in nd-07, becoming a WG document.  There is consensus in this WG that the whiteboard mechanism does not work in all scenarios and should be optional at best.  Given that, I think this WG needs to think more about the broader effects of specifying a particular way to do DAD while making it optional.  Having an option (or multiple options) could cause interoperability issues and confusion down the line.

It would not make sense to use the nd-07 mechanisms exactly as specified now after the split. Multiple options is not the problem - as you say above - there will be a wide variety of ways to insure the uniqueness of addresses. The problem I see is that just defining the whiteboard on its own only for DAD doesn't make much sense, so there we can agree. 

We should instead call the second document "Extended LoWPAN", and have it define a mechanism only for enabling Extended LoWPANs. Extended LoWPANs require a binding cache of some kind at each ER (called a whiteboard or whatever), as in the original backbone router draft. As a side-effect of registering with the Extended LoWPAN mechanism, you are also able to determine the uniqueness of an address. So this would not be specified for use as DAD on its own.   

> 
> Third, I'm not sure, frankly, that the whiteboard mechanism is something of broad interest to members of the WG.  Looking through the mailing lists, I haven't found much (any?) support for the whiteboard outside of the authors.  In fact, I have found more comments of concern.  I also don't think we've  even polled the WG about whether the whiteboard mechanism should be taken up in a WG document.

The 6lowpan-nd document was taken as a WG document already a year ago, and its main mechanism was (also then) based on registration to a whiteboard. A cache such as a whiteboard is a means to an end... are people using RFC4861 really deeply interested in neighbor caches? 

The goal of the second document should be the Extended LoWPAN feature and what it enables. For me this is an important feature,  and I have heard many planning to take advantage of it.

Zach

-- 
http://www.sensinode.com
http://zachshelby.org - My blog "On the Internet of Things"
http://6lowpan.net - New book - "6LoWPAN: The Wireless Embedded Internet"
Mobile: +358 40 7796297

Zach Shelby
Head of Research
Sensinode Ltd.
Kidekuja 2
88610 Vuokatti, FINLAND

This e-mail and all attached material are confidential and may contain legally privileged information. If you are not the intended recipient, please contact the sender and delete the e-mail from your system without producing, distributing or retaining copies thereof.

---

From: Jonathan Hui <[email-masked]>
Date: Thu, 19 Nov 2009 16:01:03 -0800

> The right question to ask is - What should be the goal of the other  

The goal will drive what to do.

>> these reasons, I think there is consensus in this working group  
>> that DAD should be optional at best.
>
> I agree that uniqueness of addresses within a LoWPAN is necessary,  
> and that can be assured in many ways. There will be networks where  
> the uniqueness of addresses must be checked with some mechanism. The  
> base 6lowpan-nd document shouldn't tell how this uniqueness is  
> determined. But checking for uniqueness should use very strong  
> wording in that document, with an opt-out if you are sure addresses  
> have been assigned properly. Note this must be an opt-out rather  
> than an opt-in.

So we agree that it's optional.

>> this WG that the whiteboard mechanism does not work in all  
>> scenarios and should be optional at best.  Given that, I think this  
>> WG needs to think more about the broader effects of specifying a  
>> particular way to do DAD while making it optional.  Having an  
>> option (or multiple options) could cause interoperability issues  
>> and confusion down the line.
>
> It would not make sense to use the nd-07 mechanisms exactly as  
> specified now after the split. Multiple options is not the problem -  
> as you say above - there will be a wide variety of ways to insure  
> the uniqueness of addresses. The problem I see is that just defining  
> the whiteboard on its own only for DAD doesn't make much sense, so  
> there we can agree.

Options is a problem if not dealt with properly.  For example, can a  
node that does not implement the "whiteboard protocol" (for lack of a  
better name)  participate in a network that requires the use of the  
"whiteboard protocol"?  Specifying the "whiteboard protocol" (or any  
other mechanism) now would almost make it required to be implemented  
by all lowpan routers to ensure interoperability in networks that  
depend on it.  This is what concerns me and I admit that I don't have  
a good solution to the problem.

> We should instead call the second document "Extended LoWPAN", and  
> have it define a mechanism only for enabling Extended LoWPANs.  
> Extended LoWPANs require a binding cache of some kind at each ER  
> (called a whiteboard or whatever), as in the original backbone  
> router draft. As a side-effect of registering with the Extended  
> LoWPAN mechanism, you are also able to determine the uniqueness of  
> an address. So this would not be specified for use as DAD on its own.

The call for consensus cited DAD as the primary reason for separating  
the whiteboard mechanism.  Pascal's individual submission on  
whiteboards cited many additional (and good) benefits, but many of  
those were dependent on having mesh-under and become lost with route- 
over.  When operating mesh-under, I see lots of value for the  
whiteboard.  But, I'm mostly interested in route-over networks, so can  
you list what additional features the whiteboard mechanism provides in  
addition to DAD?

> The 6lowpan-nd document was taken as a WG document already a year  
> ago, and its main mechanism was (also then) based on registration to  
> a whiteboard. A cache such as a whiteboard is a means to an end...  
> are people using RFC4861 really deeply interested in neighbor caches?

I tried looking for the call for consensus in the archives, but could  
not find it.  I also tried to see if there was a consensus call on  
what we would put in the draft, but could not find it either.  What I  
did find were objections to having a whiteboard mechanism.  Correct me  
if I'm wrong, but if it's true then skipping these steps was a  
mistake.  Now that we are splitting the document, we should at least  
do a call for consensus on creating these new WG drafts.  As far as I  
can tell, this call for consensus is pretty close to that.

That said, the real issue for me is not that people are interested in  
neighbor caches, the real issue is that there are people who see  
little added value in the whiteboard mechanism for many of the reasons  
I cited earlier.

> The goal of the second document should be the Extended LoWPAN  
> feature and what it enables. For me this is an important feature,   
> and I have heard many planning to take advantage of it.

It would be good to hear from those who would like to actively work on  
this whiteboard feature to speak up.  There has been little feedback  
on the whiteboard mechanism on the mailing list.  As an author, I can  
say that nearly all of the discussion on the mailing list is among 4-5  
authors.  I feel uncomfortable with a WG document that is not  
supported/reviewed/edited by a good number of WG members outside the  
authors.  So it would be certainly help to get more input from other  
WG members about what to do with the whiteboard mechanism.

--
Jonathan