Subject: [16NG] 69th-minutes (DRAFT)

From: "Daniel Park" <[email-masked]>
Date: Thu, 2 Aug 2007 13:47:14 +0900

Thanks Jihoon as our secretary. Folks, here is the meeting minutes.
Should you have any change, please let chairs and secretary know that.

Daniel Park [at] SAMSUNG Electronics.

================[BEGIN]===================

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
============================

_______________________________________________
16NG mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/16ng