[01:20:15] --- keith.brazington has joined [02:34:58] --- keith.brazington has left [02:40:51] --- keith.brazington has joined [06:09:02] --- keith.brazington has left [06:09:32] --- keith.brazington has joined [08:53:10] --- keith.brazington has joined [09:34:55] --- jronan has joined [10:03:54] --- omnione has joined [10:04:00] --- omnione has left [10:04:20] --- omnione has joined [10:10:32] --- shubranshu has joined [10:10:48] --- badamson has joined [10:12:06] --- dthaler has joined [10:12:25] [10:13:08] Agenda: 1) MANET Architecture/ Terminology, 2) Other documents [10:13:36] Fred Templin> How did first item get on agenda? [10:13:44] Chair: will discuss [10:13:56] Fred: why didn't it come out on the mailing list? [10:14:39] --- apetrescu has joined [10:14:56] Thomas Clausen: arch document was last called a while ago ... the authors updated and solicited a couple of reviews, and then document was forwarded to IESG ... subsequent to that there was an email from Thomas Narten on concerns just before IETF 70 [10:15:29] Thomas: wanted to discuss Narten comments before moving document forward and this happened just before this meeting [10:16:04] --- jpc has joined [10:16:35] Area Director: just happening now ... AD reviews normal after last call [10:17:11] Fred: It seemed irregular that it didn't occur within the mailing list ... [10:17:33] Thomas Clausen: history on MANET Arch Document [10:17:59] Defining where devices have MANET and non-MANET interfaces. [10:18:36] What is the "link model" and what is the "addressing model" we're trying to describe? [10:18:53] --- geir has joined [10:19:07] --- roberto.baldessari has joined [10:19:07] Thomas Naarten: this is very open with clarifications to my comments, etc [10:21:08] Thomas Clausen: Trying to capture layer 2 nature of these interfaces how to map IP across them, etc [10:21:44] --- badamson has left [10:21:52] there are 3 different things the doc discusses... [10:22:01] 1) the link model (e.g. L2 properties) [10:22:09] 2) how to run IP over such a link model [10:22:28] --- badamson has joined [10:22:29] 3) discussion of wider-area issues for MANET [10:22:43] (beyond a single link/subnet, relationship to outside world, etc) [10:23:05] --- john.zhao has joined [10:23:41] Thomas Clausen: discussing Autoconf Problem Statement ... [10:24:27] Immanuel: presenting autoconf problem statement [10:27:13] See slides at http://www.ietf.org/proceedings/08mar/slides/autoconf-1.pdf [10:29:13] Joe Macker: question: Didn't like DHCP "wrong in MANET" statement ... perhaps just "not general" ... [10:29:35] Immanuel: document says "often wrong in MANET" ... [10:29:48] Joe Macker: DHCP Relay may work for _some_ scenarios [10:29:57] --- intvelt has joined [10:30:06] Immanuel: it is very well described in the document but not in slides [10:31:12] --- washad has joined [10:31:44] Thomas Narten: Making it work for MANEt may not be a DHCP problem but is a MANET problem ... don't know if you have the ability to send packets on a link ... need a baseline, need to focus on the architecture before the problem statement can be made [10:32:20] Narten: if assumption is relay agent can't talk to server, then you have a bigger problem than autoconf [10:32:43] Narten: you can't start without some base assumption of what can & can't communicate [10:34:05] Dave Thaler: this slide doesn't say where the relay agent is ... Do I have unicast connection between the relay agent and the server? DHCP assumes the relay agent has unicast connection to server ... if the relay agent is inside the manet router, then it is a different issue. Hard to evaluate if this slide is correct or not [10:37:00] --- softgearko has joined [10:37:00] Charles Perkins: seems there are really basic questions being asked here even after autoconf group has been meeting for a while. In MANET, we have discussed how to send a packet over a link ... so what happened between the MANET WG and AUTOCONF that this knowledge is "lost" ...I find it to be mysterious since we can do routing if we find a multi-hop path between them ... my reading is we don't know how to set up a DHCP service model within a MANET ... the reason DHCP relay works on existing net is because of broadcast assumptions we have that may not hold up on a MANET. [10:38:23] Joe Macker: now I really disagree with this statement. if you restated that I don't how to _configure_ the relay agent, but we do know how to route from the relay agent to the server ... disagree with the statement that you can't communicate with the relay agent. Communication through the relay agent isn't the problem. [10:39:36] Immanuel: slide is trying to say that static configuration in DHCP doesn't apply to dynamic environment ... i.e. if things move, it changes [10:40:47] Dave Thaler: multiple problems here, need to be distinguished ... how does the client communicate with the relay agent, etc ... How does the relay agent communicate is not the right way to state this? [10:42:06] Narten: 1) how does client comm. with the relay agent ... trivial because I have a firm model of how IP links work ... 2) how does relay get config, 3) how does relay agent comm. w/ server [10:42:26] --- intvelt has left [10:42:32] Immanuel: if we don't consider routing only #1 and #2 are AUTOCONF problems ... [10:43:02] Narten: when you say all 3 are problems I can't get my head around it ... need to tease out the distinct problems. [10:43:33] Immanuel: same problem will manifest in following slides, so please forgive ... [10:43:52] --- thomas_hc has joined [10:45:18] Dave Thaler: ... In language of RFC 2460 , it is a multicast, non-transitive link [10:46:01] Narten: out of discussion, it is clear that a MANET link per 2461 ... this is a new kind of link ... so we need to describe the behavior ... the arch doc should make this clear! [10:46:09] "multicast - a link that supports a native mechanism at the link layer for sending packets to all (i.e., broadcast) or a subset of all neighbors." [10:46:20] "asymmetric reachability - a link where non-reflexive and/or non-transitive reachability is part of normal operation. (Non- reflexive reachability means packets from A reach B but packets from B don't reach A. Non-transitive reachability means packets from A reach B, and packets from B reach C, but packets from A don't reach C.) Many radio links exhibit these properties." [10:46:23] --- intvelt has joined [10:46:39] Narten: NDP assumption is that it is a certain kind of link and this doesn't match. [10:46:46] dave, this was from which? 2461 or manetarch? [10:46:59] (note implied [sic] in all of this as I try to keep ;-) [10:47:01] quotes from RFC 2461 terminology section (2.2) [10:47:07] thanks. [10:47:09] (2.2 Link Types) [10:47:18] --- jronan has left [10:47:58] Charles Perkins: Narten makes statement that a new link description is required ... how have we got IP packets over these links in these past 10 years. [10:48:26] Narten: a link in the IP sense is one you can assign a prefix to ... assuming that any addr covered by a prefix is a neighbor [10:48:43] Clausen: have assigned /32 prefix for IPv4 ... [10:49:16] Perkins: should say we're not running over links ... if we mention the work "link", we have to wait 3 yrs to get the arch doc done. [10:51:26] Joe Macker: there are some link/interface types that look like e.g, 802.11 that has often been used in IP _but_ this is not the only link that MANET might run over ... MANET can work over other links (e.g., Ethernet) ... don't create a new thing that is so general ...e g., OSPF runs over multiple things ... keep seeing phrase "wrong in MANET" or "sometimes wrong" ... "wrong" is not a good term ... how about "not effective" ... "wrong" and "not effective" are different terms [10:51:56] Immanuel: DHCP is wrong not just "not effective", [10:52:07] Macker: you don't need to change the RFC [10:52:16] Immanuel: need autconf for relays? [10:52:28] --- intvelt has left [10:52:36] Macker: relay agent needs to know where to get to server [10:53:19] Eric Nordmark: has someone looked at the link properties ... e.g. reachable with TTL decrement, etc [10:54:00] Eric Nordmark: current protocols assume that _all_ of these characteristics are true, etc ... if not the case you may be creating something you haven't before ... [10:55:14] Thaler: agree w/ some of Eric's and disagree others ... focus on arch, yes, but Eric's "properties" may be true of a multicast link but not NDMA ... etc ... so here is a new link type ... some protocols will have problems, some may not ... [10:55:28] that should be "NBMA " [10:55:38] Thanks Dave! [10:55:43] "non-broadcast multi-access (NBMA) - a link to which more than two interfaces can attach, but that does not support a native form of multicast or broadcast (e.g., X.25, ATM, frame relay, etc.)." [10:56:06] --- yushun has joined [10:56:23] Clausen: DHCP w/ DHCP relays is possible ... but to do it a different set of assumptions is used [10:57:41] Clausen: ongoing partition/merging etc in MANETs is problematic, but not all MANETs may be like that ... so DHCP/relay can be OK for those ... all MANETs are not equal. Agree that this doc should not exclude some [10:59:00] Immanuel: the way the document is now is that it describes how solutions work and the assumptions they are based upon. ... but if assumptions are broken, then the existing solutions are not sufficient. So we don't disagree with what Joe M. has said. [11:00:37] Eric Nordmark: we have about 2.5 types links: mcast, point to point, and then NBMA ... the way to make them work was to transform with MARS, etc to make them look like multicast ... but there are alot of host protocols that make assumptions about link behavior, etc ... easiest might be to emulate a mcast capable link ... [11:00:56] Immanuel: are you suggest to push stuff to an interim layer [11:01:41] Nordmark: how it was done for ATM, etc ... should be examined ... adaptation layer provided something that host protocols, etc .. [11:02:42] Narten: having an adaptation layer has worked in past, may work here or not ... then stock protocols work or expose protocols ... different tradeoffs .... need to describe arch (or multiple archs) to have discussion [11:03:00] --- intvelt has joined [11:04:52] Thaler: agree mostly w/ Nordmark & Narten ... you can 1) have an adaptation layer that makes it look like an mcast link, or 2) expose it as a non-mcast, or 3) expose it as a new link type ... the job of the arch document is to clarify the link type without regard to the model used, then which choice is the MANET world making wr2 which model ... [11:05:55] Name?: is there a plan for the arch doc. and discussion of link types ... what is the plan? [11:06:19] Alex Petrescu [11:06:20] Narten: how about sending note to mailing list summarizing next steps for the document [11:06:29] Clausen: good idea. [11:07:50] Teco Boot: There is a problem wr2 address assignment, but for prefix allocation there may not be a problem? There is a difference between these two for DHCP [11:08:35] Immanuel: there are similar problems that if you don't have a structure of relaying that dynamically reconfigures when routing changes, etc then you have same problem ... there may be cases where this is different? [11:09:10] Joe Macker: this slide has the same problem as the previous ... if DHCP works then prefixes aren't a problem [11:10:34] Joe Macker: would it be the goal of this exercise to delineate the different scopes of problems you are working on. there are classes of MANET that are easier and there are harder ones ... are you only considering the completely dynamic situation ... Do you think the WG could scope back if some problems appear to be research problems but some are solvable [11:11:15] Joe Macker: from reviewing different MANET routing, there are different addressing restrictions depending upon the routing protocol ... [11:11:38] Immanuel: if you don't have full mesh connectivity, we're "in space"? [11:11:48] Joe Macker: that wasn't my question ... [11:12:02] Immanuel: there are different scenarios we're talking about. [11:13:12] Joe: The address arch is different upon routing protocol ... e.g. reactive routing hard to do longest prefix matching, etc ... when I do an addressing arch. these things need to be taken into account ... Is the group's goal to discuss the scope/tradeoffs of such things? [11:13:21] Joe: there's not just one architecture [11:13:44] Immanuel: thought we were going to be routing protocol independent [11:14:53] Ian Chakeres: Joe was talking about _what_ addresses you can assign vs. _how_ you assign them ... e.g. "how" might be protocol-independent, but "what" might be protocol-dependent (wr2 routing protocol) [11:15:49] Immanuel: for now this has not been a question ... [11:15:57] --- john.zhao has left: Disconnected. [11:16:24] Charles Perkins: wise to remain protocol independent as much as possible, but may need some way to get control signals around ... [11:16:55] Immanuel: figuring out how to assign what addresses may need to be addressed in another document ... [11:18:53] --- xiaohunhun has joined [11:19:02] Clausen: couple of things being mixed up here: ... 1) different assumptions/requirements for different routing protocols need to be understood and taken into account ... while we want to be agnostic wr2 routing, different protocols may impose different assumptions ... need to be explicit here 2) getting signals around ... and 3) what problems remain after these two. ... this domain is composed of a number of different things. [11:19:43] Clausen: encourage that we analyze this for the problem statement document ... and broader participation is encouraged. [11:22:24] Perkins: follow up on suggestion about taking time to delineate link properties ... would go a long ways to resolve issues of past couple of years. raises intriguing point ... what if we have 5-6 link types ... there will be different solutions for different link types ... there will be a range of solution details need to address these. We might be able to identify links that lead to problem areas ... [11:23:16] Alex: Perkins said something about looking at prior link types ... are we going to do this or just make comment? [11:24:12] Clausen: not aware that there have been descriptions of link types in documents that have been submitted before ... there may have been some implicit assumptions from the MANET WG domain, but not explicit descriptions. [11:24:21] Alex: so we can't re-use previous descriptions? [11:24:44] Clausen: if you can point me to a previous description, we might use it, but aware of none. [11:25:05] Perkins: we didn't make such a formal description in former documents. [11:25:32] Narten: hope this is not alot of work ... just writing down what is widely understood in the community [11:26:10] Clausen: agree ... folks have commented "why is this taking so long, its _evident_" ... but that may be communicity assumption ... [11:27:05] Immanuel: need feedback/input for security section ... work to continue. brief finished. [11:27:15] --- john.zhao has joined [11:28:05] See slides: http://www.ietf.org/proceedings/08mar/slides/autoconf-2.pdf [11:28:57] --- John Ronan has joined [11:31:32] Meeting concluded. [11:31:44] --- xiaohunhun has left [11:32:04] --- John Ronan has left [11:32:42] --- teco has joined [11:32:49] --- softgearko has left [11:33:27] --- apetrescu has left [11:33:35] --- intvelt has left [11:36:00] --- keith.brazington has left [11:37:52] --- shubranshu has left [11:41:22] --- geir has left [11:49:31] --- roberto.baldessari has left [11:52:18] --- washad has left [11:55:09] --- thomas_hc has left: Logged out [11:55:13] --- teco has left [11:57:52] --- yushun has left [12:03:44] --- badamson has left [12:07:18] --- dthaler has left: Replaced by new connection [12:11:01] --- jpc has left [12:15:44] --- omnione has left: Replaced by new connection [12:15:46] --- omnione has joined [12:19:31] --- omnione has left [12:20:59] --- john.zhao has left: Disconnected. [12:34:48] --- teco has joined [12:52:23] --- shubranshu has joined [12:55:31] --- shubranshu has left [15:27:19] --- jpc has joined [15:33:44] --- jpc has left