[03:49:27] --- mstenber has joined
[04:04:58] --- hartmans@jis.mit.edu/owl has joined
[04:05:02] --- mrichardson has joined
[04:07:03] <mstenber> grumble, no scribe?
[04:07:40] <mrichardson> hi.
[04:07:45] --- miaofuyou has joined
[04:07:53] <mrichardson> Paul is talking about the agenda for this morning.
[04:08:11] <mstenber> ok.. I'm mostly curious about results, not much else.
[04:08:21] --- kuro has joined
[04:08:31] <mstenber> (I've read the problem stmt draft, and been on few discussions on the topic - unfortunately had different WG to go to at same slot)
[04:09:14] <mrichardson> Slides are http://www3.ietf.org/proceedings/07mar/agenda/isms.txt
[04:09:22] <mrichardson> http://www3.ietf.org/proceedings/07mar/slides/ifare-0.pdf
[04:09:27] <mrichardson> http://www3.ietf.org/proceedings/07mar/slides/ifare-1.pdf
[04:10:41] <mrichardson> Vidya is providing background.
[04:10:59] <mrichardson> mobileIP vendors said they didn't want to do dynamic key setup for mobile IP SA.
[04:11:08] <mrichardson> takes too long, they claimed.
[04:13:56] <mrichardson> a dinner occured in San Diego...
[04:14:01] --- bless has joined
[04:14:33] --- FDupont has joined
[04:14:45] --- ldondeti has joined
[04:14:55] <mrichardson> plea for minute taker...
[04:15:14] --- ShoichiSakane has joined
[04:15:22] --- hichem.maalaoui has joined
[04:16:13] <ldondeti> Ekr says he is not sure whether the work needs to be done
[04:17:17] <ldondeti> another person at the mic: agrees with Eric
[04:17:30] <ldondeti> says mobility people learned about this 2 days ago
[04:18:14] <ldondeti> Vidya says the info was sent to MIP6, INTAREA, IPSEC, and SAAG lists
[04:18:53] <mrichardson> change to agenda.... problem statement will be done before charter.
[04:18:54] <ldondeti> raising hands: problem statement discussion first
[04:19:05] <ldondeti> Yaron presenting
[04:23:28] --- ekr has joined
[04:23:57] <ekr> So, how many clients are we talking per gateway?
[04:24:03] <mrichardson> slides 4.
[04:24:14] <ldondeti> how many?
[04:24:23] <ldondeti> I have heard large numbers
[04:24:24] <mrichardson> uhm.... order of thousands?
[04:25:17] <ldondeti> there you go: Yaron says 100s of thousands
[04:25:32] <ldondeti> Ekr says modern processors can do large number of DH operations
[04:26:29] <mrichardson> 100,000 clients at 1000 DH/second = 3 minutes to get reconnected today.
[04:26:40] <ldondeti> so the last client is screwed then
[04:26:48] <ldondeti> it waits 3 minutes to get anywhere
[04:26:59] <mrichardson> sorry, that's 2 minutes.
[04:27:08] <ldondeti> well, same diff ;)
[04:27:13] <mrichardson> (can't divide by 60 before 11am)
[04:27:26] <ldondeti> I can understand the feeling
[04:28:01] <ldondeti> EAP is being discussed
[04:28:12] <ldondeti> Ekr says (or did he say) provisionally is a problem
[04:28:14] <mstenber> those boxes have usually something else to do too, and it is not just EAP operations, but remove AAA stuff etc.
[04:28:23] <mstenber> remote AAA even
[04:28:30] <mrichardson> my measurements were 20ms per DH operation on 3Ghz processor. With a slow hardware offload, it was 200ms :-)
[04:28:33] <ldondeti> Paul says nothing to do with DH
[04:28:36] <mstenber> radius server for example, or telco infra (EAP-SIM auth), it can take ages..
[04:29:07] <ldondeti> Tero says it takes 1/2 a minute to know that the other end is dead
[04:29:15] --- miaofuyou has left: Replaced by new connection.
[04:29:20] <mrichardson> (I'm not convinced it has to take that long)
[04:29:41] <mstenber> if you run BFD it can be done much faster (at some performance cost of course)
[04:29:44] --- miaofuyou has joined
[04:29:46] <mstenber> depends on applications involved :)
[04:29:52] --- nov has joined
[04:29:53] <ldondeti> we are discussing numbers here
[04:30:26] <ldondeti> failure detection is slow
[04:32:36] --- FDupont has left
[04:34:48] <ldondeti> so Ekr you are right for IMS for SIP when IPsec is used in 3GPP, AKA is used
[04:34:58] <ldondeti> for Mobile IPv6 proper it is IPsec with IKEv2
[04:35:07] <ldondeti> for WLAN interworking it is IKEv2+ IPsec
[04:35:26] <ldondeti> you are just working with partial information
[04:35:57] <ekr> Yes, but one (SIP + AKA) is what is actually used whereas the other is specified and basically unused.
[04:36:18] <ldondeti> today? sure
[04:36:27] <ldondeti> do we want people to use MIPv6?
[04:36:36] <ldondeti> that is pitched with RFC 4285
[04:38:09] --- sk137 has joined
[04:38:15] <ldondeti> Sam brings up a good issure: we need to get a trust model defined so we can analyze this
[04:39:05] * mrichardson notes that this is about *IPsec* SA failover, *NOT* VPN failover. VPN is just one Use Case that involves IPsec.
[04:39:14] <ldondeti> yeah, I know
[04:39:16] <ldondeti> oh well!
[04:39:27] <ldondeti> we have tunnel vision is all this is
[04:40:29] <ldondeti> let me say sth here to Ekr's point (I know he is at the mic)
[04:40:40] <ldondeti> the IETF moves slowly
[04:41:37] <ldondeti> if MIP6 with IKEv2-IPsec needs to be successfull, we need stuff like this
[04:42:01] <ldondeti> chicken and egg comes to mind when ekr says stuff is unused today
[04:44:38] <ldondeti> Steve Kent explains the trust model
[04:47:26] <ldondeti> I see several motivating factors here, but none seem compelling by itself (is that what he is saying)
[04:47:31] <ldondeti> he speaks too fast :)
[04:47:39] <ldondeti> I guess there is consensus on that ;)
[04:47:51] <ldondeti> oh Ekr said that
[04:47:58] <ldondeti> not Steve Kent!
[04:48:08] --- joonhyung.lim has joined
[04:48:18] <ldondeti> Ekr: if EAP is the problem, perhaps that needs to be cached
[04:49:03] <ldondeti> Kuntal: talks about transparent failover
[04:49:28] <ldondeti> the problem is not because HAs are slow or if EAP takes too long
[04:49:37] <ldondeti> says sth abt mobiles waking up
[04:49:54] <ldondeti> I don't understand what he is saying abt waking up mobiles
[04:51:08] <ekr> I don't understand this point.
[04:51:18] <ekr> 1. Even ifare is going to require at least one RT.
[04:51:27] <ldondeti> y
[04:51:34] --- tim.polk has joined
[04:51:44] <ldondeti> the waking up of mobiles thing doesn't make sense
[04:51:48] <ekr> 2. I don't understand the issue of crashing. The way you deal with HA for hardware or software failures is to have clusters.
[04:51:59] <ekr> This only makes sense if you have geographic dispersion
[04:52:23] <ldondeti> ya, what if mobile IP assigns a new HA
[04:52:36] <ldondeti> all those mobiles that had a new HA assigned may do IKEv2
[04:53:03] <ldondeti> Kent: transparent redundancy
[04:53:14] <ldondeti> says that 90% are in dormant mode
[04:53:17] <ldondeti> I don't see it
[04:53:22] <ldondeti> it's very today-centric
[04:54:03] <ldondeti> with mobile broadband, I don't see how 90% dormancy is going to work!
[04:54:13] <ldondeti> we hope more people browse more often :P
[04:54:26] <hartmans@jis.mit.edu/owl> Proposed requirement to deal with the waking up mobiles problem: failure recovery does not involve client interactions.
[04:54:45] <ldondeti> The paging issue is orthogonal to this
[04:55:06] <ldondeti> I can talk to people who know paging as the back of their hand, but from what little I know these are orthogonal issues
[05:02:45] --- fparent@jabber.org has joined
[05:05:06] <hartmans@jis.mit.edu/owl> Test
[05:11:09] <ldondeti> I am trying to stay away from the mic
[05:11:18] <ldondeti> I am glad Tero is making the points I wanted to make :)
[05:11:24] <mstenber> which points are those?
[05:11:30] <ldondeti> on the paging stuff:
[05:11:39] <mstenber> ah, those were by him
[05:11:45] <ldondeti> it is not like the GW wakes up clients and initiates failover recovery
[05:11:50] --- lebobits has joined
[05:11:52] <mstenber> indeed :)
[05:11:54] <ldondeti> no no other ppl brought up paging
[05:12:10] <ldondeti> and Tero beautifully says it is nonsense (without being obnoxious)
[05:12:17] <lebobits> did anyone catch in notes what Tero just said?
[05:12:20] <ldondeti> no
[05:12:24] <ldondeti> I am going to write up here
[05:12:27] --- stjepan.gros has joined
[05:12:43] <ldondeti> the other aspect is there is no way gateways can synchronize state across vendor implementations
[05:12:52] <lebobits> seemed to be lots of agreement about what Tero said, so lets catch it
[05:12:59] <hartmans@jis.mit.edu/owl> The argument was not that all clients were woken up but that in order to continue conversations with active clients you needed to interact with those clients.
[05:13:00] <ldondeti> and that to sync up state packet by packet would be very expensive
[05:13:21] <hartmans@jis.mit.edu/owl> O, who needs replay protections?:-)
[05:13:24] <ldondeti> it can be done, but only when the GWs are next to each other or have dedicated links
[05:13:25] <mrichardson> if you have dpd on, with low timeout values, then almost all the clients discover the gateway is down at about the same time.
[05:13:44] --- miaofuyou has left
[05:13:50] <ldondeti> yep! I guess let's forget replay protection :P
[05:13:53] <ldondeti> we can go home then
[05:13:57] <lebobits> paul, the solution nazi...
[05:14:05] <lebobits> <grin>
[05:14:18] <mrichardson> if you are trying to do VoIP, the dpd had better be sub-second timers.
[05:14:39] <ldondeti> exactly
[05:14:43] <ldondeti> thank Michael
[05:15:03] <ldondeti> a lot of ppl work at various layers to make sure the failover works in those layers
[05:15:13] <ldondeti> this is an effort at this "layer" for lack of better word
[05:15:36] <mrichardson> so, we use dpdtimeout= 3*dpddelay, so if you do 0.5 second DPDs,then that means that after 1.5s, 100,000 clients mover to another gateway, and with the hardware that EKR
[05:17:27] <ldondeti> can someone summarize ekr
[05:17:29] <ldondeti> I missed that
[05:17:42] <ShoichiSakane> how many movers does a single gateway often supports?
[05:18:29] <ekr> this whole "steve kent"/"kent leung" confuses me.
[05:18:39] <ldondeti> :)
[05:18:46] <ldondeti> be glad they work in different areas
[05:18:47] <ekr> So, my point is that there are basically two cases:
[05:18:57] <ekr> 1. Two gateways next to each other.
[05:19:07] <ekr> 2. Two gateways that are geographically distributed.
[05:19:15] <ldondeti> sure, we are talking abt 2 here
[05:19:25] <ekr> And then cross that with vender hetero/homogeneity.
[05:19:27] <ldondeti> (we are also talking abt 1, but irrelevant)
[05:19:38] <ldondeti> yep
[05:20:02] <ekr> So. I don't believe in hardware failures, since it's cheaper to cluster your hardware so it doesn't crash.
[05:20:15] <ekr> so. that leaves us with the case where you have two machines and one loses its link.
[05:20:19] <ldondeti> hang on
[05:20:24] <ldondeti> what if someone flipped a switch
[05:20:35] <ldondeti> all the mobiles can't talk?
[05:20:48] <ekr> What do you mean flip a switch?
[05:20:58] <ldondeti> well, let's say power failure
[05:21:01] <ldondeti> site failure
[05:21:07] <ldondeti> infrequent I agree
[05:21:17] <ekr> Sure, site failure might as well be link failure.
[05:21:21] <ldondeti> ok
[05:21:25] <ldondeti> oh sorry
[05:21:26] <ekr> That said, datacenters basically don't lose power.
[05:21:28] <ldondeti> I missed that :)
[05:21:48] <ldondeti> wishful thinking Ekr think other countries
[05:22:36] <ekr> So, then I claim that two gateways from different vendors won't be able to do state transfer even between two devices that are next to each other.
[05:22:55] <ldondeti> sure
[05:23:08] --- miaofuyou has joined
[05:24:00] <ldondeti> MR speaking:
[05:24:35] --- ShoichiSakane has left: Replaced by new connection
[05:24:37] <ldondeti> HA as in High availability
[05:24:42] <ldondeti> HA is also home agent
[05:24:56] --- fparent@jabber.org has left: Replaced by new connection
[05:25:23] <ldondeti> MR: seemless failover is one case
[05:25:37] --- ShoichiSakane has joined
[05:25:40] --- fparent@jabber.org has joined
[05:26:59] <ldondeti> MR says that fast session resumption is valuable
[05:27:16] <ldondeti> where you turn on a cell phone and it doesn't have to do EAP or what not for IPsec session resumption
[05:27:27] <ldondeti> so the cost of the box goes down if we can be efficient
[05:27:41] <ldondeti> that is refreshing :)
[05:28:01] <ldondeti> Bob Hinden: agree with ekr
[05:28:32] <ldondeti> the most useful case is where you are trying to maintain real-time connection state
[05:29:17] <ldondeti> ekr: geographically distributed gw or loss of link to the gw will need client involvement
[05:29:24] <ldondeti> rapid reconnect is another use case
[05:29:38] <ldondeti> these are use cases where interoperability is required
[05:29:58] <ldondeti> Tero:
[05:30:24] <ldondeti> (hey guys, I am trying to pay attn and type and not so good at it; please correct me if I misquoted or what not; unintentional I assure you)
[05:30:38] <ldondeti> what about MOBIKE interactions
[05:30:42] <mrichardson> (you are doing better than I)
[05:30:55] <ldondeti> what if the client moves and failover occurs
[05:31:04] <ldondeti> can we make them work together
[05:31:10] <ldondeti> Vidya agrees that it is a good point
[05:31:28] <ldondeti> MOBIKE deals with tunnel mode at the moment
[05:31:42] <ldondeti> transport mode is also a req here and clearly the interaction is part of the goals
[05:32:03] <ekr> but transport mode for mobike seems out of scope here
[05:32:42] <ldondeti> no no I meant transport mode and tunnel mode IPsec failover is what I am getting at
[05:33:03] <ldondeti> MOBIKE for reasons that were articulated when we were discussing it ruled out transport mode
[05:33:52] <ldondeti> and MOBIKE is for the client signaling that its address changed (the part whose address changed is the one initiating the signaling)
[05:34:10] <ldondeti> IFARE stuff is where the client is signaling to an entity whose address changed
[05:34:27] <ldondeti> s/the part whose/the party whose
[05:34:30] <ldondeti> Greg speaking
[05:34:34] <ldondeti> new slide: colorful
[05:35:32] <ldondeti> Greg says trying to solve the interoperability of transparent failover is a non-starter
[05:35:46] <ldondeti> ppl hav their solutions and that's that
[05:36:13] <mrichardson> not NY and Dubai. LA and Dubai. They are equidistant from Auckland, according to NZ attendees...
[05:36:23] <ldondeti> cool!
[05:36:51] <ldondeti> Yaron:
[05:36:52] <mrichardson> and LA and Dubai can have lots of *Trans-atlantic* bandwidth, while Auckland is either on one side, or the other side, of the Taiwan cable break.
[05:37:35] <ldondeti> site failover is one issue, but link failover needs to be considered as well
[05:38:11] <ldondeti> ekr says if the link failed why would the client go to the same site (is that it?)
[05:38:23] <mrichardson> the client can try all links when the link fails...
[05:38:30] <mrichardson> if might find the original link works again.
[05:38:46] <mrichardson> it might be the boxes in between failed and rebooted, or the cluster failed.
[05:39:03] <ldondeti> u saw what ekr said earlier hw failures are rare
[05:39:08] <mrichardson> (If Yaron, who has been doing this stuff the longest, I think, says it happens, then I think it does)
[05:39:18] <ldondeti> I will take that :)
[05:39:41] <ldondeti> Kuntal talks about MIP6 applicability
[05:39:43] <mrichardson> also, there is a more important case: which is operator failure.
[05:39:51] <mrichardson> i.e. unplug wrong UPS.
[05:39:58] <mrichardson> or wrong side of UPS.
[05:40:11] <ldondeti> hey I sort of said that earlier and didn't go far with ekr
[05:40:14] <ldondeti> :)
[05:40:24] <ldondeti> but failures are possible for various reasons
[05:40:48] <ldondeti> mip6 says MUST for signaling protection
[05:40:54] <ldondeti> doesn't happen so often
[05:41:04] <ldondeti> argues that ESP going out of sync is less likely
[05:41:37] <ldondeti> Vidya says there are other use cases too
[05:41:49] <ldondeti> so is it alright if ESP goes out of sync?
[05:42:00] <ldondeti> what are we saying here? we get replay protection sort of?
[05:42:36] <ldondeti> Tero:
[05:42:54] <ldondeti> I don't care about MIP6
[05:43:00] <ldondeti> I want the solution to be generic
[05:43:19] <ldondeti> we are working on IPsec here
[05:43:32] <ldondeti> Vidya clarifies that we do want to provide guidance on how to use it
[05:43:45] <ldondeti> we don't want to design protocols for a single use case
[05:43:47] <ldondeti> Sam:
[05:44:04] <ldondeti> Tero's approach does not work for MIP6
[05:44:11] <ldondeti> why? ask a few people
[05:44:33] <ldondeti> MIP6-IKEv2 spec involves fairly closely related triggers between MIP6 and IPsec
[05:44:38] <ldondeti> they are not decouplable
[05:44:41] <ldondeti> I don't agree
[05:45:13] <ldondeti> Vidya says she doesn't seem to see what Sam is saying
[05:45:28] <ldondeti> Tero agrees with Vidya
[05:45:37] <ldondeti> IPsec for MIP6 is not different
[05:45:52] <ldondeti> Vidya says she knows of an implementation of MIP6 which uses Tero's code
[05:46:03] <ldondeti> Sam's clarification:
[05:46:21] <ldondeti> arbitrary IPsec cannot be used with a HA
[05:46:29] <ldondeti> again I don't know what that means
[05:46:59] <ldondeti> I think a compliant IPsec implementation should work with MIP6's use of IPsec
[05:47:07] <ldondeti> otherwise, we failed in the IETF in doing this thing
[05:47:13] <ldondeti> I could be wrong, but that's just my take here
[05:47:34] <ldondeti> Kent L: are we designing a generic solution that will also work with MIP6
[05:47:41] <ldondeti> and that seems to be what we are doing here
[05:47:48] <ldondeti> ???:
[05:48:06] <ldondeti> is it possible for a mobile client to have two connections?
[05:48:29] --- shpark has joined
[05:49:51] <ldondeti> Sam speaks:
[05:50:04] <ldondeti> trying to rule things out of scope
[05:50:06] <ldondeti> some hums
[05:50:21] <ldondeti> who believes cross-gw vendor interoperability is sth to work on
[05:50:26] <ldondeti> need to rephrase that
[05:50:38] <ldondeti> Paul is writing
[05:50:41] <ldondeti> let's use that
[05:51:16] <ldondeti> we have people saying that that doesn't work
[05:51:22] <ldondeti> same said lots and that is being disputed
[05:51:44] <ldondeti> GregL: if two boxes sync'ing state, we don't want to solve that problem
[05:51:56] <ldondeti> geographical distribution is sth that we do wnat to solve
[05:52:08] <ldondeti> Sam: I do understand your point Greg
[05:52:24] <ldondeti> Sam says Tero said that things won't work
[05:52:27] <ldondeti> Tero is up
[05:52:32] <ldondeti> MR:
[05:52:35] <ldondeti> I disagree
[05:52:56] <ldondeti> some people said that inter-vendor gw interop is not going to happen and others said it is
[05:53:13] <ldondeti> it is not whether GW vendors interoperate directly
[05:53:21] <ldondeti> it is about whether they can interoperate with client
[05:54:56] <ldondeti> Greg: we might go to the step and say that a blob is written by vendor A and vendor B shd be able to read it
[05:55:54] <ldondeti> Tero: I was saying that if the client isn't involved we aren't going to do gw-gw interoperability
[05:56:01] <ldondeti> but with client involvement sure!
[05:56:14] <ldondeti> so disagrees with Sam's summary of his statements then
[05:56:47] <ldondeti> Tero was talking earlier abt how different vendors hav different sense of the state
[05:57:03] <ldondeti> but then he says we can extract enough of it in a form that is shareable via a client
[05:57:13] <ldondeti> and all along that is how I had been thinking about it
[05:57:23] <ldondeti> there is a logical disconnect there, but I won't go into it here
[05:57:37] <ldondeti> GregL:
[05:58:24] <ldondeti> we don't wnat to make syncro across GWs interoperable; we are not interested
[05:59:13] <ldondeti> Greg also talking abt interop through state transfer via clients and need a multi-vendor solution
[05:59:24] <ldondeti> Kuntal misunderstands ....
[05:59:55] <ldondeti> Sam trying to rule out sth
[06:01:29] <ldondeti> who is interested in SA synchronization between vendors
[06:01:34] <ldondeti> some confusion
[06:01:35] <ldondeti> Ekr:
[06:01:50] <ldondeti> the one we hummed on I am not sure what we hummed on
[06:02:01] <ldondeti> Sam: I didn't understand what you said Ekr
[06:02:03] <ldondeti> Steve K:
[06:02:36] <ldondeti> I realize that different implementations do stuff diff
[06:02:45] <ldondeti> but there is 4301 stuff which must be the same
[06:02:59] <ldondeti> so we shd be able to do this whether or not the client is involved
[06:03:21] <ldondeti> this point was getting lost
[06:03:33] <ldondeti> Sam summarized:
[06:03:47] <ldondeti> people are not interested in moving all state from one vendor to another
[06:03:51] <ldondeti> we rule that out of scope
[06:04:02] <ldondeti> Ekr disagrees
[06:04:13] <ldondeti> he likes the conclusion, but wants to see clarify on the hums
[06:05:08] <ekr> gah, the whole point is of preserving sa state is not to have clnt involvement.
[06:07:02] <ldondeti> so sync'ing up state in anticipation is good, but may not always be cool
[06:07:13] <ldondeti> some people complain that why are we holding state when the client is not there
[06:07:21] <ekr> Sure.
[06:07:34] <ldondeti> MR:
[06:08:16] <ldondeti> given how long it takes clients to detect failover, is there any value was Sam's question
[06:08:35] <ldondeti> MR says that the number is dependent on work in progress
[06:08:36] <ekr> what does this have to do with neutrinos?
[06:08:54] <ekr> premature optimization, Knuth, etc.
[06:09:58] <mrichardson> ekr, in physics you can never establish that the neutrino has no mass, or that the Higgs particle does not exist.
[06:10:25] <ekr> Ah.
[06:10:35] <ldondeti> ok, that went over my head
[06:10:38] <ldondeti> did I miss sth?
[06:10:44] <ekr> I have a higgs boson in my bag.
[06:11:10] <mrichardson> instead, you make statements like: if the neutrino has mass, it is less than 10^{-14} eV, or the Higgs particle is greater than 10^{20}GeV. (numbers made up)
[06:11:10] <ldondeti> what else is in the bag?
[06:11:54] <ldondeti> Q from mic: who initiates?
[06:12:01] <ldondeti> no sol discussion please
[06:12:08] <ldondeti> is the edict from the chairs
[06:12:12] <ldondeti> we are running out of time folks
[06:12:20] <ldondeti> 15 mins to go
[06:12:26] <mrichardson> so, we can establish that the fastest failure detection takes no longer than 4.7243522s, and therefore, is there value?
[06:13:44] <mrichardson> tomorrow, the dna WG may reduce that number from 4.72s to 3.5s tomorrow, and our ROI may go up, or maybe the function is more complicated in some way.
[06:13:52] <ldondeti> right, the way I look at it is, there are people out there who will make sure the mobiles know when to move
[06:14:07] <ldondeti> let them work on that and we can work on this here
[06:14:14] <ldondeti> we build BBs
[06:14:24] <mrichardson> knowing that many of the them are also us.
[06:14:34] <ldondeti> some of them might be useless (there are thousands of examples)
[06:14:42] <ldondeti> sure, MR-DNA-Instantiation :)
[06:14:49] <ldondeti> MR-IFARE-Instantiation
[06:15:02] <ldondeti> I will count that as two people in a good way ;)
[06:17:36] <ldondeti> Vijay's speaking
[06:17:38] <ldondeti> what did he say
[06:17:41] <ldondeti> I missed it
[06:18:04] <ldondeti> coordinate with MIP people
[06:18:04] <mrichardson> (my fault, I distracted him)
[06:18:10] <ldondeti> np
[06:18:24] --- fparent@jabber.org has left
[06:18:33] <ldondeti> well, so if IPsec failover works it works
[06:18:41] <mrichardson> so, the other side about "is this valuable", is the cost of this.
[06:18:42] <ldondeti> why should be it different for mobility or blah
[06:19:11] <mrichardson> there are two costs: IETF costs/overhead of running a WG and producing a solution.
[06:19:33] <mrichardson> the implementation complexity cost.
[06:19:43] <ldondeti> cool!
[06:20:17] <ldondeti> so spec complexity, implementation complexity, computational complexity and communication complexity
[06:20:21] <ldondeti> two I could deal with
[06:20:21] <mrichardson> part (a-IETF cost) is a relative constant, and while not easily quantized, at least, is well understood.
[06:20:24] <ldondeti> four is tough!
[06:20:41] <ldondeti> :)
[06:21:15] <mrichardson> well, we already know the computation and communication complexity of no solution.
[06:21:25] <mrichardson> the question is going to be, what is the savings.
[06:21:30] <ldondeti> right
[06:22:13] <mrichardson> I guess I should shutup and just generate running code....
[06:23:01] <ldondeti> ekr: use ietf-ipsec-failover-request@vpnc.org
[06:23:06] <ldondeti> for subscription
[06:23:19] --- shpark has left
[06:25:34] <ldondeti> discussion: Greg and Kuntal
[06:25:45] <ldondeti> Kuntal talks abt HA discovery: multiple HAs and single
[06:26:32] <ldondeti> asks abt what we might do if the client only gets a single HA
[06:26:39] <ldondeti> 4 mins to go
[06:26:43] <ldondeti> Paul wants to wrap up
[06:26:52] <ldondeti> Greg wants the use cases written up
[06:27:28] --- kuro has left
[06:28:26] <ldondeti> mip6 is a motivating factor and so we need a "we'll use this if it is done" from MIPv6
[06:28:34] <ldondeti> Paul's takeaways:
[06:28:46] <ldondeti> we do not yet enough interaction with mobility folks
[06:29:01] <ldondeti> we have not clearly stated the use cases well enuf to say what is in scope and what is not
[06:29:23] <ldondeti> Paul believes that there is a reasonable chance of doing sth here
[06:29:46] <ldondeti> we will do this on the list in the next 2 months without waiting for Chicago
[06:29:58] <ldondeti> Sam says we need another BoF
[06:30:06] <ldondeti> well, I am disappointed!
[06:30:22] <mrichardson> I concur.... We need another BOF.
[06:30:49] <ldondeti> given the delay, people will use sth like 4285
[06:30:50] <ldondeti> oh well!
[06:30:58] --- hichem.maalaoui has left
[06:30:59] --- ldondeti has left
[06:31:00] --- miaofuyou has left
[06:31:02] --- sk137 has left
[06:31:14] --- nov has left
[06:31:31] --- stjepan.gros has left
[06:35:05] --- ShoichiSakane has left
[06:39:11] --- tim.polk has left
[06:41:14] --- mstenber has left
[06:47:49] --- ekr has left
[06:50:22] --- lebobits has left
[07:36:43] --- bless has left: Disconnected
[08:38:03] --- kuro has joined
[08:49:32] --- joonhyung.lim has left
[09:11:58] --- joonhyung.lim has joined
[09:45:36] --- joonhyung.lim has left
[10:42:12] --- LOGGING STARTED
[10:47:12] --- kuro has joined
[11:31:43] --- joonhyung.lim has joined
[11:40:24] --- kuro has left
[11:56:17] --- kuro has joined
[12:20:30] --- mrichardson has joined
[13:40:21] --- kuro has left
[13:43:27] --- kuro has joined
[14:20:22] --- kuro has left
[14:27:47] --- joonhyung.lim has left
[14:41:43] --- kuro has joined
[14:50:30] --- kuro has left