Scribe: Basavaraj Patil (@nokia.com) Jabber: None Agenda: Kent: Dont see the GRE key I-D on the agenda. Pete: It is not on the charter, but is a WG item. Will get to it. Document status (Henrik) ------------------------ - As shown on the posted agenda 1. MCBC extension to MIP4 Comments supporting the I-D being taken up by the WG from Kent Leung and Alper Yegin - Alper will also send a pointer about the WiMAX liaison to the chairs. 2. MIP4 extension for Ethernet support Presenter: Qiu Samita: Believes the idea is interesting. What is the role of MIP4 in this case? Qiu: Samita: How are the tags in Use case 4 distributed? Qiu: FA will support the L2 functionality and will insert/remove the vlan IDs. The VLAN tags are processed only in the FA Kent: Is there any reason to restrict this to MAC packets or MAC address? Qiu: The MR can support wireless ethernet bridge service. Kent: It is confined to Ethernet only and not to any L2 generically? Kent: Concerns about the fact that the HA is an IP router and now you are changing it to a Layer 2 entity. Capacity of the HA is also a concern. Raj: What is the reason for using MIP to transport Ethernet vs MPLS or L2TP? Qiu: Security is one reason. User experience is another. Raj: Providing mobility to Ethernet seems to be the only value here. Raj and Kent disagreed about security being an advantage of using MIP. Kent: You also get to reuse the MIP capability of mobility and tunnel setup Pete: How many people are interested in working or exploring this problem space? For: 3 Against: 3 Pete: Will continue the discussion on the ML and will not include it in the current charter for now. MIP4 DHCP configuration: ------------------------ Presenter: Kent Leung Ralph: Implementation complexity of proxy vs direct. Direct mode may be easier. Raj: The issue with whether you can fit all the DHCP parameters in the Reg-RSP makes the direct mode a better option Also from an implementation perspective there has to be co-ordination between the MIP client and the DHCP client because the DHCP client has to wait until the MIP client has received an Ack with the DHCP server address. Kent: Agrees. The MIP adapter will need to run first. It is an implementation exercise about the co-ordination between the DHCP client and the MIP4 client. In PMIP4 mode, this is not an issue since there is no MIP client on the host. But in the case of client MIP it is an issue. Pete: Question to the room about whether to go with the approach presented by Kent vs the genext ID. At least 6~8 hands in support. None for the genext Chairs request Kent to write up an ID for this. Raj: What is the status of 3344bis Henrik: Has been busy with quite a few things including getting married :) Will get to it.. Hannu Hietalahti: Mentioned the fact that 3344bis is a reference in the 3GPP specs. Henrik: Will work on getting it done ASAP. Charter discussion ================== - RFC2794 will be advanced on standards track. Kent: There may be some ambiguities. Implementations have their own interpretations. Kent had an old I-D on some issues. - MIBs need to be done. MIP4 base protocol and UDP encap. - Reexamine the proposal on doing specs for Radius extensions to MIP4 - Host configuration work will be worked on by George T and Kent Leung. - Multiple interface/multiple tunnels and flow binding work - Will collaborate with the MEXT WG to align the descriptors and messaging. Sri: Has written an I-D. What to do with it? Pete: Go ahead and publish it and we will discuss it. - HA assisted RO. Consensus at last IETF to adopt it. Raj: RO does not seem to make a lot of sense. Henrik: It is a very special case. And hence one should look at this special case. Sri: Author had also recommended doing this on an experimental basis. - GRE tunnelling with MIP4 Kent: Not sure who would actually work on it Pete: Will find a stuckee if possible. Raj: MCBC extension for RFC3024. What is the state of this work? Pete: Believes we have consensus on this. Is probably just missing here as a result of oversight. Will fix it.