Zach Shelby a écrit :
On Nov 12, 2009, at 16:55 , Alexandru Petrescu wrote:
Ulrich Herberg a écrit :
Alex,
On Thu, Nov 12, 2009 at 7:49 PM, Alexandru Petrescu
<alexandru.petre...@gmail.com> wrote:
[...]
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.
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, 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)
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.
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.
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).
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
Zach
Alex
_______________________________________________
6lowpan mailing list
6lowpan@ietf.org
https://www.ietf.org/mailman/listinfo/6lowpan
--- Begin Message ---
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
_______________________________________________
6lowpan mailing list
6lowpan@ietf.org
https://www.ietf.org/mailman/listinfo/6lowpan
--
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.
--- End Message ---
_______________________________________________
6lowpan mailing list
6lowpan@ietf.org
https://www.ietf.org/mailman/listinfo/6lowpan
