[15:01:29] vidya joins the room [15:02:11] dvijay joins the room [15:03:10] Greg Schumacher joins the room [15:03:17] satoru.matsushima joins the room [15:03:24] satoru.matsushima leaves the room [15:03:57] satoru joins the room [15:06:34] Has the meeting started? I don't hear anything on the audio stream [15:08:17] behcet.sarikaya joins the room [15:09:33] satoru leaves the room [15:11:05] jariarkko joins the room [15:11:52] Which room is the NETLMM meeting in? [15:12:04] in Room G [15:12:22] There is nothing on the audio stream [15:12:22] Vidya on WG documents [15:12:35] Don't hear anything on the audio [15:12:47] I told chairs [15:13:08] satoru joins the room [15:13:27] Jonne is checking it now [15:14:10] charter related but not yet WG documents 3 of them [15:14:39] WG document status slide [15:14:49] http://videolab.uoregon.edu/events/ietf/ says NETLMM is on channel 6 [15:15:07] But there is nothing on channel 6 [15:15:07] No audio on that channel. [15:15:39] lion joins the room [15:16:17] Sri on IPv4 support [15:16:27] Status slide [15:17:08] sureshk joins the room [15:17:11] vidya leaves the room: Replaced by new connection [15:17:36] suresh feel free to help [15:17:40] Sri presenting http://www3.ietf.org/proceedings/08nov/slides/netlmm-0.ppt [15:17:45] vidya joins the room [15:18:19] Slide 2 [15:18:37] @behcet: are you the jabber scribe? [15:19:06] yeah you are I [15:19:25] can anyone on jabber hear the audio? [15:19:28] No [15:19:39] Channel 6 is empty [15:19:53] hmmm.. somebody said it is noisy and unclear [15:20:05] The last time this happened, somebody had shut off the power strip for the audio equipment in the room. [15:20:06] can they share what channel they are listening into? [15:20:22] satoru leaves the room [15:20:24] on the IPv4 support document, there were a lot of issues raised on Channel 6 is what the website says [15:20:42] on the IPv4 support document, there were a lot of issues raised on DHCPv4 scenarios [15:20:55] None of the them are listed on the issues page that Sri is presenting [15:21:05] I will bring this up [15:21:10] dhcp server location? anything else? [15:21:19] One was on the DHCP scenarios [15:21:28] Whether we should support two models or just one [15:21:39] Now I can hear the audio stream [15:21:43] ok.. good [15:21:51] I can't hear Sri [15:21:57] But I heard Suresh loud and clear [15:21:59] vijay: this will be covered in the section 3.4.1 bullet [15:22:46] 3.4.1 is about reducing the number of options for configuring an IP address for a DHCP server [15:22:59] Not about whether we should support two models for DHCP [15:23:08] 1. DHCP relay on the MAG, server on the LMA [15:23:13] 2. DHCP server on the MAG [15:23:21] yes: but sri said he will cover it under that topic [15:23:55] vijay can you hear joel [15:24:05] I can hear Jonne [15:24:09] But I can't hear Sri [15:24:09] can you hear Sri now? [15:24:12] Nope [15:24:18] not at all? [15:24:19] Only 1 mic is working [15:24:20] or low [15:24:23] sigh [15:24:25] not at all [15:24:30] Anyway, please go ahead [15:24:53] sri is moving to the working mike [15:25:10] Thanks [15:25:38] Now I can hear Sri [15:25:41] jlaganie joins the room [15:25:52] Someone can speak for me? [15:25:57] jlaganie is now known as julien [15:26:14] Suresh, I guess [15:26:20] yep jule vas y [15:26:21] yes, type your questions/comments [15:26:28] can u hear Sri now? [15:26:29] Can someone tell Sri that having two modes of DHCP operation causes problem where different type of network are hooked together [15:26:44] e.g. non-3GPP access using one mode, and 3GPP access using the other [15:26:51] that causes interop problems [15:26:57] Yes I can [15:26:59] thanks [15:28:19] At minimum, recommend one setup [15:28:35] if someone wants to do something else they can do [15:28:48] Configuration parameters do not solve the problem [15:28:56] when there are multiple options [15:29:11] Vijay, can you explain a bit further? [15:29:23] configuration could solve the problem if it is done on LMA and imposed upon MAG [15:29:41] jouni joins the room [15:30:12] I agree with Jonne [15:30:23] At minimum the potential interop problem shall be called out [15:31:07] We do have an issue today if a Wimax ASN GW that implements a proxy connects to a PDN GW (from 3GPP) using the relay model [15:31:12] This causes an issue [15:31:19] To Sri: Why don't you let one LMA impose the DHCP operation mode to its MAGs [15:31:35] It is not possible to co-ordinate configuration across differe operator networks [15:31:37] Vijay, don't you think that would solve the issue? [15:31:59] I mean, the configuration is done entirely on LMA, LMA instrcuts MAGs which mode they should operate in. [15:32:04] How about a flag in the PBU/PBACK exchange that tells both the MAG and the LMA which option should be used [15:32:15] How does the LMA instruct the MAG? Through the PBACK? [15:32:19] LMA is configured with {MAG in relay mode, MAG in server mode} [15:32:43] No, thats difficult if the LMA and the MAG are in different operator networks [15:32:51] Vijay, I think the LMA should decide, because we want the settings to be consistent across different MAGs to which the MN attahces [15:33:14] Then, I think we should extend the PBACK, for the LMA to instruct the MAG to use a particular mode [15:33:20] the different operator story has to be solved with roaming agreements specifying that visited has to follow configuration of home netwrok [15:33:24] Right! [15:33:30] ldondeti joins the room [15:33:31] Vidya, is this clear? [15:34:12] zarhan joins the room [15:34:19] Vijay and I agree on "the LMA instructs the MAG which DHCP mode to use via PBAck" [15:34:36] Peny joins the room [15:34:51] why not using the aaa ? [15:34:52] satoru joins the room [15:34:57] nsko joins the room [15:35:05] because it is the only way to have consistent settings across MAGs [15:35:14] The LMA and the MAG could be in different operator networks [15:35:22] Configuration is not possible in this case [15:35:28] this is the way to realize consistency of configuration across MAG of a domain [15:35:37] guys you have an excellent representative here at the meeting [15:35:38] :) [15:36:37] AAA-based solution is fine too [15:37:05] tell sri that if we're too much architecture focused, then let's remove the whole DHCP story [15:37:57] Sri is telling that interop is handled via configuration. I'm telling that we should make at least one mode mandatory, and include negotiation of the mode in the protocol [15:38:05] this is the IETF... [15:38:20] (BTW Thanks Suresh!) [15:38:34] no probs [15:38:48] (FWIW, I and Vijay already had exactly same discussion with Sri on Monday :) ) [15:39:50] Suresh: can you make this point: Sri is telling that interop is handled via configuration. I'm telling that we should make at least one mode mandatory, and include negotiation of the mode in the protocol. This is the IETF we need to provide real interop at protocol level, not config=uration [15:40:19] I'm in another room, but I strongly agree that interop is not merely a config issue. one mode generally needs to be mandatory... [15:40:58] julien and jari: relayed [15:41:24] THANK YOU [15:41:49] Behcet, please relay the responses back on jabber - some people on jabber are not listening to the audio stream [15:41:52] jonne also agrees with jari and julien (and vijay) [15:42:01] Sure [15:42:30] satoru leaves the room: Replaced by new connection [15:42:46] jonne think we should define PMIP architecture independent of SDOs [15:43:05] we're not building an architetcure, we're building a protocol that woks correctly with DHCP [15:43:20] we're not shutting down anything, we make sure configuration is propagated consistently [15:43:20] Alper wants to make sure that the decided arch does not preclude SDOs from doing different things [15:43:28] make one mode of operation mandatory, other modes can be option [15:43:47] SDO can define whatever crazy mode of operation they want. e.g. AAA based :-p [15:44:18] Hesham agrees with Jonne [15:44:34] alper thinks that either option has no impact on protocol [15:45:04] sri and hesham think there needs to be negotiation and that will have impact on the protocol [15:45:12] saying iyt's out of band isn't a solution [15:45:27] alper thinks that the SDOs will define their own non-PMIP mechanisms to negotiate [15:45:34] Gerardo joins the room [15:45:34] Gerardo leaves the room [15:45:34] Gerardo joins the room [15:45:37] alper - nobody prevents that [15:46:05] right jule and I think alper agreed [15:46:50] sri to update the doc next week [15:47:38] tell sri it would be good if he posts text on ML and we agree on before ypdating the draft [15:47:46] define config flag [15:47:54] remove any normative text [15:48:04] I don't think we agreed on that [15:49:11] the stream is going bad [15:49:17] I don't think we agreed on using the config flag [15:49:28] sri to send text to ML [15:49:34] or it's MSP's WiFi... [15:49:37] on jabber, who thinks we should limit to one option? [15:49:42] There has to be a protocol level instruction from the LMA to the MAG to act in one more [15:49:43] we are having a consensus call on whether to have two options at all [15:49:48] I vote for one option [15:49:54] there is no consensus in the room [15:49:58] ->to ML [15:50:14] Ahmad GRE Keys [15:50:35] Since IETF-72 slide [15:50:42] Ahmad presenting http://www3.ietf.org/proceedings/08nov/slides/netlmm-1.ppt [15:51:10] Slide 2 [15:51:58] Slide 3 [15:53:21] julien leaves the room: Replaced by new connection [15:53:37] Alide 5 [15:53:42] Slide 5 [15:56:11] I agree with Suresh [15:56:15] Suresh against option to support GRE keys [15:56:36] Frank GRE without keys can be used [15:56:41] frank and sri want to keep the option [15:58:38] Suresh : it is possible but no use case in PMIP use of GRE [15:59:14] Ahmad: allowing MAG to negotiate is OK but no use case [15:59:23] This is again one of those, "nice to have, what is the harm in allowing it" stuff that Sri always talks about :) [15:59:25] peny agreed with me [15:59:35] @vijay: :-) [15:59:50] Vidya, Jonne, we should be a little bit more agressive in simplifying the number of options in NETLMM specs. :) [15:59:56] satoru joins the room [16:00:04] jlaganie joins the room [16:00:05] hesham thinks this discussion is painful [16:00:35] I agree with limiting options we'll dig into this before sending the doc to LC [16:00:40] Ahmad: there was consensus to allow GRE without keys [16:01:46] Jonne: update the draft and give one week for comments [16:02:34] Gerardo leaves the room [16:03:07] Suresh take over the scribe I'll be back [16:03:28] I think the doc is ready for last call [16:03:43] no new text needed [16:04:26] Frank to present http://www3.ietf.org/proceedings/08nov/slides/netlmm-2.pdf [16:05:36] Slide 2 [16:06:14] Slide 3 [16:07:20] zarhan leaves the room [16:07:31] zarhan joins the room [16:08:32] Slide 4 [16:09:34] Slide 5 [16:10:43] alper: thinks it is better to have separate attribs for mip and pmip [16:10:53] I ahd same comment as Alper to Jouni once [16:11:05] I don't think it makes sens doing semantic overloading [16:11:32] there's two camps there.. [16:11:59] I'm going to scribe temporarily here [16:12:02] but i think it is a good proposal to consider [16:12:10] agree completely w/ Alper! [16:12:21] Frank talks about RADIUS attribute shortage.. but, Alper says that is solved [16:13:08] jouni leaves the room [16:13:36] Gerardo joins the room [16:13:44] Slide 6 [16:14:06] Slide 7 [16:15:44] Frank requests adoption as wg item [16:16:06] Vidya wants radext to review the document [16:16:27] polls the room to find out how many people read the draft [16:16:32] 3 hands other than authors [16:16:39] -> ML [16:16:45] please read and comment [16:18:16] Sri on mic [16:18:19] Sri presenting http://www3.ietf.org/proceedings/08nov/slides/netlmm-6.ppt [16:18:59] Slide 3 [16:19:12] About MIB for PMIP6 [16:20:05] done [16:20:10] Raj on mic [16:20:23] LMA discovery for Vijay [16:20:26] Raj to present http://www3.ietf.org/proceedings/08nov/slides/netlmm-3.pdf [16:20:35] for Jouni and Vijay [16:21:35] Slide 2 [16:22:06] jlaganie leaves the room: Replaced by new connection [16:22:33] Raj now AAA-based solutions [16:22:52] Slide 3 [16:23:35] zarhan leaves the room [16:24:23] Slide 4 [16:24:34] jlaganie joins the room [16:24:44] jlaganie is now known as julien [16:24:48] now lower layer solutions [16:26:34] now handover considerations [16:27:41] alper wants to make a comment [16:28:20] Alper wants to know if AAA will be used as a fallback to DNS [16:29:03] Alper says use AAA allover [16:29:04] Raj agrees [16:29:07] Alper wants to stick with all AAA solution [16:29:22] @behcet: take over [16:29:43] Glen : second bullet not accurate [16:30:53] Glen where state is held is very important [16:31:29] Glen: AAA infrastructure could mean anything [16:31:51] Got to catch my plane - thanks again to those who made remote attendance possible. See you in SFO. [16:32:01] Bye Julien [16:32:02] It could be the visited AAA server that stores the information [16:32:28] Glen is sayi ng stateful proxy is not good idea [16:32:48] ok [16:33:17] Frank : LMA discovery using DHCP could also be considered [16:35:33] Mohana fast attach detach, AAA may not be updated [16:36:46] Vidya: let's get people read it and comment [16:36:57] only 3 people read it [16:37:27] Raj again on mic [16:38:05] control and data plane separation [16:38:39] vidya leaves the room [16:40:33] data plane address option slide [16:42:38] use of AltCoA option [16:43:53] Frank on mic [16:44:08] Surprised there are no comments :) [16:44:14] MPLS tunnel support [16:44:34] The room is too cold maybe that's why [16:44:57] Background & solution slide [16:45:43] History slide [16:46:45] WG item? [16:46:55] Yokota san on mic [16:47:03] Behcet, Suresh, thanks a lot [16:47:06] much appreciated [16:47:18] dvijay leaves the room [16:47:24] Yokota san but there are other choices like Vlan [16:48:03] Raj: mpls can be used any need to change the protocol? [16:48:36] Frank: how to distribute mpls labels same problem as gre key distr. [16:48:53] Jonne: mpls not in domain boundaries [16:49:54] Frank: mpls deployment choice [16:51:11] Frank: mpls deployment different than vlan [16:51:41] Vidya: out of scope with current charter [16:52:01] Vidya: wrap up the meeting [16:52:09] gre key last call [16:52:09] Peny leaves the room [16:52:20] ipv4 go to AD comments [16:52:22] julien leaves the room [16:53:08] lma discovery & radius support to become WG docs [16:53:15] read documents and comments [16:53:30] Radius doc to be reviewed by Radext [16:53:59] read documents and comment [16:54:17] netext issue [16:54:34] chairs to discuss with AD on the future of netlmm [16:54:50] maybe all extension docs go to netext [16:55:03] to be discussed with AD [16:55:09] donw [16:55:12] done [16:55:24] Gerardo leaves the room [16:55:34] behcet.sarikaya leaves the room [16:55:43] ldondeti leaves the room [16:57:12] lion leaves the room: Computer went to sleep [17:05:53] sureshk leaves the room [17:09:18] satoru leaves the room [17:21:29] lion joins the room [17:31:42] nsko leaves the room: Computer went to sleep [17:36:37] lion leaves the room: Computer went to sleep [18:11:04] jariarkko leaves the room [18:32:53] Greg Schumacher leaves the room [19:05:24] satoru joins the room [19:05:40] satoru leaves the room [19:57:21] hexamonnexus joins the room [20:38:12] hexamonnexus leaves the room