[12:15:29] jpc joins the room [12:15:39] jpc leaves the room [12:26:53] aalain joins the room [12:27:04] aalain leaves the room [13:28:19] Desire joins the room [13:32:16] satoru.matsushima joins the room [13:32:17] behcet.sarikaya joins the room [13:32:26] Ralph Droms joins the room [13:33:19] HeikkiMahkonen joins the room [13:34:18] sureshk joins the room [13:35:20] Marcelo presenting http://www3.ietf.org/proceedings/75/slides/mext-7.ppt [13:35:43] wmhaddad joins the room [13:36:09] Raj wants to know if issues in WGLC will be addressed [13:36:16] Marcelo says no [13:36:33] Raj clarifies that it is a hypothetical case but possible [13:37:38] Marcelo clarifies that issues in the draft can be fixed but any new improvements are not possible [13:38:35] marcelo talking about flow binding directionality [13:38:58] Behcet to present http://www3.ietf.org/proceedings/75/slides/mext-2.ppt [13:39:26] slide 2 [13:40:03] slide 3 [13:41:46] slide 4 [13:43:32] Raj mentions that the choices of the MN are overruled by the operator [13:44:09] Behcet says the network can initially layout the flows and the MN can change them later [13:44:35] Raj says that the flow layout policies are already provisioned on the host [13:44:52] 22NDSTRE-934E1A joins the room [13:45:29] Raj thinks there is no problem to be solved. [13:45:38] Behcet agrees but..... [13:45:57] he thinks it should be possible to do this [13:45:57] ron_kehno@jabber.scha.de joins the room [13:46:26] MN is in the best position to decide howto send flows [13:47:08] George: HE thinks this information is either static or semi-static and does not change with handovers [13:47:33] and is much more extensive than flow bindings [13:47:44] so we need to use other methods like 802.21 [13:47:53] 22NDSTRE-934E1A leaves the room: Replaced by new connection [13:47:54] or other OOB signaling [13:48:14] 22NDSTRE-934E1A joins the room [13:48:47] George wants a more flushed out proposal before deciding [13:50:18] George thinks no further signaling is required to accomodate this case [13:50:25] Marcelo does not agree [13:50:38] He thinks the HA has more info than the MN in this case [13:51:13] (we were talking about slide 3 Inter-interface flow movement) [13:51:44] Ryuji also agrees with Marcelo [13:52:50] Raj mentions that this can be accomplished by reactive means [13:53:56] Marcelo asks Ryuji if he assumes that the HA has info about access conditions in this case [13:54:16] Raj thinks that this is out of scope [13:54:50] Raj thinks the real question is whether we should use flow bindings as a mechanism for switching interfaces [13:55:05] George says that the MN will eventually figure it out [13:55:13] and you can still do binding revocation [13:55:58] how does the HA figure out that this flow would be better off served from another interface? [13:56:10] Raj thinks that binding revocation is a bit drastic [13:57:29] Can we send a BR message that says you can use the network for 30 minutes then switch [13:57:39] Ryuji agrees with Raj and thinks BRI is costly [13:59:30] Kent is not clear about the need for flow management from the HA [13:59:37] he needs more justification [14:00:52] Marcelo: Only clear consensus from ML is that provisioning policy is out of scope [14:01:09] so slide 4 case is out [14:01:27] only one to consider is slide 3 case (inter-interface flow movement) [14:01:57] george: we have already been through this in the ML [14:02:22] Marcelo: What has not been documented is what the HA is assumed to know [14:02:34] we need to write it down [14:04:00] George presenting http://www.ietf.org/proceedings/75/slides/mext-5.pdf [14:04:26] slide 2 [14:05:57] slide 3 [14:07:55] slide 4 [14:09:29] Julien wants to know why the discard action is required [14:09:52] George: e.g. MN might want to block a source address [14:10:03] Julien: it can do it without flow mobility [14:10:44] George: It is not about flow mobility, it is about flow bindings [14:11:01] Raj: Do flow descriptors allow IPv4 addresses as well [14:11:18] Marcelo: Descriptors will be in the next presentation [14:12:50] Marcelo: Will start WGLC on this document [14:12:58] George presenting http://www3.ietf.org/proceedings/75/slides/mext-4.pdf [14:13:51] slide 2 [14:14:31] slide 3 [14:15:50] wmhaddad leaves the room [14:16:20] slide 5 [14:21:20] Julien thinks if the offset is from the payload part then we do not need to worry about options in between [14:21:33] sklvarjo joins the room [14:21:52] he mentions that only the CN knows the offsets [14:22:09] George says the MN can figure it out after receiving a couple of packets [14:22:25] YOKOLETSR8 joins the room [14:22:29] Julien: This means that you are assuming all packets in a flow are similarly structured [14:22:51] YOKOLETSR8 leaves the room [14:22:51] George: The real question is that do we need to use upper layer info for routing [14:23:23] Ryuji: Disagrees with the need for this [14:23:34] What kind of applications need this? [14:23:39] sklvarjo leaves the room [14:23:48] George: uses the example of RTP and Julien agrees [14:25:31] George is fine with removing this from the draft and adding it back if needed [14:26:10] Marcelo: Will call for wg adoption WITHOUT pointers [14:26:17] and then we can discuss the pointer issue later [14:27:43] Ryuji to present http://www3.ietf.org/proceedings/75/slides/mext-8.pdf [14:28:01] slide 2 [14:29:04] slide 3 [14:29:31] Hidetoshi Yokota joins the room [14:30:55] Hidetoshi Yokota leaves the room [14:33:16] Suresh, Raj, Jean Michel and Charlie to review the draft [14:33:27] Reordering presentation [14:33:27] tachibana@jabber.org joins the room [14:33:47] Behcet to present http://www3.ietf.org/proceedings/75/slides/mext-6.ppt [14:33:50] slide 2 [14:36:17] slide 3 [14:36:58] slide 4 [14:38:04] Marcelo clarifies all the presentation from this one onwards are not charter items [14:38:13] and are to be considered only for a recharter [14:39:02] yoshihiko.saeki@jabber.org joins the room [14:39:32] Raj: identified this problem during DSMIPv6 last call [14:39:46] George: wants this to be reviewed in DHCPas well [14:39:59] I have to present [14:40:02] brb [14:43:20] yoshihiko.saeki@jabber.org leaves the room [14:47:33] Ralph Droms leaves the room: Replaced by new connection [14:47:33] Ralph Droms joins the room [14:56:36] Ralph Droms leaves the room: Replaced by new connection [14:56:36] Ralph Droms joins the room [14:57:00] sklvarjo joins the room [14:57:07] sklvarjo leaves the room [14:59:58] tachibana@jabber.org leaves the room [14:59:58] behcet.sarikaya leaves the room [15:03:08] sureshk leaves the room [15:09:04] sklvarjo joins the room [15:09:23] sklvarjo leaves the room [15:13:25] lifenghua joins the room [15:16:09] Ralph Droms leaves the room: Replaced by new connection [15:16:12] Ralph Droms joins the room [15:24:31] HeikkiMahkonen leaves the room [15:30:16] Gerardo joins the room [15:30:16] Gerardo leaves the room [15:30:16] Gerardo joins the room [15:33:07] Gerardo leaves the room [15:35:21] Ralph Droms leaves the room: Replaced by new connection [15:39:31] SELNOTEBOOK joins the room [15:41:00] SELNOTEBOOK leaves the room [15:43:19] satoru.matsushima leaves the room [15:58:13] lifenghua leaves the room [16:01:40] ron_kehno@jabber.scha.de leaves the room [16:03:12] 22NDSTRE-934E1A leaves the room [16:04:04] Desire leaves the room [16:11:51] Ralph Droms joins the room [16:27:43] Ralph Droms leaves the room: Replaced by new connection [16:27:44] Ralph Droms joins the room [16:29:20] Ralph Droms leaves the room [16:29:21] Ralph Droms joins the room [16:30:30] Ralph Droms leaves the room: Replaced by new connection [16:30:30] Ralph Droms joins the room [16:30:55] Ralph Droms leaves the room