nemo@conference.ietf.jabber.com - 2003/03/19
[07:03] %% Yu Wanrong has arrived.
[07:11] %% Yu Wanrong has left.
[07:54] %% Yu Wanrong has arrived.
[07:55] %% Yu Wanrong has left.
[10:15] %% frodo has arrived.
[10:16] %% carlalf has arrived.
[10:21] %% ivancic has arrived.
[10:21] %% behcets has arrived.
[10:21] %% joelja has arrived.
[10:22] <ivancic> So, I'll log this for the minutes and then put it in a nicer format later for the archive.
[10:24] %% tj has arrived.
[10:25] %% jishac has arrived.
[10:25] %% sakai has arrived.
[10:25] <ivancic> Start 9:05 Agenda Bashing.
[10:25] <ivancic> Agenda:
[10:27] %% SRuffino has arrived.
[10:29] <ivancic> Agenda same as posted on IETF web.
[10:29] <ivancic> Some discussion will occur on AAA
[10:32] <ivancic> 1st item Charter updates and milestones. Charter updated Jan 03 basically text not content. Milestones were adjusted by a few months to match formation of working group.
[10:32] <ivancic> March 03 terminology doc dome
[10:32] <ivancic> May 03 submit threat analysis and security requirements
[10:33] <ivancic> aug 03 submit solution fo basic support to IESG - this is the current focus of nemo
[10:34] <ivancic> Theirry - Terminology and requirements draft discussion
[10:35] <ivancic> request to merge terminology and requirements - discussion.
[10:35] <tj> thierry asked if people want the requirements and terminology drafts to be merged
[10:35] <tj> show of hands indicates that people seem to want separate documents
[10:35] <tj> comments? pascal thubert commented in favor of keeping them separate
[10:36] <tj> samita chakrabarti - likes the idea of merging the documents
[10:36] <tj> if you merge them together? how can you combine terminology with seamoby?
[10:37] <tj> thierry - terms are already in seamoby - mobile node, access router, host mobility. other similar terms already in seamoby -
[10:37] <tj> intra-domain mobility: local mobility
[10:37] <tj> inter-domain mobility: glabal mobility
[10:38] <tj> james kempf: if you have terms that are common mobility terms, they should probably go in the seamoby doc
[10:38] <tj> it is intended to serve as a reference for the ietf
[10:38] <tj> seamoby doc is intended to avoid having huge terminology docs
[10:39] <tj> tj: how can nemo views on terms be merged into seamoby doc?
[10:39] <tj> answer: nemo terms should not be in seamoby doc, but any common mobility terms can be in there
[10:39] <tj> pascal: would someone looking for terms look in a requirements document
[10:43] <tj> asked question again. it seems like 2/3 want separate documents,
[10:43] <ivancic> second vote taken - seems like group prefers separate documents.
[10:43] <tj> thierry would like to keep them in the same doc, so we will follow up on the list
[10:44] <tj> (tj also made comment in favor of 2 documents)
[10:45] <tj> Thierry is describing multi-homing cases -- multi-addressed, multi-interfaced, multi-linked, multi-sited
[10:46] <tj> any comments?
[10:46] <ivancic> opinions on multihoming.
[10:46] <tj> keith moore - mutli homing address selection does not work. applications know better. no objection to definng term, but ..
[10:47] <tj> don't think it's useful to take that particular use of the word multihoming and think that it applies to this situation.
[10:47] <tj> if mr's need multiple prefixes, we might need a new word for it.
[10:48] <tj> erik nordmark - the document has definitions for these specific things, with multi-homing as catch-all name
[10:49] <tj> chan-wah ng - maybe we can define the most specific terms like multi-address, so we can know which scenario we are talking about
[10:49] <tj> pascal - i do agree w/ chan-wah, we should have more words so we know the situation
[10:50] <tj> erik - it might make sense to finish the discussion with the drawings that are given in the multi-homing draft. we should have a shared understanding of the different ways to do multihoming
[10:50] <tj> thierry - does m.h. mean that interfaces are to be available simultaneously or not
[10:51] <tj> vijay devarapalli - just because mobile net has 2 separate interfaces, doesn't make it multihoming. both interfaces have to be active at the same time.
[10:51] <tj> thierry - what about if you have multiple addresses?
[10:51] %% mallman has arrived.
[10:52] <tj> pascal - if you have multi address, you have several tunnels, each one being a different interfaces
[10:52] %% mallman has left.
[10:52] <tj> hong-yon lach - you are missing some words, like simultaneously active with respect to nemo operation
[10:53] <tj> pascal - chan-wah's paper/presentation will address this
[10:53] <tj> Thierry - now to requirements document discussion
[10:53] <ivancic> hong-yon lach - suggestion to firm up definition to include simultaneously active interfaces
[10:55] <tj> keith moore - basic problem in many wg's. requirements should be changed to "design goals". usually it's premature to define requirements now
[10:55] %% mrose has arrived.
[10:55] <ivancic> Agenda General Propose Guidelines for the Solutions. Remove SHOULD and MUST to "should" and "must"
[10:56] <ivancic> Other Requirements - Should we be concerned about location privacy?
[10:57] <ivancic> Do we need to add text about benefit / use of multihoming?
[10:58] <ivancic> tj - any discussion on design goals and versus requirements?
[10:59] <tj> m. kim - it's unfortunate ietf has gone down requirements road, but i don't think we can change that here. regarding fault tolerance, it relates to multihoming. we need to be more specific about what it intends to do. we should specify more distinctly the reasoning for each goal. it might go into general guidelines, or requirements.
[11:00] <ivancic> w. kim - Fault tolerance and multihoming. Is multihoming being done for fault tolerance
[11:00] <tj> pascal - about location privacy. there are two things. one is for the visitor, one for visited network
[11:01] <ivancic> T.E. - One line requirements.
[11:02] <ivancic> T.E. How many layers of nesting?
[11:02] <tj> thierry - should we remove the 'arbitrary levels of nesting'?
[11:02] <tj> michael thomas - how could you prevent it?
[11:03] <tj> keith - performance is really the factor. what are you trying to make work *well*?
[11:03] <tj> hesham s. - I don't think you can have this restriction. if you have proxy RA, even if you have /64, it can propogate beyond the network. it would be nice if the solution just works
[11:03] <tj> i don't think we need a requirement for x levels of nesting
[11:05] <tj> will ivancic - i think taking out the text underlined should be fine. i don't htink you can specify the levels or enforce it
[11:05] <tj> mobile net below doesn't know anything about the network above
[11:06] <tj> hesham - 0 levels of nesting or 1, we should not put a requirement on that. i would pick 2+, but i don't think we need a number
[11:06] <tj> but there's no point in putting a number but you can't stop it
[11:07] <tj> keith m - must support means it must work and be useful. i doubt arbitrary levels of nesting is really a requirement that you can impose on yourself. if you can identify a minimum numer of levels then that's ok. you're not going to arbitrarily restrict it, but there might be some performance issues for x layers.
[11:07] <ivancic> w.ivancic - do not put restriction on nesting, it cannot be enforced.
[11:07] <tj> pascal - we already have use cases where the nesting occurs
[11:08] <tj> later we will be doing evaluation of proposals. we should use this to determine which one is preferred
[11:08] <ivancic> pascal - preferred approach will result from evaluations, not requirements.
[11:09] <tj> thierry - can we remove definitions of multihoming in R12?
[11:09] <tj> vijay - i think we should keep this to keep things clear
[11:09] <ivancic> T.E. mutlihoming requirements
[11:11] <ivancic> TJ - what is really meant by "support"? Is this an implementation issue rather than a requirements issue.
[11:13] <ivancic> T.E. Should solution preserver established session through another interface?
[11:14] <tj> confusion about numbering of requirements - R12, sub 13 (erik comment - bug in document numbering)
[11:16] <ivancic> Question about mutlihoming and various link bandwidths and the ability to ensure session connectivity.
[11:18] <tj> boeing - links to an aircraft are not all equal. some will handle commercial isp traffic, some handle atm traffic, some handle voice. different bandwidth and requirements on the ground. you can't maintin internet traffic for low-speed rf link
[11:19] <ivancic> R14 requirement - signaling messages between the HA and the MR MUST be secured.
[11:20] <tj> erik - you are using tunneling, and tunneling can be secured w/ ipsec etc. so we don't need this requirement (R14.5) here.
[11:20] <tj> R14 is about signaling, not payloads
[11:21] %% SRuffino has left.
[11:21] <tj> Writing these types of documents is hard - getting the right level of description
[11:21] <tj> vijay - which NEMO signaling message needs to be encrypted, and why?
[11:21] <tj> what is one example?
[11:21] <tj> there are none!
[11:22] <tj> mipv6 says that BU & BA needs to be authenticated, not encrypted. HOTI needs to be encrypted because RR becomes weaker without it.
[11:22] <tj> we have no message like that right now for NEMO, so they need to be authenticated, not encrypted
[11:23] <tj> michael thomas - somebody in the middle of the network can track your movement, which is a location privacy concern. it ought to have that basic privacy
[11:23] <tj> hesham - but people can always see your home and care-of address, so it's always visible
[11:25] <ivancic> TJ - suggestion appears to be consensus to remove or modify 14.4 "signaling messages MUST be encrypted". Will move to the maillist.
[11:25] <tj> R17: should we make sure that the protocol is backward compatible. what is the list of protocols that must be backward compatible? we can discuss this on the list
[11:26] <tj> michael ohomas - for R16, how do you test for that? that you're a good network citizen?
[11:26] <ivancic> Question regarding R16 - How do we test for solution no impacting on the routing fabric.
[11:26] <ivancic> Suggestion to remove R16.
[11:26] <tj> michael - Nuke R16. it's a feel-good requirement
[11:27] * tj has changed the subject to: NEMO Working Group Meeting - LIVE
[11:28] <tj> pascal - signaling is not something we can make as a requirement. what does minimize mean?
[11:28] <tj> so it's not a requirement
[11:29] <tj> will i. - you shouldn't have separate requirements for aeronautics, etc. you should take them into consideration and cross administrative domains, put them in the req draft
[11:30] <ivancic> How do we get input from other groups for their needs - aeronautics, etc...
[11:31] <tj> vijay - you can't have a requirement on cross-domain roaming
[11:31] <tj> (thierry asked if we should put this req back
[11:32] <tj> Chan-Wah is presenting the AAA / NEMO discussion on the mailing list, and what are the conclusions and actions from that
[11:32] <ivancic> AGENDA - AAA
[11:32] <ivancic> Issues - Nigration transparency and AAA policy transparency.
[11:34] <tj> michael thomas - does this working group need to consider this?
[11:34] <tj> thierry - the question is where should we discuss this
[11:35] <tj> Erik - Previous slide, #1 - there is another way of describing that at a higher level of abstraction. With Mobile Networks, you might do a nesting of AAA relationships
[11:36] <tj> One way of describing #1 is that you want this nesting to be transparent as much as possible. #2 says that there might be some cases that you want to expose the changes in one level of nesting to propogate down
[11:36] %% carlalf has left.
[11:36] <tj> In this working group, it might make sense to think about what is a reasonable model to think about AAA models to have a shared understanding of how this (NEMO) will fit in with AAA
[11:38] <tj> tj - do you think that there are actually requirements based on this nesting mode, or is it just a matter of understanding it?
[11:38] <tj> erik - might depend on business issues. understanding it is the higher good
[11:39] <tj> michael thomas - i'm skeptical for there being "a" AAA model. my preference is to allow this to evolve more before we try to determine what to do. may not have much to do with traditional AAA
[11:39] <tj> coming up with single model or scenarios might be premature
[11:39] <ivancic> micheal thomas - Very unclear as to what AAA models would be. We need to let this evolve.
[11:40] <tj> alper yegin - we should identify differences between mobile ip and mobile networks. For MN, each "A" in AAA is tightly coupled in a single transaction.
[11:40] %% mark.ellison has arrived.
[11:40] <tj> in the case of mobile networks, we want ot have transparency of the network
[11:41] <ivancic> AGENDA IPv4 traversal - pascal
[11:43] <ivancic> Issues - Satellites, GPRS uses PAT Public Access (DSL, etc...)
[11:44] <ivancic> pascal - Should be able to traverse IPv6, IPv4 public and IPv4 private as well as PATs and NATs.
[11:47] <ivancic> Question of requirement to work over NATs as NATs are very unpredictable and constantly evolving.
[11:49] <tj> billing aspects might be different, which might lead to a different AAA modepfd
[11:49] <tj> oops
[11:50] <tj> disregard that
[11:50] <tj> pascal - NATs are already there
[11:50] <tj> keith - well, trying to make your protocol work in a broken network is a rathole
[11:53] <ivancic> General Discussion - NATs are bad, but they exist and must be addressed - but perhaps not be a hard and fast requirement.
[11:54] <ivancic> keith - suggest this is goal to work with NATs, but not be a requirement.
[11:56] <tj> tj - There is a decision here, which is (a) require that NATs somehow be supported, (b) design for a NAT-free world and defer NAT traversal to another WG or later here,
[11:57] <tj> erik - 3rd option - might be simplifying assumption, which is that other WG such as v6ops might come up with a v6 over v4 nat, which can be used to layer NEMO
[12:00] <ivancic> consensus is to not have requirement for NAT and PAT transversal - although there is nothing to preclude as solution.
[12:00] <ivancic> AGENDA - Mulitihoming Scenarios.
[12:01] <tj> (to add to will's comment above - I asked a question whether people think a requirement should be added to the basic spec requirements that NAT traversal must be supported/work. about 1/4-1/3 indicated yes, 2/3-3/4 raised hands for no)
[12:03] <tj> link recovery is desirable, but from thierry's talk, maybe it should not be a requirement
[12:03] <tj> hesham - for ipv6 there is a mechanism, but for nemo you say it is undesirable. why?
[12:04] <tj> chan-wah - my thinking was that mult egress links has active open paths. the MR should actively switch to different route instead of waiting for MNNs to discover
[12:04] %% mrose has left.
[12:04] <tj> hesham - I agree, but is this something specific for NEMO, or a generic problem?
[12:04] <tj> chan-wah it is generic, but in mobile nets, failure happens more often
[12:05] <tj> Erik - first bullet says that in dynamic routing protocol, recovery taes a long time. but this might not be true. if you run a dynamic rting proto over tunnel, it can recover as fast as you want. is there something unsatisfactory with doing that/
[12:06] <tj> erik - my mental model is that there is one organization that runs HA, and MR. one prefix for MoNet. if you do routing advertisements, what issues of mobility or wireless flakiness will pop up making you do something different?
[12:06] <tj> pictures in draft will be useful to discuss multihoming cases and understand them
[12:07] <tj> will i. - one thing to consider with multihoming and fast handovers is to think about radio technologies, links going up and down and flapping interfaces, switching too quickly might be a problem
[12:09] <ivancic> chan-wah - multiple address on single interface does not appear to be an issue to be addressed by nemo.
[12:09] <tj> c.w. -multiple MRs, different home agents, requires coordination between HAs
[12:10] <tj> alper - this is a fancy feature we shouldn't have to worry about at this time
[12:10] <tj> will - i don't think it has to be put in the basic draft. it's useful for geographically diverse locations of HA
[12:11] <tj> hesham - I don't think you can have different home agents advertising the same prefix
[12:13] <tj> tj - well they will advertise each others' prefixes
[12:13] <ivancic> multiple HA is useful for fault tolerance.
[12:15] <tj> felix wu (uc davis )multiple home agents should be considered, it should go into the base protocol
[12:16] <tj> some discussion - maybe this is already supported by mobile ip.
[12:16] <tj> felix - ok, I think this is important to consider though - maybe multiple HAs supporting an MR (or MN) at the same time
[12:16] <tj> alper - I don't see any integration requiring coordination between HAs
[12:17] <tj> there is no mobile node choosing a mobile router. it just picks a prefix.
[12:18] <tj> pascal - two mobile routers can serve the same prefix. we may ask the MR to tell the HA which prefix it's serving. in that case, it may have to tell multiple HAs, or have a single registration, etc
[12:18] <ivancic> pascal - mr may want to tell two different HAs the same prefix.
[12:19] <tj> thierry - presenting slides for ryuji wakikawa on new support solution
[12:19] <ivancic> AGENDA - Basic Nework Mobility Support.
[12:20] <tj> Please comment on mailing list for technical discussions so ryuji can answer
[12:22] <tj> vijay - question: what if your mobile network has more than one prefix?
[12:22] <tj> how do you create routes at the home agent for both prefixes? instead of having a prefix suboption, you are restricting yourself to one prefix
[12:23] <tj> thierry - you would send a BU with mult. prefix suboptions
[12:23] <tj> vijay - but you are using prefix length
[12:23] <tj> thierry - you have a difference in the egress interface
[12:23] <tj> (open question)
[12:24] <tj> psacal - why do you care that the MR has an address in this prefix?
[12:24] <tj> thierry - might not be necessary
[12:26] <tj> michael - it's not clear the ha/ipsec draft works with this
[12:26] <tj> (with prefixes)
[12:26] <tj> vijay - i think ryuji does provide examples
[12:27] <tj> vijay - you always have to maintain a binding cache entry on the home agent, even when you're at home.
[12:27] <tj> so I don't know why dergistration is easy
[12:28] <tj> pascal - problem not addressed in draft - if you want more than a single home agent, you have to do some sort of undefined coordination
[12:28] <tj> this reminds us of multihoming, and it's the same topic here
[12:31] <ivancic> T.E. Tested and implemented under FreeBSD-Release
[12:32] <ivancic> TE- to do Multiple home agents, etc....
[12:33] <ivancic> TJ AGENDA- Basic NEMO Support starting point.
[12:34] <ivancic> Delivery date for Base Document is August 03.
[12:35] <ivancic> Requirements will be finalized by end of this month.
[12:39] <ivancic> vijay - threats analysis well understood for basic support.
[12:41] %% sakai has left.
[12:41] <ivancic> What is distance between three drafts? Is it large or can they easily be combined.
[12:42] <ivancic> tj - reverse tunneling is common.
[12:43] <ivancic> what about a bare-bones specifications where optimizaitons can come later?
[12:45] <ivancic> suggestion draf-petrescu-nemo-mrha-02 should included analysis of any new proposals to ease use by group.
[12:49] <ivancic> pascal - a draft may meet basic approach, but not be well positioned to address future needs.
[12:50] <ivancic> pascal - suggest starting with TJ's draft and insert material from other drafts into this draft.
[12:51] %% behcets has left.
[12:52] %% ivancic has left.
[12:52] %% jishac has left.
[12:52] %% frodo has left.
[12:55] <tj> So I asked two questions at the end:
[12:56] <tj> 1. Do people feel comfortable choosing a draft and proceeding with editing?
[12:56] <tj> The vote wsa something like 2 to 1.
[12:56] <tj> A suggestion was made that MRTP wsa most complete, and another was made that the authors of the drafts
[12:56] <tj> could get together and combine some features.
[12:57] <tj> So next I asked the question, do people feel comfortable with the idea of using MRTP as a starting point, and having the three drafts' authors collaborate on editing process
[12:57] <tj> the vote this time was given by a large number in the room, and was a unanymous yes.
[12:57] %% joelja has left.
[12:57] <tj> Thanks everyone for participating; see you on the mailing list.... http://www.nal.motlabs.com/nemo/
[12:58] %% tj has left.
[14:17] %% mark.ellison has left.
[14:26] %% behcets has arrived.
[14:26] %% behcets has left.