Subject: [Autoconf] [CFP] IEEE MASS 2008: Submission open (deadline March 14, 2008)

From: "Pedro M. Ruiz" <[email-masked]>
Date: Thu, 07 Feb 2008 09:24:09 +0100

-------------------------------------------------------

                        CALL FOR PAPERS

                         IEEE MASS 2008
             Fifth IEEE International Conference on
                Mobile Ad-hoc and Sensor Systems

                 September 29 ? October 2, 2008
                         Hilton Atlanta
                        Atlanta, GA, USA

              http://www.cse.psu.edu/IEEEMASS08/

Sponsors: IEEE, IEEE Computer Society, IEEE Technical Committee on
Distributed
Processing, IEEE Technical Committee on Simulation, and IEEE Technical
Committee
on Computer Communications

Wireless ad-hoc communication has applications in a variety of
environments,
such as conferences, hospitals, battlefields and disaster-recovery/rescue
operations, and is also being actively investigated as an alternative
paradigm
for Internet connectivity in both urban and rural areas. Wireless sensor
and
actuator networks are also being deployed for enhancing industrial control
processes and supply-chains, and for various forms of environmental
monitoring.
The IEEE MASS 2008 conference is the fifth edition of MASS and aims at
addressing
advances in research on multi-hop ad-hoc and sensor networks, covering
topics
ranging from technology issues to applications and test-bed development.

IEEE  MASS 2008  solicits riginal, unpublished contributions  in all
aspects of
(mobile) ad-hoc networks and wireless sensor networks (WSN), systems and
applications. Submitted articles must not be concurrently considered
elsewhere
for publication. Extended versions of selected papers will be considered
for
fast track publication in the Pervasive and Mobile Computing Journal
(www.elsevier.come/locate/pmc).

Scope: Topics include, but are not limited to:

- Physical layer impact on higher layers in ad-hoc networks and WSNs
- Directional / smart antennas
- Multi-channel, multi-radio and MIMO technologies
- MAC protocols (802.11, 802.15.4, UWB)
- Wireless mesh networks and cognitive networks
- P2P/overlay/content distribution architectures for wireless ad hoc
networks
- Delay tolerant networks and opportunistic networking
- Vehicular networks and protocols
- Mobile/robotic sensor networks
- Power-aware architectures, algorithms and protocols design
- Clustering, topology control, coverage and connectivity issues
- Routing protocols (unicast, multicast, broadcast, geocast)
- Data transport, management and information scheduling
- Data gathering, fusion, and dissemination in WSNs
- Localization, synchronization and cooperative sensing in WSNs
- Sensor networks and pervasive infrastructures
- Capacity planning and admission control in ad-hoc networks
- Handoff / mobility management and seamless internetworking
- Resource management and wireless QoS Provisioning
- Cross layer design and optimization
- Incentive-based and game-theoretic approaches in ad-hoc networks
- Reliability, resiliency and fault tolerance techniques
- Security, privacy, and trust issues
- Management and monitoring of ad-hoc and sensor networks
- Operating systems and middleware support
- Novel applications and architectures for WSNs
- Modeling, analysis and performance evaluation
- Measurements and experience from experimental systems and test-beds

Submission Guidelines:

All submissions must be full papers in PDF format and uploaded on EDAS.
Direct link for paper submission (abstracts due within March 14, 2008):
               http://www.edas.info/newPaper.php?c=6118&
They must not exceed 10 single-spaced, double-column pages using at least
11 pt size fonts on 8.5 x 11 inch pages in IEEE style format.
Detailed formatting and submission instructions will be available on the
conference website.

WORKSHOP Proposals:
Workshop proposals are solicited on cutting-edge topics that complement
or supplement the main theme of IEEE MASS 2008. Please contact the
Workshop Co-chairs with proposals or for any questions.
The submission deadline is Feb 15.

DEMO Proposals:
Proposals are solicited for technical demonstrations of experimental ad-hoc
and sensor networking systems. Visit the conference website for
instructions on submitting demo proposals or contact the Demo Chair.

PAPER Submission Deadlines:
   Abstracts Due:           March 14, 2008
   Manuscripts Due:         March 21, 2008
   Acceptance Notification: June 20, 2008
   Camera-ready Submission: July 18, 2008

ORGANIZING COMMITTEE

GENERAL Chair
Tom La Porta, Pennsylvania State University, USA (tlp at cse.psuedu)

PROGRAM Chair
Sajal K. Das, The University of Texas at Arlington, USA (das at uta.edu)

TPC Vice Chairs
Luciano Bononi, University of Bologna, Italy (bononi at cs.unibo.it)
Archan Misra, IBM Watson Research Center, USA (archan at us.ibm.com)
Chunming Qiao, University of Buffalo, USA (qiao at cse.buffalo.edu)

WORKSHOP Co-Chairs
Yonghe Liu, University of Texas at Arlington, USA (yonghe at cse.uta.edu)
Sencun Zhu, Pennsylvania State University, USA (szhu at cse.psu.edu)

FINANCE & REGISTRATION Chair:
Anup Kumar, University of Louisville, USA

PUBLICATION Chair
Dajin Wang, Montclair State University, USA

PUBLICITY Co-Chairs
Sunghyun Choi, Seoul National University, Korea (schoi at snu.ac.kr)
Murat Demirbas, University of Buffalo, USA (demirbas at cse.buffalo.edu)
Pedro Ruiz, University of Murcia, Spain (pedrom at dif.um.es)

LOCAL ARRANGEMENTS Chair
George Riley, Georgia Tech, USA (riley at ece.gatech.edu)

WEB Chair
Sharanya Eswaran, Pennsylvania State Univ, USA (eswaran at cse.psu.edu)

STEERING COMMITTEE Co-chairs
Dharma P. Agrawal, University of Cincinnati, USA
Jie Wu (TCDP), Florida Atlantic University & NSF, USA

TECHNICAL PROGRAM COMMITTEE

Nael Abu-Ghazaleh, State University of New York at Binghamton, USA
Prathima Agrawal, Auburn University, USA
Ian Akyildiz, Georgia Institute of Technology, USA
Kevin Almeroth, University of California at Santa Barbara
Giuseppe Anastasi, University of Pisa, Italy
Stefano Basagni, Northeastern University, USA
Elizabeth Belding, University of California at Santa Barbara, USA
Brahim Bensaou, Hong Kong Univ. of Science and Technology, Hong Kong
Amiya Bhattacharya, New Mexico State University, USA
Douglas Blough, Georgia Institute of Technology, USA
Luciano Bononi, University of Bologna, Italy
Azzedine Boukerche, University of Ottawa, Canada
Joel Branch, IBM Watson Research Center, USA
Raffaele Bruno, IIT?CNR, Pisa, Italy
Levente Buttyan, CrySys lab, Budapest Univ. of tech. and econ., Hungary
Guohong Cao, Pennsylvania State University, USA
Jiannong Cao, Hong Kong Polytechnic University, Hong Kong
Antonio Capone, Politecnico di Milano, Italy
Mainak Chatterjee, University of Central Florida, USA
Guihai Chen, Nanjing University, China
Hsiao-Hwa Chen, National Sun Yat-Sen University, Taiwan
Yanghee Choi, Seoul National University, Korea
Chun Tung Chou, University of New South Wales, Australia
Amitabha Das, Nanyang Technological University, Singapore
Sajal K. Das, The University of Texas at Arlington, USA
Swades De, Indian Institute of Technology, India
Murat Demirbas, State University of New York at Buffalo, USA
Falko Dressler, University of Erlangen, Germany
Eylem Ekici, Ohio State University,USA
Karoly Farkas, University of West Hungary, Hungary
Laura Feeney, Swedish Institute of Computer Science, Sweden
Ratan Ghosh, Indian Institute of Technology at Kanpur, India
Silvia Giordano, University of Applied Science ?(SUPSI), Switzerland
Mesut G?nes, Computer Science, Freie Universit?t Berlin, Germany
Zygmunt Haas, Cornell University, USA
Qi Han, Colorado School of Mines, USA
Paul Havinga, University of Twente, The Netherlands
Tian He, University of Minnesota, USA
Sanjay Jha, University of New South Wales, Australia
Xiaohua Jia, City University of Hong Kong, Hong Kong
Vana Kalogeraki, University of California at Riverside, USA
Koushik Kar, Rensselaer Polytechnic Institute, USA
Holger Karl, University of Paderborn, Germany
Sneha Kasera, University of Utah, USA
Young-Bae Ko, Ajou University, Korea
Sastry Kompella, Naval Research Laboratory, USA
Farinaz Koushanfar, Rice University, USA
Evangelos Kranakis, Carleton University, Canada
Bhaskar Krishnamachari, University of Southern California, USA
Sudha Krishnamurthy, Deutsche Telekom Laboratories, Germany
Taekyoung Kwon, Seoul National University, Korea
Tom La Porta, Pennsylvania State University, USA
Sung-Ju Lee, HP Labs, USA
Qilian  Liang, The University of Texas at Arlington, USA
Weifa Liang, Australian National University, Australia
Lavy Libman, NICTA, Sydney, Australia
Yonghe Liu, The University of Texas at Arlington, USA
Yunhao Liu, Hong Kong University of Science and Technology, Hong Kong
Cecilia Mascolo, University College London,     UK
Martin Mauve, Heinrich Heine University, D?sseldorf, Germany
Ciaran Mc Goldrick, Trinity College at Dublin,  Ireland
Tommaso Melodia, State University of New York at Buffalo, mUSA
Jelena Misic, University of Manitoba, Canada
Archan Misra, IBM Watson Research Center, USA
Mehul Motani, National University of Singapore, Singapore
Farid Na?t-Abdesselam, University of Sciences and Tech. of Lille, France
Peng Ning, North Carolina State University, USA
Sergio  Palazzo, University of Catania, Italy
Jos? Parente de Oliveira, ITA, Brazil
Andrea  Passarella, IIT-CNR, Pisa, Italy
Dirk Pesch, Cork Institute of Technology, Ireland
Chiara  Petrioli, University of Rome "La Sapienza", Italy
Tien Pham, Army Research Laboratory, USA
Cristina M. Pinotti, University of Perugia, Italy
Dario Pompili, Rutgers  University, The State Univ. of New Jersey, USA
Ravi Prakash, University of Texas at Dallas, USA
Chunming Qiao, State University of New York at Buffalo, USA
Lili Qiu, The University of Texas at Austin, USA
Milena  Radenkovic, University of Nottingham, UK
Fengyuan Ren, Tsinghua University, China
Pedro Ruiz, University of Murcia, Spain
Weisong Shi, Wayne State University, USA
Yi Shi, Virginia Tech, USA
Rajeev  Shorey, General Motors Research, India
David Simplot-Ryl, INRIA & University of Lille, France
Raghupathy Sivakumar, Georgia Institute of Technology, USA
Krishna Sivalingam, University of Maryland at Baltimore County, USA
Harry Skianis, National Centre for Scientific Res. 'Demokritos', Greece
Cormac Sreenan, University College of Cork, Ireland
Vikram Srinivasan, Bell Labs Research, India
Violet Syrotiuk, Arizona State University, USA
Vic Thomas, Honeywell, USA
Ozan Tonguz, Carnegie Mellon University, USA
Wade Trappe, Rutgers University, The State Univ. of New Jersey, USA
Yu-Chee Tseng, National Chiao-Tung University, Taiwan
Roberto Verdone, University of Bologna, Italy
Mehmet  Vuran, University of Nebraska-Lincoln, USA
Carlos Becker Westphall, Federal University of Santa Catarina, Brazil
Hongyi  Wu, University of Louisiana at Lafayette, Louisiana
Wendong Xiao, Institute for Infocomm Research, Singapore
Wensheng Zhang, Iowa State University, USA
Sheng Zhong, State University of New York at Buffalo, USA
Yanmin  Zhu, Imperial College of London, UK
Michele Zorzi, Universit? degli Studi di Padova, Italy

-- 
---------------------------------------------------------------------
Pedro M. Ruiz, Ph.D, MIEEE.             E-mail: [email-masked]
Fac. Informatica, Univ. of Murcia       Phone:  +34968364335
Campus de Espinardo s/n                 Fax:    +34968364151
E-30100, Espinardo, Murcia              www: ants.dif.um.es/~pedrom/
SPAIN
---------------------------------------------------------------------

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

---

From: Emmanuel Baccelli <[email-masked]>
Date: Mon, 18 Feb 2008 16:35:27 +0100

Hi all,

an updated version of the problem statement is available at the 
following URL:

http://wiki.emmanuelbaccelli.org/uploads/Ietf/draft-ietf-autoconf-problem-statement-04-PREVIEW-5.txt

Your review is needed in order for the document to go forward. Please 
provide your feedback this week -- the cut-off date being next Monday. 
The document is short (20 pages), so don't refrain!

Thanks, and see you soon in Philadelphia.

Emmanuel

---

From: "Teco Boot" <[email-masked]>
Date: Mon, 18 Feb 2008 21:19:50 +0100

Hi Emanuel,

Thanks for the new draft.
I think the document is largely improved.
Here some comments:

Page 4; Network merging:
Why not using "MANET merging"?
Same for Network partitioning.
And why using term "disconnected MANETs"? What is the difference with
"Autonomous MANETs"?

Page 6; 3.1.1.
I think Car-to-car communication is more or less an autonomous MANET, where
car-to-infrastructure is an example of a subordinate MANET.
c/Car-to-car communication networks/Vehicle communication networks/ ??

Page 7; 3.2.1.
c/inapproriate/ inappropriate/  

Page 8; 4. 3.
c/face/case/

Page 10; 5.1.2.
I don't think correctly operating DHCP servers will provide non-unique IP
addresses. Why is this suggested?
I would say each DHCP server manages its own pool of addresses and it will
never offer addresses or prefixes with already active leases.
Same remark on page 11 - 5.3.2

Page 11; 5.3.2
When IP connectivity exists between a MANET Router and a DHCP Server (set up
by whatever mechanism), what is the problem with DHCP-PD? I can't follow.

Page 12; R 02
First, the term prefix. I think this term is used in another context as
RFC4291. In RFC4291 a prefix is simply the subnet part of an address. In
this document, we specify that a prefix is some kind a aggregate of subnets.
I like this approach, as aggregating may reduce routing protocol overhead.
But using the same term for two purposes is confusing.
Second, I think the aggregated prefix allocation is a bootstrap problem
(onetime shot) and I am not sure if this requirement is a "must" in the
MANET Autoconf context. I think also the allocated prefixes are to be used
for the non-MANET interfaces on a MANET Router. I think current protocols
for prefix delegation can be used, under the condition that the requirements
for MANET address autoconfiguration are fulfilled.

Page 12; R 05
c/asymetry/asymmetry/

CU@philly,
Teco

> -----Oorspronkelijk bericht-----
> Van: [email-masked] [mailto:[email-masked]]
> Namens Emmanuel Baccelli
> Verzonden: maandag 18 februari 2008 16:35
> Aan: [email-masked]
> Onderwerp: [Autoconf] AUTOCONF Problem Statement: reviews needed.
> 
> Hi all,
>

---

From: Emmanuel Baccelli <[email-masked]>
Date: Tue, 19 Feb 2008 13:08:49 +0100

Hi Teco,

thanks for your feedback. Judging from its substance, it seems we have 
made great progress! Comments are inline:

Emmanuel

Teco Boot a écrit :
 > Hi Emmanuel,

Nework merging can happen between two subordinate MANETs (you would then 
get a multihomed MANET). The definition of "network merging" may be 
useful to networks in general, not just MANETs.

 > c/Car-to-car communication networks/Vehicle communication networks/ ??

Yes I agree. Maybe it is a clearer way to put it.

 > Same remark on page 11 - 5.3.2

Yes. But an issue may arise if the pools of addresses of multiple DHCP 
servers in the same MANET are not disjoint. This is the issue that is 
raised.

 > by whatever mechanism), what is the problem with DHCP-PD? I can't follow.

Well, you are basically dependent on a routing protocol of sorts then, no?

 > for MANET address autoconfiguration are fulfilled.

Well this requirement is basically a direct translation of what is 
specified in the MANET arch document. So I guess that if we want to have 
this discussion, we should take it there first. But I am not sure this 
is relevant in that this discussion already happened I guess.

---

From: Thomas Clausen <[email-masked]>
Date: Tue, 19 Feb 2008 14:54:14 +0100

Emmanuel, Teco,

Emmanuel, I assume that the items that you have not commented on are  
already, or will soon be, integrated into an updated I-D?

A couple of comments to the issues Teco brought forward below.

>> I think the document is largely improved.

Agreed - and thanks, Teco (and all of you) for making that happen.

> useful to networks in general, not just MANETs.

Teco has a point in as much as a "multihomed subordinate MANET  
emerging from two formerly single-homed subordinate MANETs" might be  
(or be seen) as different from " a large autonomous MANET emerging  
from two formerly autonomous and not connected MANETs". It might be  
worth exploring in the document if and how (or, if not, why not) such  
are different.

Good catch - Teco, Emmanuel, do you have opinions on this (the  
substance, that is)?

<SNIP>

I'm actually glad to see that Teco's main comments are to section 5  
and forward, since that's probably where we need eyes to help  
understand if the essentials are correctly captured.

> servers in the same MANET are not disjoint. This is the issue that is

Just to clarify: Emmanuel, are you suggesting that two DHCP servers  
"share" a pool of addresses, without co-ordinating leases with each  
other? Does that happen? I think Teco is right in that it doesn't,  
unless something is broken elsewhere? Or, are you talking about the  
situation in which this co-ordination happens only through the MANET,  
which becomes disconnected?

> Well, you are basically dependent on a routing protocol of sorts  

Hu-humm.....DHCP proxies and promiscuous abuse of broadcasting seems  
an off-the-cuff way to make it happen without a routing protocol as  
such. Or (and someone *will* object, but I have seen it done) simple  
classical flooding of any and all DHCP traffic, blatantly ignoring  
address scopes and hop-limits.

In other words, I can imagine ways where no routing protocol as such  
is required - granted, I do not recommend any of those in the  
abbreviated form stated above. The question is as to if the issue is  
captured correctly in the I-D (i.e. does IP connectivity exist  
between a MANET router and a DHCP server in the scenarios envisioned?  
If not, we need to explain that, plus why. If yes, then Teco seems to  
be right ;) )

Thomas

---

From: Emmanuel Baccelli <[email-masked]>
Date: Tue, 19 Feb 2008 15:35:43 +0100

Hi Thomas,

I beleive that I commented every item, except spelling-related comments, 
or did I miss something? Anyways, my further comments are inline:

Thomas Clausen a écrit :
> Teco has a point in as much as a "multihomed subordinate MANET emerging 
> from two formerly single-homed subordinate MANETs" might be (or be seen) 
> as different from " a large autonomous MANET emerging from two formerly 
> autonomous and not connected MANETs". It might be worth exploring in the 
> document if and how (or, if not, why not) such are different.
> 

I think this scenario distinction has nothing to do with the definition 
of network merging. As far as scenarios are concerned, the draft as it 
is now classifies the resulting merged MANET as such:
(i) is it autonomous or subordinate? If it is subordinate, is it multihomed?
(ii) are pre-configured addresses or prefixes are creating duplication 
conflicts?
(iii) if it is subordinate, are pre-configured addresses or prefixes 
against topology correctness?

I am wondering what other classification/exception we should incorporate 
in addition? Maybe this is sufficient?

> <SNIP>
> 
> I'm actually glad to see that Teco's main comments are to section 5 and 
> forward, since that's probably where we need eyes to help understand if 
> the essentials are correctly captured.
> 
>>>
>>> Page 10; 5.1.2.

I am saying that if two previously independent MANETs merge, each MANET 
having its own DHCP server, there is no assurance that the pools of 
"local" addresses they each manage are indeed disjoint, is there? 
Duplication issues may thus arise after the merge, and DHCP does not 
have a mechanism to dynamically re-configure servers in such cases.

> Hu-humm.....DHCP proxies and promiscuous abuse of broadcasting seems an 
> off-the-cuff way to make it happen without a routing protocol as such. 
> Or (and someone *will* object, but I have seen it done) simple classical 
> flooding of any and all DHCP traffic, blatantly ignoring address scopes 
> and hop-limits.
> 
> In other words, I can imagine ways where no routing protocol as such is 
> required - granted, I do not recommend any of those in the abbreviated 
> form stated above. The question is as to if the issue is captured 
> correctly in the I-D (i.e. does IP connectivity exist between a MANET 
> router and a DHCP server in the scenarios envisioned? If not, we need to 
> explain that, plus why. If yes, then Teco seems to be right ;) )

I see. Maybe we could be clearer on this point then. How about adding a 
specific sentence in 5.3.2, like  "if the topology is or becomes such 
that a MANET router cannot communicate with a DHCP server, DHCP-PD is 
not operational." What do you think?

Emmanuel

---

From: Emmanuel Baccelli <[email-masked]>
Date: Tue, 19 Feb 2008 15:38:54 +0100

BTW, the security considerations need special attention while reviewing 
the document. So please do NOT skip this section ;) as we definitely 
need to hear some feedback on this.

Emmanuel

---

From: "Teco Boot" <[email-masked]>
Date: Wed, 20 Feb 2008 11:56:15 +0100

Hi,

Some comments inline.

I have more thoughts which I did not mention in my first response:

On uniqueness validation, I posted before my reservations on active DAD. In
many cases, this is not needed. RFC4862:
>  To accommodate
>  sites that believe the overhead of performing Duplicate Address
>  Detection outweighs its benefits, the use of Duplicate Address
>  Detection can be disabled through the administrative setting of a
>  per-interface configuration flag.
The old version of our Problem Statement had some text on this.

On multi-homed subordinate MANETs, the current document does not describe
this scenario in detail. It is just an instance of a subordinate MANET, as
this category is described with "is connected to at least one external
network N".
I think multi-homed subordinate MANET scenario introduces a large, new
problem which is related to the selection mechanism of the path to one of
the external networks. This path selection is out-of-control for Autoconf,
as it is up to the (MANET) routing protocol to find out the path to the
destination.
Scenario:

                   '.                           /
                    `.        Network N        /   Topologically correct
                      `.                    _,'          prefix q:: with
  Topologically correct `-.__           _,,'        respect to network M
        prefix p:: with      `'-.,._,,''                    ___
   respect to network N          :                       ,-´
                               +-:-+                    /    
                               |MNR|                   ;    N
                               +-|-+                  /     E
              +-+  +---+ /      /|\       \ +---+     ;     T 
              | |...MNR---       .-.      ---MNR:.....,     W
              +-+  +---+ \    ,-(  _)-.   / +---+     !     O
                           .-(_ MANET  )-.            !     R
              Other       ( Communication )           :     K
              Nodes          `-(______)-'              \   
              and         \|/             \|/           :   M
              Networks   +-|-+           +-|-+          \ 
                         |MNR|    \|/    |MNR|           \_____    
                         +-:-+   +-|-+   +-:-+    
                                 |MNR|     :
                                 +-:-+    +-+
                                          +-+

Now, we have to select a topologically correct prefix p:: with respect to
network N but not to network M or a topologically correct prefix q:: with
respect to network M but not to network N. It is very hard to select p:: or
q::, as it is dependent on the (dynamic) topology of the MANET and the MANET
routing protocol. By my knowledge, the MANET protocols we have right now are
using the destination IP address for forwarding and not the source IP
address.
Any thoughts including this problem in the Problem Statement document?

I have also my thoughts on needs for authorization on using the external
network. I think in real world, many access providers no not allow
unauthorized nodes to have access. Getting an address in not that much a
problem, using the access network is. 

Regards, Teco

> -----Oorspronkelijk bericht-----
<snip>
> > useful to networks in general, not just MANETs.
[Teco:] 
I think we should scope on MANET networks only.

> >> I would say each DHCP server manages its own pool of addresses and
> it
> > will
[Teco:] 
I think this is a DHCP problem and it is not specific to MANETs.
The DHC WG should work on this.
DHC WG is already chartered to cope with wireless / insecure / public LANs.

> If not, we need to explain that, plus why. If yes, then Teco seems to
[Teco:] 
I think Autoconf should work on address assignment and MANET WG should work
on the routing protocol.
Before IP connectivity is arranged, the first step is getting a MANET
address. The Second step is MANET routing.
After step 2, I think communication between a MANET Router and a DHCP Server
should work. Maybe there is a bootstrap problem on DHCP Server discovery,
especially if the address (step 1) was not assigned by a DHCP server.

On DHCP and routing protocol dependency, I agree there is a problem for
getting an address. This is section 5.1.

On getting a prefix (section 5.3), there may be a problem. I think section
5.3.1. should describe what the DHCP-PD problem really is.

> >> MANET Autoconf context. I think also the allocated prefixes are to
> be
> > used
[Teco:] 
I think pointing to each other doesn't help much.
The name of the document is "Terminology and Problem Statement". I think it
makes sense that terms are defined clearly in this document and that
ManetArch is updated, if needed. 
ManetArch does not provide a definition of the term prefix. This document
does, and it is not exactly what is described in RFC4291. I do not have a
problem with the "aggregatable pool of addresses" definition (out of section
2.), but some of us could get confused.
Why not adding the term in 2?
Bring in line with RFC3513 & RFC3587 and use Global Routing Prefix and
Subnet Prefix? Use MANET Routing Prefix, if we do not want to use Global
Routing Prefix?

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Wed, 20 Feb 2008 13:34:33 +0100

Hi Teco,

	Thanks for the detailed comments. Some comments inline...

>               Other       ( Communication )           :     K

[Carlos] In this case, I'm not sure this issues should be documented in
the PS document. To me, this seems more related to routing, but not to
IP address autoconfiguration. I agree it is an important problem, but
IMHO we are only concerned in this document in providing MNRs with valid
and unique IP addresses/prefixes. Do others share that view? maybe I'm
missing something...

One more comment below...

> problem, using the access network is. 

[Carlos] This could be related to security, although I see network
access authorisation as some-how an orthogonal problem to IP address
autoconf.
	
> Subnet Prefix? Use MANET Routing Prefix, if we do not want to use Global

[Carlos] For me, the use of prefix in the PS and in the MANET arch
document is clear now, but I have to admit that I needed some time to
get to it. If we want to clarify that, I think manet-arch document is
the best place, IMO, since it's related to the networking model.

	Kind Regards,

	Carlos

-- 
¡ASÓCIATE! Gratis para estudiantes  http://www.telematica.ws
 Carlos Jesús Bernardos Cano     http://www.netcoms.net
 GPG FP: D29B 0A6A 639A A561 93CA  4D55 35DC BA4D D170 4F67
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
  WEEDEV 2008: 1st Workshop on Experimental Evaluation and
        Deployment Experiences on Vehicular networks
                  http://www.weedev.org/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
_______________________________________________
Autoconf mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/autoconf

---

From: "Simone Ruffino" <[email-masked]>
Date: Wed, 20 Feb 2008 15:01:50 +0100

Hi Teco,
some comments below.

Thanks for your comments and regs,
Simone

Teco Boot wrote:
> routing protocol. 

Great that you raised this point, because I've always stressed this is a 
a problem :).

I agree: the selection of prefix (and addresses) to use for application 
sessions with external hosts is hard, because it directly impacts on the 
path followed by return traffic *from* the external network *to* MNRs 
*in* the MANET. Routing protocols can only affect the other direction, 
i.e. from the MNR to the external network.

However, let me elaborate more on this.
I think selection of either p:: or q:: is not really a problem per-se. 
In fact, MNRs (and connected hosts) could configure both p:: and q:: on 
their interfaces: IPv6 permits it. And hosts connected to MNRs could 
initiate application sessions with hosts in both networks M and N: 
source address selection rules will choose the prefix with the right scope.

Moreover, if both Network M and N are eventually connected to the 
Internet and if hosts (attached to MNRs) want to initiate application 
sessions with hosts on the Internet, p:: and q:: could be equivalent.

But in this case, the choice of prefix could depend on other factors, 
e.g. performance. In fact, it is actually more important to choose the 
optimal Border MNR, in order to prevent return traffic to traverse long 
paths in the MANET. Choosing a very far away border router (in terms of 
number of hops, w.r.t. the MNR initiating the session) has a direct 
impact on applications, especially jitter-sensitive ones like VoIP.

So in my opinion there is a 1:1 correspondence between performance and 
prefix choice.

By my knowledge, the MANET protocols we have right now are
> Any thoughts including this problem in the Problem Statement document?

I think it could be useful to add some considerations, but, we decided 
to keep this version of PS "to-the-bone" as much as possible and get 
agreement on this. I'd like to hear opinion of other authors as well.

> problem, using the access network is. 
--------------------------------------------------------------------

CONFIDENTIALITY NOTICE

This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by replying to [email-masked].

        Thank you

                                        www.telecomitalia.it

--------------------------------------------------------------------

---

From: "Teco Boot" <[email-masked]>
Date: Wed, 20 Feb 2008 16:22:10 +0100

Hi Simone,
I think it is not only a performance issue. Ingress filtering will simply
block incoming traffic with non-conforming source addresses.
On Problem Statement "to the bone", I agree. But I think that the dual homed
MANET is a very important real world scenario. 
And another issue on this, when using both p:: and q:: on the local
"classical IP" interface for assignment of addresses to directly connected
hosts, these hosts are not aware on what is happening on the MANET. So
address maintenance for these nodes, solving the ingress filtering issue and
optimizing performance, is not that easy. Ignoring this problem is not my
preferred option. In the contrary, I think it is a very important goal. 
Regards, Teco

NB.
In the diagram, network N and M are connected to the Internet. We are in
Internet Area, so this is implicit but I forgot to mention.

> Van: Simone Ruffino [mailto:[email-masked]]
> Verzonden: woensdag 20 februari 2008 15:02
> Aan: Teco Boot; [email-masked]
> Onderwerp: Re: [Autoconf] AUTOCONF Problem Statement: reviews
> needed.
> 
> Hi Teco,
> some comments below.
> 
> >                       `.                    _,'          prefix q::
> with
> This message and its attachments are addressed solely to the persons
> above and may contain confidential information. If you have received
> the message in error, be informed that any use of the content hereof is
> prohibited. Please return it immediately to the sender and delete the
> message. Should you have any questions, please contact us by replying
> to [email-masked].
> 
>         Thank you
> 
>                                         www.telecomitalia.it
>

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Wed, 20 Feb 2008 16:53:57 +0100

Hi Somone, all.

	Two short comments below.

> So in my opinion there is a 1:1 correspondence between performance

[Carlos] I think this problem/scenario also happens in non-MANET
scenarios (it's a multihoming issue) and it is not particular of IP
address autoconfiguration. I agree is a very interesting issue, but I'm
not sure the IP autoconf PS is the right place. The only specific issue
I see there is how to detect that an initially multihomed subordinate
MANET gets disconnected from one of the external networks it was
attached to, and even in this case, this also occurs in non-MANETs.

> agreement on this. I'd like to hear opinion of other authors as well.

[Carlos] Again, I don't see this as an IP address autoconfiguration
issue. This is related to MANET routing protocols, and therefore I'd
prefer not to include any consideration in the PS.

	Regards,

	Carlos
> the message in error, be informed that any use of the content hereof
> is prohibited. Please return it immediately to the sender and delete
> the message. Should you have any questions, please contact us by
> replying to [email-masked].
> 
>         Thank you
> 
>                                         www.telecomitalia.it
>

---

From: "Simone Ruffino" <[email-masked]>
Date: Wed, 20 Feb 2008 17:02:08 +0100

Teco,

> block incoming traffic with non-conforming source addresses.

Yes, I didn't mention it in my mail to avoid putting too many problems 
on the table but I strongly agree it is a problem in some deployments.

> MANET is a very important real world scenario. 

Agree. Maybe more explanatory text could be needed and, BTW, your 
picture is good :) !

But, if we want to include in the PS the topics we covered in our late 
mail exchange, the question is, as always: what is the problem? And, 
after we come up with a clear definition of the problem: is it something 
we cannot solve with standard existing solutions?

> preferred option. In the contrary, I think it is a very important goal. 

I agree, also because I don't think it is an unsolvable/impossible 
problem. For example, going into solution space, interaction with 
routing protocol can help.

CONFIDENTIALITY NOTICE

        Thank you

                                        www.telecomitalia.it

---

From: "Teco Boot" <[email-masked]>
Date: Wed, 20 Feb 2008 17:18:58 +0100

Hi Carlos,
Maybe it is true that is some "unmanaged and open" wired networks, the
multi-homing issue can arise. But I think the hosts can deal with this
issue, by selecting a default gateway. And yes, there is a relation between
the selected gateway and the generated SLAAC address.
I think that in a open, wireless network where we introduce a MANET
protocol, the problem is out-of-control. The MANET Router connected hosts do
not have any idea of the MANET topology and I do not see a method that these
nodes can select a source address, other than try and error.
The MANET Router itself could perform an internal MANET topology table
lookup and try to detect the egress to the Internet, and use corresponding
source address. I think this method does not work in all cases, e.g. session
continuity during movement is a problem.
Any other opinions?
Teco.

> Van: Carlos Jesús Bernardos Cano [mailto:[email-masked]]
> Verzonden: woensdag 20 februari 2008 16:54
> Aan: Simone Ruffino
> CC: Teco Boot; [email-masked]
> Onderwerp: Re: [Autoconf] AUTOCONF Problem Statement: reviews needed.
> 
> Hi Somone, all.
> 
> > > network N but not to network M or a topologically correct prefix
> q::
> > with
> > > respect to network M but not to network N. It is very hard to
> select
> > p:: or
> > Great that you raised this point, because I've always stressed this
> is
> > a a problem :).
> >
> > I agree: the selection of prefix (and addresses) to use for
> > application sessions with external hosts is hard, because it directly
> > impacts on the path followed by return traffic *from* the external
> > network *to* MNRs
> > optimal Border MNR, in order to prevent return traffic to traverse
> > long paths in the MANET. Choosing a very far away border router (in
> > terms of number of hops, w.r.t. the MNR initiating the session) has a
> > direct impact on applications, especially jitter-sensitive ones like
> > VoIP.
> >

---

From: "Simone Ruffino" <[email-masked]>
Date: Wed, 20 Feb 2008 17:26:49 +0100

Teco,

> continuity during movement is a problem.

:D

FYI, we have implemented (and documented in a expired draft) a solution 
that exactly does that.
And, it is integrated with Mobile IPv6.
I've experimented many times that choosing the wrong border router 
(e.g., picking the first one that MNR hears) can tear a voice call down 
when MANET topology changes. Instead, with the mechanism you're 
suggesting, the best possible performance is guaranteed.

Only problem: solution was designed for a multi-link subnet MANET model, 
but I think the underlying principle (ruoting table lookup to find best 
source address) is still sound.

CONFIDENTIALITY NOTICE

        Thank you

                                        www.telecomitalia.it

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Wed, 20 Feb 2008 17:30:17 +0100

Hi Teco,

> multi-homing issue can arise. But I think the hosts can deal with this

	The site multihoming issue may arise even in controlled wired networks
that are connected to several ISPs. In IPv4 there are solutions to deal
with the failure of one of the ISPs (mainly based on BGP). I still don't
see why MANET is so different here (from an IP address autoconf point of
view, routing is a different issue).

	Regards,

	Carlos

---

From: "Simone Ruffino" <[email-masked]>
Date: Wed, 20 Feb 2008 17:39:02 +0100

> On mié, 2008-02-20 at 15:01 +0100, Simone Ruffino wrote:
[[SNIP]]
>> application 
>> long 

I respectfully don't agree.
MANET has specific problems, deriving from the fact that routers can 
dynamically change topology (which usually does not happen in wired 
networks....): the choice of a random prefix (from a pool of available 
prefixes) by an MNR could, one minute later, cause severe performance 
degradation to hosts.
This of course cannot be avoided in single-border-router scenarios, but, 
if multiple border routers are available, this CAN be avoided, with 
proper prefix selection mechanisms.

So, I think that (as with DHCP) the question is: are existing solutions 
able to cope with specific MANET environment, ... including here the 
fact that there is a Big difference between a three-hop path and a 
four-hop path .... :) ?

CONFIDENTIALITY NOTICE

        Thank you

                                        www.telecomitalia.it

---

From: "Teco Boot" <[email-masked]>
Date: Wed, 20 Feb 2008 17:42:44 +0100

I do not want to suggest a solution at this moment. After Philly, I will.
My intention was to make clear taht it is hard for a MANET node to select a
source address that is appropriate for communication with nodes outside a
multi-homed MANET. And that for a MANET router connected host, it is
undoable. I think try-and-error is not an acceptable solution.
I always thought this is an important real world issue. Your effort on this
is some evidence;-)
Teco.

> Verzonden: woensdag 20 februari 2008 17:27
> Aan: Teco Boot
> CC: [email-masked]; [email-masked]
> >>>> On uniqueness validation, I posted before my reservations on
> active
> >>> DAD. In
> >>>> as it is up to the (MANET) routing protocol to find out the path
> to
> >>> the
> >>>> destination.
> >>>> Scenario:
> >>>>
> >>>>
> >>>>                    '.                           /
> >>>>                       `.                    _,'          prefix
> >>> In fact, MNRs (and connected hosts) could configure both p:: and
> q::
> >>> on
> >>> source address selection rules will choose the prefix with the
> right
> >>> scope.
> >>>

---

From: "Francisco J. Ros" <[email-masked]>
Date: Wed, 20 Feb 2008 18:02:23 +0100

Hi Simone, all,

I've been following the discussion and tend to agree with Carlos. In my 
opinion, the MNR can configure as many prefixes as are available for each of 
its interfaces. Then, the selection of one border router or another according 
to a given metric (e.g. hop count) is a routing issue not related to 
autoconf. The source address selection policy should then take into account 
the border router which is being used in order to avoid the ingress filtering 
issue.

I don't think the P-S is the right place to discuss this, although I don't 
have a strong feeling on this either.

Regards,
fran

On Wednesday 20 February 2008 17:39, Simone Ruffino wrote:
<snip>

-- 
Francisco J. Ros, Ph.D. Student
Dept. of Information and Communications Engineering
University of Murcia, Murcia (Spain)

http://masimum.inf.um.es/fjrm/
_______________________________________________
Autoconf mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/autoconf

---

From: "Teco Boot" <[email-masked]>
Date: Wed, 20 Feb 2008 17:57:55 +0100

Hi Carlos,

There are BCPs to circumvent this problem.
I always used ingress filters on ingress interfaces and never on transit
links.
I would never, never, never deploy an open wireless access network without
strict ingress filtering.

I highly prefer ingress filtering on secured and fully controlled access
networks, just for making sure every node is behaving well.
I want to keep this BCP as long as possible, including supporting a
multi-homed secured and fully controlled access network. The options are
opening the ingress filters on all exit points for all possible exit points,
or strict filters on each exit point and source address selection on all
nodes.

With multiple access providers, the wide ingress filter is no option
anymore. Many large network operators offer different access technologies,
and I doubt if wide filters will be used here.

Regards, Teco.

> Verzonden: woensdag 20 februari 2008 17:30
> Aan: Teco Boot
> CC: [email-masked]
> Onderwerp: RE: [Autoconf] AUTOCONF Problem Statement: reviews needed.
> 
> Hi Teco,
> 
> 	The site multihoming issue may arise even in controlled wired
> networks that are connected to several ISPs. In IPv4 there are
> solutions to deal with the failure of one of the ISPs (mainly based on
> BGP). I still don't see why MANET is so different here (from an IP
> address autoconf point of view, routing is a different issue).
> 
> 	Regards,
> 
> 	Carlos
>

---

From: "Teco Boot" <[email-masked]>
Date: Wed, 20 Feb 2008 18:01:48 +0100

Hi Francisco,
What about the connected hosts?
What about movement and session continuity?
What about a reactive MANET routing protocol?
Regards, Teco

> Namens Francisco J. Ros
> Verzonden: woensdag 20 februari 2008 18:02
> Aan: [email-masked]

---

From: "Simone Ruffino" <[email-masked]>
Date: Wed, 20 Feb 2008 18:34:18 +0100

Hi Francisco,
Please see below.
Simone

> to a given metric (e.g. hop count) is a routing issue not related to 

Well, every time I raise this point we end up here ..:).
But, as a matter of fact:
- performance degradation caused by prefix choice and
- ingress filtering
are not tackled anywhere.

The source address selection policy should then take into account
> the border router which is being used in order to avoid the ingress filtering 

Well, yes, but it's not that easy...:)
Because, if you're doing that and the border routers change frequently, 
applications are degraded as well, even if a session continuity solution 
like MIPv6 is in place.

> have a strong feeling on this either.

Although my personal opinion is that they could be mentioned in the P-S, 
right now, as an author, I feel much more important to get consensus on 
what are the _basic_ problems to solve.
I.e., if DHCP does not work, nothing else works....

CONFIDENTIALITY NOTICE

        Thank you

                                        www.telecomitalia.it

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Wed, 20 Feb 2008 18:50:42 +0100

Hi Simone,

> I.e., if DHCP does not work, nothing else works....

	Agree on the latter :-)

---

From: "Teco Boot" <[email-masked]>
Date: Wed, 20 Feb 2008 19:36:01 +0100

> > I.e., if DHCP does not work, nothing else works....
Why not giving SLAAC a chance? I think SLAAC and ULA fits MANET Autoconf
requirements pretty well.
And there are other options. So I don't agree at all :-)
Cheers, Teco.

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Wed, 20 Feb 2008 19:49:16 +0100

Hi Teco,

	I meant "agree on that the most important thing is to get consensus on
what are the _basic_ problems to solve.", nothing about the use of
DCHP/SLAAC,...

	Sorry for the misunderstanding.

	Regards,

	Carlos

---

From: "Simone Ruffino" <[email-masked]>
Date: Thu, 21 Feb 2008 08:49:57 +0100

Yes, thanks Carlos,
this is what I meant too (DHCP was more like an example).

Simone

CONFIDENTIALITY NOTICE

        Thank you

                                        www.telecomitalia.it

---

From: "Teco Boot" <[email-masked]>
Date: Thu, 21 Feb 2008 10:48:26 +0100

Hi Emmanuel, WG chairs,

I posted some of my "additional" thoughts on the PS document. There was some
discussion, maybe we can come up with an outcome:

1) Need for active DAD.
Not that much response yet. It is a comment on the Autoconf PS text. Add a
single line at the end of 5.2.2?
Proposed text:
>   Also the Duplicate Address Detection signalling could 
>   introduce unacceptable overhead.
Text is in line with text above in section 5.2.2 and in line with RFC4862.

2) Multi-homed subordinate MANETs and source address selection and session
continuity.
This is an important real-world problem that must be addressed somewhere.
However the problem is a result of what Autoconf and MANET achieves, so
input for a follow-up. I can live with an outcome that the Autoconf WG
produces a separate document describing this scenario and introduced
problem(s). I can present the scenario and the introduced problem(s) in
Philly. I did in Chicago, but there were few seconds left for my
presentation, and I think many of us may not understood the scenario and the
introduced problem(s).
What do you think?

3) Authorization to use access to external network.
This is also an important real-world problem that must be addressed
somewhere. Similar to problem 2, it is a problem that is introduced as a
result of what Autoconf and MANET achieves. We could describe this problem
in more detail in the scenario document I suggested above.

Can the WG chairs can react on my proposal?
Opinion from ADs?

Regards, Teco

---

From: Emmanuel Baccelli <[email-masked]>
Date: Thu, 21 Feb 2008 11:13:12 +0100

Hi Teco,

> Text is in line with text above in section 5.2.2 and in line with RFC4862.

I guess your argument basically says "NDP is not optimized", but it does 
not say: "NDP does not work". I agree you have a point, but for now the 
document concentrates on why "NDP does not work", and it is explained in 
section 5.2.2.

Furthermore, in section 6.1, solutions requirements (i.e. R06) state 
that "solutions must achieve low overhead". So I guess that your concern 
is covered anyways. Do you agree?

> presentation, and I think many of us may not understood the scenario and the

In section 6.1., solutions requirements (i.e. R11) state that "solutions 
should work in MANETs connected to external network(s), via multiple 
border routers." Does this take into account your concern? If not, how 
do you suggest we alter this requirement to take it into account?

> in more detail in the scenario document I suggested above.

Again, do you think R11 covers this? Or how do you suggest we alter it?

Emmanuel

---

From: "Teco Boot" <[email-masked]>
Date: Thu, 21 Feb 2008 12:13:14 +0100

Hi, Comments inline.
Regards, Teco

> Verzonden: donderdag 21 februari 2008 11:13
> Aan: [email-masked]
[Teco:] 
R06 is OK, this req is important.
The proposed text mentions a problem with usage of NDP DAD in a wireless
network were overhead is a concern. The problem is directly related to NDP.
Therefore I liked to mention this explicitly.

> do you suggest we alter this requirement to take it into account?
[Teco:] 
Req11 is OK, but very general. And it is a should, not a must.
Add R 11.1.?
**> Solutions must circumvent problems with source address filtering 
**> on ingress to external networks.
The problems with multiple external networks are not described in current PS
document. The discussion on ML made also clear the problem is not well
understood. 
I'll wait for a reaction from chairs on where to describe the problems.

Simone mentioned that the performance degradation caused by non-optimal
prefix choice is not tackled anywhere.
Add R 11.2.?
**> Solutions should select addresses and prefixes to optimize communication
**> to external networks.

> Again, do you think R11 covers this? Or how do you suggest we alter it?
[Teco:] 
Here I don't think R 11 addresses the problem.
Add R 11.3.?
**> Solutions must comply with authorization mechanisms validating access to

**> external networks.

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 21 Feb 2008 19:08:31 +0100

Emmanuel Baccelli wrote:
>  provide your feedback this week -- the cut-off date being next 
> Monday. The document is short (20 pages), so don't refrain!

Hi Manu, thanks for submitting this revised version.

I'm personally still trying to identify the space into which this can
become a problem and how a solution could fit some requirements.

The draft is clearer than before.

Stating DHCP/PD/NDP don't work when the connections break doesn't mean
we have a problem, because nothing could ever work when connections
break - AUTOCONF included.  Stating they  can be part of solution, but
not everything in a solution - I agree with that part.

Defining new 'disjoint prefixes' as opposed to discussing old 'unique
prefixes' seems a more common denominator, I can grasp it, but I'm not
sure the draft definition of disjoint prefixes was discussed and agreed
already.  PRobably yes.  I will not oppose it.  I have a marginal
theoretical interest in disjoint and unique prefixes and other items
affecting how routing may work, but that doesn't mean I oppose the way
AUTOCONF choose to do it.

Otherwise yes, the structure and reading of the entire draft makes sense
to me.

Alex

> Emmanuel _______________________________________________ Autoconf 
> mailing list [email-masked] 

______________________________________________________________________
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]
http://www.ietf.org/mailman/listinfo/autoconf

---

From: Emmanuel Baccelli <[email-masked]>
Date: Thu, 21 Feb 2008 19:26:52 +0100

Hi Alex,

thanks for your feedback. I am happy that the draft seems to make more 
sense to you ;) Please see my comments inline:

> not everything in a solution - I agree with that part.

Yes, MANETs are a new challenge, and the document describes a subset of 
the new challenges regarding IP autoconfiguration (stating that existing 
solutions are not sufficient).

> AUTOCONF choose to do it.

OK. I guess this indeed results from the "unique prefix" discussion, 
that happened a while back, and also from the MANET-architecture 
document. If you can suggest a better way to express the fact that 
"addresses with prefixA are all different from addresses in prefixB" 
please do so, we will use it!

> Otherwise yes, the structure and reading of the entire draft makes sense

Great!

Emmanuel

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 21 Feb 2008 21:43:45 +0100

Emmanuel Baccelli wrote:
[...
>> Stating DHCP/PD/NDP don't work when the connections break doesn't
>> mean we have a problem, because nothing could ever work when
>> connections break - AUTOCONF included.  Stating they  can be part
>> of solution, but not everything in a solution - I agree with that
>> part.
>> 
> 
> Yes, MANETs are a new challenge, and the document describes a subset
> of the new challenges regarding IP autoconfiguration (stating that
> existing solutions are not sufficient).

This is what should be identified, but we said this over and over :-)

>> Defining new 'disjoint prefixes' as opposed to discussing old
>> 'unique prefixes' seems a more common denominator, I can grasp it,
>> but I'm not sure the draft definition of disjoint prefixes was
>> discussed and agreed already.  PRobably yes.  I will not oppose it.
>> I have a marginal theoretical interest in disjoint and unique
>> prefixes and other items affecting how routing may work, but that
>> doesn't mean I oppose the way AUTOCONF choose to do it.
> 

This is disgression following.  I'm not sure we can express the fact
that addresses with prefixA are all different from addresses in prefixB
unless we assume (1) prefix length n of prefixA is equal to prefix
length n of prefixB and (2) the underlying routing system uses longest
prefix matching and prefixes are the contiguous set of leftmost n bits.

Whereas the latter seems to be a good assumption in many routing
systems, especially IPv6 (probably less IPv4), the former was not an
assumption in your discussions, only in mine :-) (I'm not sure whether
it figures in the draft).

But yes, intuitively 'disjoint prefixes' resonate like 'unique prefixes'
to me, and seems people can agree with it as is.

Alex

---

From: mase <[email-masked]>
Date: Fri, 22 Feb 2008 21:42:36 +0900

Alex,

Comments in line.

>to me, and seems people can agree with it as is.

Regardless of the prefix length, a prefix represents an address 
range, a set of addresses, Then, two prefixes,  disjoint to each 
other, mean that two address ranges are not overlapping. That is, two 
sets of addresses do not have a common set of addresses. Underlying 
routing system must use the whole prefix A with length n and the 
whole prefix B with length m in routing. Longest prefix matching must 
not used in routing in the MANET.
Does this help your understanding?

Kenichi

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 22 Feb 2008 16:37:02 +0100

mase wrote:
>>>> 'unique prefixes' seems a more common denominator, I can grasp 
>>>> it, but I'm not sure the draft definition of disjoint prefixes 
>>>> was discussed and agreed already.  PRobably yes.  I will not 
>>>> oppose it. I have a marginal theoretical interest in disjoint 
>>>> and unique prefixes and other items affecting how routing may 
>>>> work, but that doesn't mean I oppose the way AUTOCONF choose to
>>>>  do it.
>>> 
>>> OK. I guess this indeed results from the "unique prefix" 
>>> discussion, that happened a while back, and also from the 
>>> MANET-architecture document. If you can suggest a better way to 
>>> express the fact that "addresses with prefixA are all different 
>>> from addresses in prefixB" please do so, we will use it!
>> 
>> This is disgression following.  I'm not sure we can express the 
>> fact that addresses with prefixA are all different from addresses 
>> in prefixB unless we assume (1) prefix length n of prefixA is equal
>>  to prefix length n of prefixB and (2) the underlying routing 
>> system uses longest prefix matching and prefixes are the contiguous
>>  set of leftmost n bits.
>> 
>> systems, especially IPv6 (probably less IPv4), the former was not 
>> an assumption in your discussions, only in mine :-) (I'm not sure 
>> whether it figures in the draft).
>> 
>> But yes, intuitively 'disjoint prefixes' resonate like 'unique 
>> prefixes' to me, and seems people can agree with it as is.
> 
>  sets of addresses do not have a common set of addresses.

Sounds ok... I can then understand that if two sets of addresses don't
have a common subset of addresses then the two sets of addresses may
contain each a prefix different than the other prefix?  I'd say 'may',
because there exist of course two sets of addresses that don't have any
common subset of  addresses and that don't have any common prefix either
(differ at leftmost bit).

> Underlying routing system must use the whole prefix A with length n 
> and the whole prefix B with length m in routing.

MUST?  Are there any routing system that doesn't use longest prefix
match?  Are there routing systems that don't use prefix matching at all?
  I'd suppose yes, like in policy routing.  Also yes because link-layer
'routing' in bluetooth seems to be exact matching on link-layer
addresses, there being no prefixes.

> Longest prefix matching must not used in routing in the MANET.

I think you say longest-prefix matching must be used, and the 'not'
above is just a typo?

> Does this help your understanding?

Well yes, thank you, as I said previously, I will not oppose the
agreements in this discussion and I will try to follow the discussion
from a distance.

Alex

---

From: mase <[email-masked]>
Date: Sat, 23 Feb 2008 06:28:03 +0900

At 00:37 08/02/23, Alexandru Petrescu wrote:
>>>This is disgression following.  I'm not sure we can express 
>>>the fact that addresses with prefixA are all different from 
>>>addresses in prefixB unless we assume (1) prefix length n of prefixA is equal
>>>Whereas the latter seems to be a good assumption in many 
>>>routing systems, especially IPv6 (probably less IPv4), the former 
>>>was not an assumption in your discussions, only in mine :-) (I'm 
>>>not sure whether it figures in the draft).

No. Let W, X, Y, Z are 8bit sequences, respectively. Prefix WX/16 
and WYZ/24 has a common Prefix W/8 but, Prefix WX and WYZ does not 
have a common sebset of addresses.

>>Underlying routing system must use the whole prefix A with length 
>>n and the whole prefix B with length m in routing.
>

Sorry for the confusion. Longest-prefix matching is workable.

>agreements in this discussion and I will try to follow the discussion

Thank you for the discussions to clarify points.

Kenichi

---

From: Alexandru Petrescu <[email-masked]>
Date: Sat, 23 Feb 2008 02:35:29 +0100

mase wrote:
>>> Alex, Comments in line. At 05:43 08/02/22, Alexandru Petrescu 
>>> wrote:
>>>>>> Defining new 'disjoint prefixes' as opposed to discussing 
>>>>>> old 'unique prefixes' seems a more common denominator, I 
>>>>>> can grasp it, but I'm not sure the draft definition of 
>>>>>> disjoint prefixes was discussed and agreed already. 
>>>>>> PRobably yes.  I will not oppose it. I have a marginal 
>>>>>> theoretical interest in disjoint and unique prefixes and 
>>>>>> other items affecting how routing may work, but that 
>>>>> MANET-architecture document. If you can suggest a better way 
>>>>> to express the fact that "addresses with prefixA are all 
>>>>> different from addresses in prefixB" please do so, we will 
>>>>> use it!
>>>>  fact that addresses with prefixA are all different from 
>>>> addresses in prefixB unless we assume (1) prefix length n of 
>>>> prefixA is equal to prefix length n of prefixB and (2) the 
>>>> underlying routing system uses longest prefix matching and 
>>>> prefixes are the contiguous set of leftmost n bits. Whereas the
>>>>  latter seems to be a good assumption in many routing systems, 
>>>> especially IPv6 (probably less IPv4), the former was not an 
>>>> assumption in your discussions, only in mine :-) (I'm not sure 
>>>> whether it figures in the draft). But yes, intuitively 
>>>> 'disjoint prefixes' resonate like 'unique prefixes' to me, and 
>>>> seems people can agree with it as is.
>>> other, mean that two address ranges are not overlapping. That is,
>>> two sets of addresses do not have a common set of addresses.
>> 
>> Sounds ok... I can then understand that if two sets of addresses 
>> don't have a common subset of addresses then the two sets of 
>> addresses may contain each a prefix different than the other 
>> prefix?  I'd say 'may', because there exist of course two sets of 
>> addresses that don't have any common subset of  addresses and that 
>> don't have any common prefix either (differ at leftmost bit).
> 
> No. Let W, X, Y, Z are 8bit sequences, respectively. Prefix WX/16 and
>  WYZ/24 has a common Prefix W/8 but, Prefix WX and WYZ does not have 
> a common subset of addresses.

Right, WX and WYZ look as a perfect illustration for what 'disjoint'
means, worth noting down!  Not even one address generated from WX can
ever be generated from WYZ, and reciprocally.

Code would be: given a pair of tuples [prefix, prefixlen] pick the
smallest prefix length, compare that number of leftmost bits of the two
prefixes.  If they match then the two prefixes are not disjoint,
otherwise they're disjoint.

Remark the relationship is not transitive.  I could have 0 disjoint from
10, 10 disjoint from 001 and yet 0 not disjoint from 001.  In this sense
'disjoint' relationship is very different from 'unique' relationship.

It's difficult to talk about three - or a pool of - prefixes being
disjoint (two by two?  3 by 2?).  Whereas if we assume all prefixes have
same prefix length it's very easy to talk about n 'unique' prefixes.

Sidenote, I would avoid the term 'overlap' below
> Disjoint prefixes  - two prefixes are said to be disjoint if and only
>  if their respective address ranges do not overlap.
because makes one think that some addresses may overlap on some leftmost
bits, whereas I think you meant no address from one prefix's range is
present in the other's range (comparing addresses by an exact 128bit
match).  Or maybe it's just my reading.

Just some notes...

Alex

---

From: mase <[email-masked]>
Date: Sat, 23 Feb 2008 11:49:38 +0900

At 10:35 08/02/23, Alexandru Petrescu wrote:
>>>>Alex, Comments in line. At 05:43 08/02/22, Alexandru Petrescu wrote:
>>>>>>>work, but that doesn't mean I oppose the way AUTOCONF choose to do it.
>>>>>  latter seems to be a good assumption in many routing 
>>>>> systems, especially IPv6 (probably less IPv4), the former was 
>>>>> not an assumption in your discussions, only in mine :-) (I'm 
>>>>> not sure whether it figures in the draft). But yes, intuitively 
>>>>Regardless of the prefix length, a prefix represents an 
>>>>address range, a set of addresses, Then, two prefixes,  disjoint 
>>>>to each other, mean that two address ranges are not overlapping. That is,
>>>Sounds ok... I can then understand that if two sets of 
>>>addresses don't have a common subset of addresses then the two 
>>>sets of addresses may contain each a prefix different than the 
>>>other prefix?  I'd say 'may', because there exist of course two 
>>>sets of addresses that don't have any common subset of  addresses 
>>>and that don't have any common prefix either (differ at leftmost bit).
>>  WYZ/24 has a common Prefix W/8 but, Prefix WX and WYZ does not 
>> have a common subset of addresses.
>

Right.

>otherwise they're disjoint.

Right.

>'disjoint' relationship is very different from 'unique' relationship.

Prefix is the set of addresses. Using your example above, the set 
0 and the set 10 is disjoint. Since the set 001 is included in the 
set 0, it is natural that the  set 001 is also disjoint to the set 10.

>same prefix length it's very easy to talk about n 'unique' prefixes.

I believe efficient calculation is possible without the same 
prefix length assumtion. I also think that it is not difficult to 
produce multiple disjoint prefixes, that are disjoint to each 
other. I think that allowing different lenghth prefix is important 
and useful in some scenarios. For example, assume that  node 1 has 
authority of the prefix WX/16 and node 2 has authority of the 
prefix WY/16. Later, node 2 takes WYZ/24 for itself and gives 
WYA/24 to other node, resulting different length prefixes.

>match).  Or maybe it's just my reading.

I understand that overlap may be confusing.

Thanks,
Kenichi

---

From: Alexandru Petrescu <[email-masked]>
Date: Sat, 23 Feb 2008 12:08:55 +0100

Hi Kenichi,

mase wrote:
[...]
>>>  and WYZ/24 has a common Prefix W/8 but, Prefix WX and WYZ does 
>>> not have a common subset of addresses.
>> 
>> Right, WX and WYZ look as a perfect illustration for what 
>> 'disjoint' means, worth noting down!  Not even one address 
>> generated from WX can ever be generated from WYZ, and reciprocally.
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
> 
> Right.
> 
> 
>>  smallest prefix length, compare that number of leftmost bits of
>> the two prefixes.  If they match then the two prefixes are not 
>> disjoint, otherwise they're disjoint.
> 
> Right.
> 
> 
>> Remark the relationship is not transitive.  I could have 0 disjoint
>>  from 10, 10 disjoint from 001 and yet 0 not disjoint from 001.  In
>>  this sense 'disjoint' relationship is very different from 'unique'
>>  relationship.
> 
> Prefix is the set of addresses. Using your example above, the set 0 
> and the set 10 is disjoint. Since the set 001 is included in the set 
> 0, it is natural that the  set 001 is also disjoint to the set 10.

Right, that sounds natural as well.

Let's look at this text:
> 2. [allow each MANET router to] be allocated IPv6 prefixes that are 
> disjoint from prefixes allocated to other routers within the MANET.

Do you mean a new router should be allocated (e.g.) two prefixes, each
  prefix being disjoint from each existing router's prefix?  But are
those two new prefixes disjoint between themselves or they could be joint?

Because it is possible to allocate two new prefixes 0 and 001 to a new
router, each prefix being disjoint from the already allocated prefix 10,
yet the two new allocated prefixes are not disjoint between themselves.
  This leads to a situation where the allocation happened according to
goal 2 above yet it could make goal 3 impossible:

> 3. maintain, within the MANET, [...] the disjoint character of 
> allocated prefixes (even in face of network merging).

This is confusing to me, ?

Alex

---

From: mase <[email-masked]>
Date: Sun, 24 Feb 2008 09:34:27 +0900

Hi Alex,

At 20:08 08/02/23, Alexandru Petrescu wrote:
>>Prefix is the set of addresses. Using your example above, the 
>>set 0 and the set 10 is disjoint. Since the set 001 is included in 
>>the set 0, it is natural that the  set 001 is also disjoint to the set 10.
>
>>2. [allow each MANET router to] be allocated IPv6 prefixes that 
>>are disjoint from prefixes allocated to other routers within the MANET.
>

No, a new router should be allocated one prefix in principle. This 
prefix must be disjoint from any of the already addlocated prefixes 
for other routers.

>goal 2 above yet it could make goal 3 impossible:

Assume that an exisitng MANET router i has prefix pi. The prefix of 
router i and router j, pi and pj, are disjoint. Goal 2 says that a 
new router x will be allocated prefix px, that is disjoint from 
each of pi, pj and other prefixes of the existing routers in the MANET.

>This is confusing to me, ?

Assume that there are two separated MANET, MANET1 and MANET2. 
Router i in MANT1 has prefix p1i and router j in MANET2 has prefix 
p2j. Since MANET1 and 2 were independent, p1x and p2y may be same. 
After merging, this violates the disjoint character of allocated 
prefixes in the merged MANET. Goal 3 addresses that such issues 
should be resolved. Is this clear?

Kenichi

---

From: "Teco Boot" <[email-masked]>
Date: Sun, 24 Feb 2008 10:00:30 +0100

All,
Just some remarks on the "prefix-discussion".
1) I still doubt Autoconf should put much effort on prefixes. I still do not
understand the problem, or I think it is not a real-world problem. I think
current protocols for PD can be used in Subordinate MANETs and random ULA
prefixes can be used in a Autonomous MANET with extreme low probability on
collisions, e.g. using a 52-bit Global_ID.
2) Discussion on terminology, to be used for unique / disjoint /
non-overlapping / mutually exclusive or whatever prefixes is a general
routing issue. Too much discussion on this term on Autoconf ML is a waste of
time. 
3) Please keep in mind prefixes are not disjoint by definition, think about
anycast (or VRRF, but this is out-of-scope for a MANET). Are there existing
IETF protocols for verifying disjoint prefixes on routers?
Regards, Teco

> Namens mase
> Verzonden: zondag 24 februari 2008 1:34
> Aan: Alexandru Petrescu
> CC: [email-masked]; Emmanuel Baccelli

---

From: mase <[email-masked]>
Date: Sun, 24 Feb 2008 21:47:18 +0900

Hi Teco,

Thank you for your comments. My comments are in line.

>collisions, e.g. using a 52-bit Global_ID.

Wether random prefixes work or not depends on the prefix length, that 
may be selected depending on applications and scenarios.

>routing issue. Too much discussion on this term on Autoconf ML is a waste of

I think that unique address and disjoint prefix characeristisc are 
required for discussing any routing issues, but they are not 
necessarily discussed with routing issues. We therefore discuss these 
issues in autoconf WG, not manet WG.

>IETF protocols for verifying disjoint prefixes on routers?

Disjoint prefix characteristics are at least required for unicast routing.

Regards,
Kenichi