16ng at 69th IETF meeting WG ---------------------------- Slot: Mon, 2007-07-23 17:40-19:50 Room: (Chicago, The Palmer House Hilton) ============================ Notes taken by: Gabriel Montenegro Bruno Sousa Ji Hoon Lee Minutes assembled by: Ji Hoon Lee ============================ ============================ Administrator (10 min) Chairs - Blue sheets - Jabber scribe - Agenda bashing - WG report ============================ Document: http://www3.ietf.org/proceedings/07jul/slides/16ng-0.ppt ============================ IPv6 over IPv6CS (10 min) Basavaraj Patil - ID: draft-ietf-16ng-ipv6-over-ipv6cs-09 - STATUS: IESG Evaluation - GOAL: Resolution to IESG comments ============================ Document: http://www3.ietf.org/proceedings/07jul/slides/16ng-6.ppt Status - Rev 09 published prior to IETF68. - received comments from 802.16g, security directorate, and others. Current issues - documents at the moment is not clear in terms of mandates; what aspects are MUST, SHOULD, or MAY. - Texts in some sections need to be revised (and probably rewritten). Plan - Rev 10 will be published by 1st week of Aug 07. Conversation: Jari Arkko: issues with the timers in 2461. 1. which document dose the modification, - This one - 2461bis (currently in auth48)? 2. is it ok to change the timers? Basavaraj Patil: discussions done on the mailing list. Jari Arkko: To be resolved this week. ============================ IP over EthernetCS (30 min) Max Riegel - ID: draft-ietf-16ng-ip-over-ethernet-over-802.16-01 - STATUS: Active WG Document - GOAL: Ready for WGLC ============================ Document: http://www3.ietf.org/proceedings/07jul/slides/16ng-7.ppt No severe issues identified, model accepted Separation of QoS differentiation and forwarding decision: - Forwarding done in bridge behind BS - CS classification is QoS related (no forwarding) - Between BS and MS New revision (Rev 02): - Now with normative language - Adoption of RFC4605 for IGMP/MLD proxying + Instead of 4541 snooping bridges (only informational) + why RFC4605? - The .16 fits well into the simple tree topology - No multicast CIDs - Appendix on mcast CIDs and deployment considerations + Incompatible with MIMO, HARQ, advanced directional antennas + Increase interference cuz you don't use HARQ so no feedback + Need higher power to reach the furthest system + Less efficient with mobile terminals + Loss of idle mode for inactive terminals + Increased complexity for the whole system + Mcast CIDs require mgmt of group keys + Probably more efficient to do mcast service over unicast links + These are the reasons why we are not using the multicast to emulate the Ethernet behaviour. Conversation: Gabriel Montenegro: RFC4541 widely supported and deployed... what can you say against? Max Riegel: I've no information of the deployment of RFC4605. RFC4605 - a small document, very focused. - Not a complete solution, does not address bridges, more focus on routers. Dave Thaler: RFC4541 is informational. Seems not to be adopted. Daniel Park: Just a clarification. What is going on in the WiMAX Forum regarding MBS issues? Is there any conclusion? Max Riegel: WiMAX Forum is currently defining multicast and broadcast service based on both MBS-based and non-MBS-based. MBS deployment is not mandate. You can deploy MBS, but is not very efficient. Daniel Park: There are a few comments on the mailing list. Please make your comments. ============================ IPv4 over IPv4CS (30 min) Samita Chakrabarti - ID: draft-ietf-16ng-ip-v4over-802-dot-16-ipcs-00 - STATUS: Active WG Document - GOAL: Initial discussion ============================ Document: http://www3.ietf.org/proceedings/07jul/slides/16ng-8.ppt MTU issues - Default MTU 1400 but can be increased to 1500 if no one sees any issue. ARP issues - Traditional IP requires ARP. ARP is not required for IPv4 CS. Multicast mapping - Don't recommend mcast mapping; use IPCS CIDs for multicast data delivery. Feedback from WG Conversation: Gabriel Montenegro: ARP is an issue internal to the system. No need to say anything *normative* here. Dave Thaler: that was the consensus from Prague discussion. Behcet Sarikaya: If you emphasize the PtP link you should say more about the address assignment. At least, as much as in IPv6 draft. Dave Thaler: For efficiency should be high as possible but avoiding fragmentation. You should incorporate the discussion of the IETF 68. As is in the jabber logs. 1482 was the "consensus" in Prague based on jabber room from that time. ============================ FMIP6 over IEEE 802.16e Networks (10 min) Heejin Jang - ID: draft-ietf-mipshop-fh80216e-01 - STATUS: Active MIPSHOP WG Document - GOAL: Wrap-Up issues raised by MIPSHOP mailing list ============================ Document: http://www3.ietf.org/proceedings/07jul/slides/16ng-4.ppt MIPSHOP document - Some feedbacks are already in the current document (v02) - Delete Section 3 - Link_Going_Down is more appropriate than Link_Handover_Imminent for handover preparation. Conversation: Frank Xia: There is a new section in the Fast handovers 4068-bis about the shared prefix announcement by PAR. Singh Ajoy: link going down will not work, why did you abandon handover imminent? Rajeev Koodli: You should give a reason about the prefix assignment. Jonne Soienen: The draft should not specify how WiMAX uses FMIP. A question about the availability of the WiMAX documents. Gabriel Montenegro: Became public recently. see the WiMAX Forum website. 802.21 triggers not yet adopted by wimax. w/respect to that example, w/respect to that example, how about using the link-up (similar to DNA) in wimax for reactive mode? ============================ Location Based MBS Service in IEEE 802.16 Networks (10 min) Jongtaek Oh - ID: none - STATUS: none - GOAL: Individual submission ============================ Document: http://www3.ietf.org/proceedings/07jul/slides/16ng-5.ppt Academic work, but difficult (very) to deploy Conversation: Dave Thaler: What about power management? what are your expectations to not wake up dormant nodes? Jongtaek Oh: The user who wants to receive the service turns on the program on the MS. ============================ Multicast Transport over IEEE 802.16 Networks (10 min) Sangeon Kim - ID: coming soon - STATUS: none - GOAL: Individual submission ============================ Document: http://www3.ietf.org/proceedings/07jul/slides/16ng-3.ppt Conversation: Max Riegel: What exactly is your target? Sangeon Kim: Mapping of IP mcasts to mcast CIDs. Daniel Park: This is an individual submission. Max Riegel: no management here. ============================ WEIRD project overview (10 min) Bruno Sousa - ID: none - STATUS: none - GOAL: Introduction to 16NG relevant project ============================ Document: http://www3.ietf.org/proceedings/07jul/slides/16ng-2.ppt WEIRD - A 24 month integrated project - Aiming at implment research testbeds using the WiMAX - Applications: VoIP, video, telemedicine, environmental monitoring - 4 testbeds Conversation: Gabriel Montenegro: which are the carriers?, which bands? Bruno Sousa: Carriers involved to use licensed spectrum are Orange, BT, WIND(Italy). Gabriel Montenegro: are you employing WiMAX spec or 802.16 std? Bruno Sousa: compliance with WiMAX Forum as much as possible. Samita Chakrabarti: did you implement a particular WiMAX profile? Bruno Sousa: Trying to stay close. Not specifically wimax, so they may depart. ============================ Security API for 802.16 (10 min) Pascal Urien - ID: draft-urien-16ng-security-api-00 - STATUS: none - GOAL: Individual submission ============================ Document: http://www3.ietf.org/proceedings/07jul/slides/16ng-1.ppt Info on API for secure hardware ============================ Closing Chairs ============================