Subject: [Autoconf] A description for a link-type of interest

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 12 Mar 2008 12:11:49 -0700

Hello folks,

At the meeting I heard that it would be good
idea for document authors to make a description
of the types of links that their solution was
intended to work over.  Here is a first attempt
to describe the links over which our solution
(including a sort of multi-link NDP) should
work.

Properties of "link" for multi-hop NDP solution
[Wakikawa/Perkins]

- Subnet aggregation is not necessarily easy
 to define, and so we do not rely on the
 traditional properties of subnets

- Nodes can transmit IP packets to "neighbors",
 which are directly accessible via local
 communications channels established by layer-1
 and layer-2 protocols

- A node's physical broadcasts are detectable
 by all nodes that are sufficiently close by and
 equipped with the requisite hardware (e.g,
 demodulators, amplifiers, transducers, etc.)

- Multicast groups may be defined, but for sparse
 multicast groups there may not be any existing
 mechanism for multicast tree maintenance.
 Dense multicast groups may be handled by
 flooding.  Local/neighborhood multicast groups
 are handled by physical broadcasts which are
 not forwarded.

===============================

Regards,
Charlie P.

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

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 14 Mar 2008 00:12:21 +0100

Hi Charlie, and thanks for the beginning of this description.

One general question upfront: can these links be mapped conceptually to
an existing layer-2?  Can I think that the links you describe below
have, to some extent, some relationship with 802.3 MAC?

Charles E. Perkins wrote:
> Hello folks,
> 
> At the meeting I heard that it would be good idea for document 
> authors to make a description of the types of links that their 
> solution was intended to work over.  Here is a first attempt to 
> describe the links over which our solution (including a sort of 
> multi-link NDP) should work.
> 
> Properties of "link" for multi-hop NDP solution [Wakikawa/Perkins]
> 
> - Subnet aggregation is not necessarily easy to define, and so we do
>  not rely on the traditional properties of subnets

What does this mean?  I am not sure about subnet aggregation is easily
defined for traditional links in first place.  I know about IPv6
aggregation of prefixes, but I'm not sure about subnet aggregation.

> - Nodes can transmit IP packets to "neighbors", which are directly 
> accessible via local communications channels established by layer-1 
> and layer-2 protocols

I understand this.

> - A node's physical broadcasts are detectable by all nodes that are 
> sufficiently close by and equipped with the requisite hardware (e.g, 

I understand this.  I guess IP doesn't care much about mac  (layer-2)
having to replicate broadcast packets such as to reach neighbors that
are not visible at phy (layer-1).

> - Multicast groups may be defined, but for sparse multicast groups 
> there may not be any existing mechanism for multicast tree 
> maintenance. Dense multicast groups may be handled by flooding. 
> Local/neighborhood multicast groups are handled by physical 
> broadcasts which are not forwarded.

I'm looking at this from a Ethernet MAC-layer multicast perspective and
I don't think there may be needs for dense vs sparse group separation,
just have simple groups in the beginning.  I'd reserve the dense/sparse
separation when we know more precisely the type of one link, then we
combine links and see this separation.

-------

As a side note, including this in this same thread: Emmanuel said at the
meeting that the AUTOCONF subnets are different from subnets where
DHCP/ND can be run, mostly because they move around.  Can we discuss
that movement aspect Emmanuel has mentioned into this link-type description?

For example, assume I talk about AUTOCONF link type.  AUTOCONF links
move around.  Whenever they move around, layer-1 and layer-2 make sure
AUTOCONF link-type look as a 802.3 MAC to the IP layer, thus hiding that
appearance of movement from IP.  Is this a safe assumption?  If it's not
a safe assumption then what kind of movement breaks what.

Just some comments,

Alex

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________
_______________________________________________
Autoconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/autoconf