[03:54:32] --- behcet.sarikaya has joined
[04:01:44] --- ldondeti has joined
[04:02:54] --- teemuk has joined
[04:03:19] --- apetrescu has joined
[04:04:14] --- ks has joined
[04:04:52] <ldondeti> folks I couldn't make it to the meeting
[04:04:56] <ldondeti> TLS is in parallel
[04:05:06] <ldondeti> could someone scribe the proceedings
[04:05:13] <ldondeti> I don't want to miss the fireworks :)
[04:05:27] <apetrescu> I can try...
[04:05:31] <apetrescu> Phil Roberts
[04:05:32] <ldondeti> thx Alex
[04:05:37] <ldondeti> oh Phil
[04:05:38] <ldondeti> :)
[04:05:40] <apetrescu> PR: we don't have liaison wimax
[04:05:51] <apetrescu> sorry, I'm Alex, Phil is talking
[04:06:09] <apetrescu> slide: IPR Status
[04:06:26] <apetrescu> Vidya NArayanan VN
[04:06:38] <apetrescu> slide: disclosures from Cisco.. and _new_ Qualcomm.
[04:06:58] <apetrescu> VN: not clear is or not is from qualcomm, technical.
[04:07:30] <ldondeti> Ack Alex; thanks for scribing
[04:07:35] <apetrescu> VN: if people want to diverse WG decisions based on IPR statements... we have to see.
[04:07:46] <apetrescu> slide: Recap of Agreed Goals
[04:09:00] <apetrescu> next Ajoy Singh is presenting
[04:09:08] <apetrescu> slide: PMIPv6 Overview
[04:09:12] <apetrescu> Question
[04:09:15] <apetrescu> Jean-Michel Combes
[04:09:27] <apetrescu> JMC: when you said 'minimal' changes at HA - what do you mean?
[04:09:32] <apetrescu> VN: difficult to quantify minimal
[04:09:52] <apetrescu> VN: goal is not to write new HA, but not a goal to be constrained by mobility ha either
[04:10:03] <apetrescu> VN: hard to quantify, we'll have to evaluate as we move along
[04:10:08] <apetrescu> Wassim HAddadh
[04:10:19] <apetrescu> WH: should we say a few words about MAG being compromised?
[04:10:28] <apetrescu> VN: discussed as part of mip6-pmip6 discussion
[04:10:54] <apetrescu> slide: Outline
[04:11:04] <apetrescu> Ajoy Singh
[04:11:22] <apetrescu> AS: this is already more than 1 year old
[04:11:32] <apetrescu> AS: delta
[04:12:04] <apetrescu> AS: two architectural concepts IETF: client anchoring and relocation
[04:12:26] <apetrescu> AS: pmip client need not be collocated with MAG
[04:15:42] <apetrescu> I'm gonna make comments but so many other people, on mike, so few notes
[04:15:56] <ldondeti> ok
[04:20:29] <apetrescu> Vidya NArayanan cuts line at end of presentation
[04:20:38] <apetrescu> VN: questions after the two presentations.
[04:21:13] <apetrescu> Sri Gundavelli going to present
[04:21:22] <apetrescu> slide: Proxy Mobile IPv6
[04:22:21] <apetrescu> slide: Main Protocol Features supported in the Draft
[04:28:29] --- miaofuyou has joined
[04:28:43] --- miaofuyou has left
[04:33:20] --- behcet.sarikaya has left
[04:33:35] --- shubranshu has joined
[04:34:16] --- shubranshu has left
[04:34:35] <apetrescu> fireworks Ajoy-Sri about NAT traversal and the need of PMIP relocated client
[04:34:50] <ldondeti> cool!
[04:34:58] <ldondeti> so where is Sri at?
[04:35:07] <apetrescu> Sri ended his slides
[04:35:10] <ldondeti> ok
[04:36:46] --- behcet.sarikaya has joined
[04:38:32] <ldondeti> what is the sense of the room on anchoring as Ajoy describes?
[04:38:43] <ldondeti> were there Qs on that? any conclusion?
[04:39:20] --- saphira@jabber.no has joined
[04:42:47] --- xiaohunhun has joined
[04:42:49] --- xiaohunhun has left
[04:44:46] <apetrescu> Ahmad Muhanna
[04:44:58] <apetrescu> AM: top bullet take it out (authorization something)
[04:45:13] <apetrescu> AH: PMIP Client relocation according to your...
[04:45:25] <apetrescu> AH: you agree?
[04:45:38] <apetrescu> Ajoy Singh is AS, Sri gundavelli is SG
[04:45:59] <apetrescu> AS: agrees but SA back to LMA, but there are scenarios that LMA and ...
[04:46:02] <apetrescu> AM: that's not true
[04:46:34] <apetrescu> AM: talked about before, but in your presentation you stress pmip client in a separate box... advantage - point of failure?
[04:46:46] <apetrescu> AS: pmip client logical concept or on MAG.
[04:46:55] <apetrescu> AS: wherever implemented don't change the anchor
[04:47:14] <apetrescu> AM: oversimplyging issue
[04:47:42] <apetrescu> AM: mobiles moving from MAG to MAG
[04:47:56] <apetrescu> AM: my point is it could generate point of failure
[04:48:12] <apetrescu> AM: sessions down from one node to another
[04:48:21] <apetrescu> AS: relocation can co-exist with...
[04:48:35] <apetrescu> Phil Roberts asks whether has other issue?
[04:48:51] <apetrescu> PR: seq number and timestamp (q to Sri)
[04:48:54] <apetrescu> SG: yes
[04:49:04] <apetrescu> VN: cutting line
[04:49:10] <apetrescu> Gerardo Giaretta
[04:49:18] <apetrescu> GG: one q per draft to be fair
[04:49:45] <apetrescu> GG: q to si draft, PMIP Client, Trigger message, how does the MAG know the PMIP client address to send the message to right PMIP client
[04:49:54] <apetrescu> AS: PMIP client cna be located to first mag
[04:50:10] <apetrescu> AS: this is like in 3gpp context
[04:50:17] <apetrescu> AS: same as MME pmipl client
[04:50:34] <apetrescu> GG: not talk 3gpp, that is a system, here we don't have a system
[04:50:45] <apetrescu> GG: pre-configuration, all nodes have same pmip client?
[04:51:17] <apetrescu> AS: dns-based discovery, yes, that too, .
[04:51:40] <apetrescu> GG: I can think of several ways of doing it. Your draft doesnt define.
[04:51:45] <apetrescu> GG: to Sri draft
[04:51:57] <apetrescu> GG: DHCP messages are specified by draft.
[04:52:03] <apetrescu> GG: MN-AR interface draft.
[04:52:26] <apetrescu> GG: favors dropping anything about what the MN does.
[04:52:44] <apetrescu> PR: right. Problem is that if there's somehow MAG behaviour must go in
[04:52:58] <apetrescu> GG: DHCP may be one example, but maybe other ways to do that.
[04:53:02] <apetrescu> PR: agrees
[04:53:06] <apetrescu> GG: authorization
[04:53:13] <apetrescu> GG: what type of authori?
[04:53:28] <apetrescu> GG: are all all the nodes in mobile network to use mip? or that the network handles that?
[04:53:45] <apetrescu> GG: per-node SA is fine if case...
[04:54:09] <apetrescu> GG: but if we want to auth explicitely (some nodes auth'ed to pmip others not) then some nodes auth'ed to use pmip service.
[04:54:18] <apetrescu> SG: it's a policy-based thing.
[04:54:25] <apetrescu> SG: prefix is logically following.
[04:54:37] <apetrescu> Phil cuts Kuntal but he insists
[04:54:41] <apetrescu> Kuntal chowdhury
[04:54:52] <apetrescu> KC: part of MN-ID in PBU, that's part of mobile.
[04:54:57] <apetrescu> KC: looks at that ID.
[04:55:56] <apetrescu>
[04:56:01] --- sureshk has joined
[04:56:02] <apetrescu> Gerardo Giaretta presents
[04:56:10] <apetrescu> slide: Motivation and Objective
[04:56:13] <sureshk> the line at the mic was cut off
[04:56:23] <sureshk> but another associated question is
[04:56:24] <apetrescu> it was cut off in a very strange way
[04:56:37] <ldondeti> what happened?
[04:56:38] <apetrescu> Effectivel Kuntal cut Eric Ndjedjou
[04:56:40] <sureshk> how does the mobile day it wants to do its own signalling
[04:56:48] <sureshk> s/day/say/
[04:57:07] <sureshk> i mean, the mobile needs to authorize the MAG to do signaling on its behalf
[04:57:12] <sureshk> doesn't it?
[04:57:14] <apetrescu> that's right...
[04:57:32] <sureshk> i will take it up on the ML
[04:57:35] <ldondeti> so NETLMM requires mobile involvement?
[04:57:44] <sureshk> nope lakshmi
[04:57:45] <ldondeti> or should require mobile involvement?
[04:57:47] <apetrescu> right... god questions... good I mean
[04:57:48] <ldondeti> ok, expl
[04:57:58] <ldondeti> please :)
[04:58:03] <sureshk> when a MN enters a PMIP domain
[04:58:14] <sureshk> it needs to have a choice whether it needs PMIP support
[04:58:20] <sureshk> or it can do its own signaling
[04:58:21] <ldondeti> hmmm
[04:58:35] <sureshk> not all MNs are stupid you know
[04:58:40] <ldondeti> nope
[04:58:47] <ldondeti> ideally they should do their own signaling
[04:58:54] <ldondeti> i.e., we don't need netlmm ;)
[04:59:04] <ldondeti> thank God I am not in the room as I say it
[04:59:10] --- washad has joined
[04:59:43] <washad> Netlmm is not about only stupid client
[04:59:56] <washad> it is mainly about doing the signaling on behalf of the MN
[05:00:11] <ldondeti> but if the network is doing signaling, the mobile involvement sounds ...., well, let's say interesting
[05:00:21] <sureshk> i believe in choice
[05:00:23] <washad> so the MN can do part of MIPv6 and let the PMIP do the signaling
[05:00:30] <sureshk> the mobile needs to choose to do this
[05:00:32] <ldondeti> what might be the signaling protocol between the MN and MAG
[05:00:39] <sureshk> ICMPv6
[05:00:43] <sureshk> for example
[05:01:06] <ldondeti> hmmm
[05:01:11] <washad> or something else
[05:02:40] <apetrescu> Raj Patil asks
[05:03:00] <apetrescu> RP: you say you could essentially use a subscriber profile?
[05:03:22] <apetrescu> RP: the MN should have the ability to... in that case MN would not know whether it's attached to home or emulated prefix.
[05:03:38] <apetrescu> RP: regular prefix
[05:03:52] <apetrescu> GG: if you have a MN profile, if the profile says this is the MIP6 node
[05:03:59] <apetrescu> RP: can't say that in the profile
[05:04:29] <apetrescu> GG: after profile note in some system, devie proerties exchanged.
[05:04:35] <washad> I think Raj has a very good point
[05:04:42] <washad> that's what I also would like to have
[05:04:50] <apetrescu> Phil Roberts cuts line cleanly (this time :-)
[05:04:56] <washad> and what I wrote few minutes ago
[05:05:22] <apetrescu> slide: Movement between PMIPv6 and MIPv6
[05:05:30] <washad> Having the MN configures a CoA and letting the PMIP do the signaling is very useful
[05:06:04] <apetrescu> it is
[05:06:39] <apetrescu> slide: Issues
[05:07:18] <apetrescu> GG: disclaims that these issues can be solved by either one or the other draft (I suppose si and sg).
[05:07:50] <apetrescu> Ajoy Singh going to ask
[05:08:16] <apetrescu> VN holds discussion to end.
[05:08:28] <apetrescu> Hesham Soliman is also waiting at the other mike.
[05:09:52] <apetrescu> slide: Issues (cont'd)
[05:10:14] <washad> where are the slides btw?
[05:11:35] <apetrescu> still on Issues, GG presents issues with pbu and bu and security.
[05:12:16] <apetrescu> line are Hesham Soliman, Kent Leung and Jean-Michel Combes
[05:12:38] <apetrescu> slide: sequence numbers and multihoming
[05:13:11] <apetrescu> slide: Conclusions
[05:13:44] <apetrescu> slides areat https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=68 and then search netlmm
[05:14:37] <apetrescu> HS: answers, good point 60% scenarios need to be elaborated, some are not an issue
[05:14:40] <apetrescu> HS: a draft?
[05:14:50] <apetrescu> HS: good way to write a draft.
[05:14:57] <apetrescu> HS: security slide
[05:15:30] <apetrescu> HS: compromised MAG? compromised router is already a big issue...
[05:15:34] <apetrescu> HS: is this different?
[05:15:41] <apetrescu> GG: trust model of routing protocols.
[05:15:49] <apetrescu> GG: 4th bullet is different than the others.
[05:16:00] <apetrescu> GG: pmipv6 and mipv6 interactions
[05:16:15] <apetrescu> HS: dont see that
[05:16:21] <apetrescu> VN: replies
[05:16:27] <apetrescu> VN chair hat off apparently
[05:16:38] <apetrescu> VN: routing protocols are designed for byzanthine problems.
[05:16:44] <apetrescu> VN: one path that's reachable
[05:16:57] <apetrescu> VN: point in mip is that MN has a hoa-coa and SA
[05:17:14] <apetrescu> VN: in proxymip we get into a situation if the MAG is compromised then...
[05:17:24] <apetrescu> HS: same PMIP address?
[05:17:34] <apetrescu> VN: restrict this to have...
[05:17:43] <apetrescu> VN: MIP6 home domain equals one of the PMIP domains
[05:18:07] <apetrescu> VN: two cases where pmip-assigned address equals the mip assigned a COA- that's not an issue HS agrees.
[05:18:16] <apetrescu> VN: exposes a different scenario
[05:18:20] <apetrescu> HS: why do that?
[05:18:23] <apetrescu> VN: good question
[05:18:32] <apetrescu> HS: digging your own grave.
[05:18:46] <apetrescu> GG: not creating, just IETF that we want
[05:19:05] <apetrescu> VN: presenation on open issues. lead the discussion. create awareness.
[05:19:14] <apetrescu> Kent Leung
[05:19:28] <apetrescu> KL: looking at this, initially I thought this is generic PMIP threat model.
[05:19:42] <apetrescu> KL: threat model is on PMIP, just one comment.
[05:20:04] <apetrescu> AS: comments on SAs used of different SAs. It's needed only when you relocated a PMIP client.
[05:20:22] <apetrescu> AS: compromise MAG? If you implement that in PMIP client that is deeper in the network.
[05:20:28] <apetrescu> GG: you're moving the problem.
[05:20:36] <apetrescu> GG: because in your proposal you have a trigger.
[05:20:42] <apetrescu> GG: compromise the trigger.
[05:20:58] <apetrescu> AS: that trigger can be layer-2 NAS message
[05:21:10] <apetrescu> AS: 3gpp/wimax is not required
[05:21:16] <apetrescu> VN: says no SDO comment
[05:21:27] <apetrescu> VN: compromised MAG issue is captured in the document.
[05:21:45] --- benkoh has joined
[05:21:49] <apetrescu> Hakima INT France
[05:22:02] <apetrescu> H: protocol independent of any global mobility protocol?
[05:22:28] <apetrescu> H: performance analysis for PMIP? PMIP is performing any better than HMIP?
[05:22:35] <apetrescu> PR: answers...
[05:23:03] <apetrescu> VN: also in San Diego we were in urge of PMIP, important to impact.
[05:23:29] <apetrescu> GG: PMIP-HMIP completely different performance levels? (GG doesn't think so).
[05:23:47] <apetrescu> VN: not in scope of discussion (performance analysis)
[05:23:57] <apetrescu> H: netlmm protocol totally based on MIP?
[05:24:14] <apetrescu> H: performance are not good for localized network mobility.
[05:24:28] <apetrescu> ETRI... name?
[05:24:41] <apetrescu> name: MIP6 extensios and NEMO and MONAMI6 should be considered
[05:24:54] <apetrescu> GG: only considered rfc3775.
[05:25:57] <apetrescu> KL: only happens for a node PMIP case, this is for MN, model still requires BCE... PMIP-CMIP
[05:29:42] --- sureshk has left
[05:34:34] --- sureshk has joined
[05:35:40] <apetrescu> Julien Laganier presenting
[05:35:45] <apetrescu> slide: per-MN subnet (2)
[05:36:30] <apetrescu> slide: Domain-wide address uniqueness
[05:37:15] --- washad has left
[05:37:26] <apetrescu> slide: Enforce domain-wide address uniqueness
[05:38:26] <apetrescu> slide: Shared link support
[05:41:13] <apetrescu> VD: not sure about dnav6
[05:41:20] <apetrescu> Jari Arkko
[05:41:33] <apetrescu> JA: shared links in product management if you're late, do you add new features?
[05:41:56] <apetrescu> JA: do that later ok, not add complicated stuff depending on proxy nd
[05:42:37] <apetrescu> JA: not sure whether you want of existence of dnav6 or not.
[05:42:44] <apetrescu> JA: regular IPv6 hosts.
[05:42:53] <apetrescu> JA: deal with the main
[05:43:05] <apetrescu> VN: DNAv6 problem only on shared last hop
[05:43:18] <apetrescu> Jinhyeock Choi
[05:43:29] <apetrescu> JC: peer-to-peer link then RA unicast is not needed.
[05:43:56] <apetrescu> JC: to be able to send RA unicast router should not address all or each nonce address access router otherwise can't send RA in unicast
[05:44:08] <apetrescu> SG: you can l2 ptp unicast
[05:44:18] <apetrescu> JC: unsolicited one
[05:44:36] <apetrescu> SG: if you support shared link that's a seggregation
[05:44:43] <apetrescu> JC: attempt to be solved
[05:44:47] <apetrescu> JC: during 16ng
[05:44:55] <apetrescu> JC: people can't be sure router can be that
[05:45:10] <apetrescu> JC: per-mn-prefix model. Prefix is assigned not to a mobile but to a link
[05:45:29] <apetrescu> JC: peer-to-peer link first defined and only _then_ assined a prefix (in 3gpp)
[05:45:44] <apetrescu> JC: link-shared, but how can you assigned to each link to assign a prefix?
[05:46:02] <apetrescu> GG: general comment on dnav6 and this draft: if not draft this is target informational
[05:46:15] <apetrescu> GG: we decided to include this draft to put some .... on how IETF tech
[05:46:38] <apetrescu> GG: there should be no assumption on base spec about how the MN-AR interface
[05:46:54] <apetrescu> GG: base spec can not assume DNAv6, must be agnostic
[05:47:16] <apetrescu> JL: do we want to support shared links ?
[05:47:23] --- jmg-ietf has joined
[05:47:40] <apetrescu> JMC: more the work goes on more I see assumptions on the future protocol... will become proiprietary protocol.
[05:47:51] <apetrescu> JMC: for me it's clear it must be supported.
[05:47:55] <apetrescu> VN: in base document?
[05:48:04] <apetrescu> VN: or leave it for further study
[05:51:11] --- miaofuyou has joined
[05:56:59] --- teemuk has left
[06:01:51] <jmg-ietf> who is the speaker please ?
[06:02:06] <apetrescu> Raj Patil presents about IPv4
[06:02:14] <apetrescu> slide: IPv4 at LMA
[06:02:37] <ldondeti> I am in the netlmm room now
[06:02:39] <ldondeti> TLS finished early
[06:02:47] --- sureshk has left
[06:02:47] <ldondeti> thx Alex; it was very helpful!
[06:02:58] <apetrescu> sure
[06:05:00] --- sureshk has joined
[06:06:55] <apetrescu> slide: Questions
[06:09:08] <apetrescu> slide: Use of DS-MIP6
[06:09:46] <apetrescu> HS: needs IPv4 support
[06:09:51] <apetrescu> HS: what if NAT
[06:10:00] <apetrescu> HS: how relevant is for NAT between MAG and LMA
[06:10:41] <apetrescu> RP: not looked at that issue NAT between MAG and LMA
[06:11:14] <apetrescu> RP: no reason for expecting that there are nasty things.
[06:11:50] <apetrescu> VN: one of the assumptions is per-mn prefix model. For v4 people whether that discussion makes sense.
[06:15:00] --- jclee has joined
[06:23:00] --- apetrescu has left
[06:26:38] --- ldondeti has left: Disconnected.
[06:26:54] --- ks has left
[06:27:33] --- saphira@jabber.no has left
[06:28:29] --- sureshk has left
[06:28:46] --- behcet.sarikaya has left
[06:28:59] --- benkoh has left: Computer went to sleep
[06:35:34] --- jmg-ietf has left
[06:42:09] --- miaofuyou has left
[06:53:05] --- jclee has left: Disconnected
[07:55:38] --- jclee has joined
[07:56:12] --- jclee has left
[12:44:58] --- apetrescu has joined
[12:45:02] --- apetrescu has left