[10:01:15] --- tsavo_work@jabber.org/Meebo has joined
[10:18:19] --- frodek has joined
[10:20:11] --- jyg has joined
[10:20:46] --- jyg has left
[10:21:36] --- dros66 has joined
[10:25:25] --- jyg has joined
[10:25:31] --- ks has joined
[10:26:01] --- behcet.sarikaya has joined
[10:26:01] --- jyg has left
[10:35:18] --- m_ersue has joined
[10:43:24] --- amy_zhao has joined
[10:45:32] --- amy_zhao has left
[10:46:20] --- apetrescu has joined
[10:46:50] <apetrescu> slideL WiMax Network Reference Model (roaming case, HA in vNSP)
[10:47:04] <apetrescu> slide: WiMax CSN Anchored Mobility Management
[10:48:01] <apetrescu> slide: WiMax Reference Points
[10:49:16] <apetrescu> slide: WiMAX NRM Considerations
[10:49:49] <apetrescu> some slides available at: https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=68, search 16ng)
[10:50:05] <apetrescu> slide: WiMax NRM Considerations
[10:51:35] <apetrescu> slide: WiMAX NRM: The simple case Stationary network deployment option
[10:52:26] <apetrescu> slide: Real deployments will be a mixture of scenarios
[10:53:38] <apetrescu> slide: WiMAX Network Model Implicationa for 16ng
[10:54:54] <apetrescu> slide: ASN anchored hand-over case
[10:55:39] <apetrescu> the bottom of the slides all say: Copyright 2006 WiMAX Forum (Credits to Domagoj Premec)
[10:56:40] --- ltn22@jabber.org has joined
[10:57:14] <apetrescu> slide: Mapping Functions to ASN Profiles
[10:59:02] <apetrescu> slide: ASN Data Plane (IP-CS Case)
[11:00:24] <apetrescu> slide: ASN Data Plane (IPoETH-CS Case)
[11:01:12] <apetrescu> slide: Control Plane and Data Path Protocol Layering
[11:01:51] --- m_ersue has left
[11:02:42] <apetrescu> slide: IP Network Service vs. Ethernet Network Service
[11:03:54] <apetrescu> slide: WiMAX Interworking with DSL (over V-interface)
[11:04:07] <apetrescu> Max: sorry for
[11:04:23] <apetrescu> Max: switch off and then
[11:04:41] <apetrescu> Max: acoustics is magic, more magic than radio
[11:06:32] <apetrescu> slide: WiMAX ASN Model Implications for 16ng
[11:08:04] <apetrescu> slide: slide: Relays in Mobile WiMAX Rationale:
[11:10:29] <apetrescu> slide: WiMAX - Wi-Fi Relays
[11:12:15] <apetrescu> slide: WiMAX NWG Definitions for Multiple Hosts Support
[11:14:32] <apetrescu> slide: Network Sharing and Roaming with Relay w/ Multiple Hosts Support
[11:16:03] <apetrescu> slide: WiMAX Multiple Hosts Support Implications for 16ng
[11:17:28] <apetrescu> slide: Summary WiMAX NWG Release 1 Features
[11:20:37] <apetrescu> slide: The End
[11:21:08] <apetrescu> SDP: we interoperable implementations, good chance to make say what16ng, WiMax... please feel free to make questions at this time
[11:21:11] <apetrescu> Dave Thaler:
[11:21:24] <apetrescu> DT: clarifying, slide 25, ASN may support IPCs and ETHCS
[11:21:34] <apetrescu> DT: interpret that as ... some optional?
[11:21:57] <apetrescu> DT: clarification? If ASN supports one of them is there only one per CSN or mixed or what?
[11:22:02] <apetrescu> Max Riegel: MR
[11:22:07] <apetrescu> MR: IPCS not visible to CSN
[11:22:24] <apetrescu> DT: would ETHCS and IPCS both ever be used by same ASN that CSN is serving
[11:22:37] <apetrescu> MR: latter statement
[11:23:04] <apetrescu> DT: what you're not doing, you're not taking one type of MS using IPCS and the other ETHCS and try to put these together in isame CSN, not doing that, right?
[11:23:08] <apetrescu> MR: not specified yet.
[11:23:17] <apetrescu> MR: how ETHCS is served in cSN...
[11:23:21] <apetrescu> MR: MSP and ISP
[11:23:26] --- jyg has joined
[11:23:28] <apetrescu> DT: why I'm asking this is that.
[11:23:50] <apetrescu> DT: last IETF two disjoint worlds between fixed/nomadic one is ETH one of IP, not talk to each other.
[11:24:05] <apetrescu> DT: want to make sure they do talk to each other, multiple independent worlds.
[11:24:18] --- resnick has joined
[11:24:20] <apetrescu> DT: still valid not changing
[11:24:25] <apetrescu> RP: Raj Patil
[11:24:29] <apetrescu> MR:
[11:24:38] --- resnick has left
[11:24:43] <apetrescu> MR: where those are meeting is in the Access NEtwork
[11:24:57] <apetrescu> MR: leveraging whatever possible, serving ... as well as IP mobile customer
[11:25:08] <apetrescu> MR: different, but MS concerned by different world.
[11:25:15] <apetrescu> MR: most likely different CSNs
[11:25:22] <apetrescu> RP: that's the q, why different CSNs?
[11:25:34] <apetrescu> DT: in theory could be same CSN, but ...,
[11:25:50] <apetrescu> DT: assumptions in previous IETFs, you never had a case where... not directly...
[11:25:58] <apetrescu> DT: not change that assumptions
[11:26:13] <apetrescu> MR: translation is something we deal at Access Router
[11:26:25] <apetrescu> name please: not to ETHCS
[11:26:45] <apetrescu> name please (long hairs): much possible that same terminals... IPCS and ETHCS committed to same same CSN
[11:26:54] <apetrescu> name: donald von something?
[11:27:07] <apetrescu> Domagoj was that.
[11:27:41] <apetrescu> MR: the ... is used for forwarding service links.
[11:27:46] <apetrescu> MR: not on top of CS
[11:27:58] <apetrescu> GRE tunnelling is used just to provide management of service flows.
[11:28:16] <apetrescu> MR: if you try to implement switch network you'll run in trouble because you have to differentiate service flows.
[11:28:27] <apetrescu> MR:CID is not enough for ...
[11:28:44] <apetrescu> MR: GRE tunnelling endpoint is the base station and IP interface of gateway
[11:28:58] <apetrescu> MR: extending CID into ...
[11:29:21] <apetrescu> MR: using VLANs won't work in mobile environments, not even in stationary due to limited of address space.
[11:29:32] <apetrescu> MR answers to questions raised by somebody.
[11:29:51] <apetrescu> questioner: how is ... mode processing happenning?
[11:30:02] <apetrescu> MR: idle mode is done by our 6 control functions.
[11:30:18] <apetrescu> MR: BS can also buffer packets and to wait until.
[11:30:31] <apetrescu> questioner: ASN gateway is not aware of a ny ... mode?
[11:30:39] <apetrescu> MR: can be, but not sure latest spec, I'll email you
[11:30:42] <apetrescu> questioner: thanks.
[11:31:04] <apetrescu> ROnald Salomon?
[11:31:15] <apetrescu> RS: how do you treat scalable multicast environments?
[11:31:18] <apetrescu> MR: what?
[11:31:34] <apetrescu> RS: hundreds of subscribers, who's doing the actual replication to hundreds?
[11:31:44] <apetrescu> MR: in rel1.0 no multicast, so you have to do it in AR or bridge
[11:31:59] <apetrescu> MR: current implementation replicated in...
[11:32:09] <apetrescu> RS: not solution sufficient
[11:32:12] <apetrescu> MR: agree.
[11:32:32] <apetrescu> SDP: good information for 16ng folks
[11:32:42] <apetrescu> SDP: something will be delayed until friday.
[11:32:50] <apetrescu> SDP: one more good presentations.
[11:32:59] <apetrescu> SDP: thanks Max, clap hands, room claps hands.
[11:33:17] <apetrescu> slide: agenda - monday
[11:33:34] <apetrescu> Rajeev Patil (Basavaraj Patil) approaching
[11:33:43] <apetrescu> SDP: use IETF if you have more questins
[11:33:51] <apetrescu> SDP: presentation not yet on server, sorry.
[11:33:57] <apetrescu> Ahmad Muhanna: please put on server.
[11:34:51] <apetrescu> slide: IPv6 over IPv6CS: Issues from WG and IETF LC
[11:35:00] <apetrescu> RP: draft is in last call
[11:35:07] <apetrescu> RP: March 21st is last day of LC
[11:35:19] <apetrescu> draft-ietf-16ng-ipv6-over-ipv6cs
[11:35:32] <apetrescu> slide: IPv6 over IPCS or ETHCS
[11:37:39] <apetrescu> slide: Classification rules in IPCS
[11:38:59] <apetrescu> slide: use of secnodary mgmt connection
[11:41:31] <apetrescu> Jari Arkko: you're saying draft specifies by default you use regular, but by configuraiton you use something else, is that?
[11:41:49] <apetrescu> RP: there's a 2ndary mgmt connection that can be established, which is not the regular, can be used.
[11:41:54] <apetrescu> JA: how do you get there?
[11:42:08] <apetrescu> JA: what code do I need to have in my host? Or is it a configuration issue?
[11:42:17] <apetrescu> RP: you'll need support from MAC layer as well.
[11:42:19] <apetrescu> RP:
[11:42:30] <apetrescu> RP: a classification issue.
[11:42:46] <apetrescu> RP: configuration type is mapped to 2ary mgmt connection
[11:42:52] <apetrescu> RP: for all practical ...
[11:42:59] <apetrescu> JA: by default htis should just work.
[11:43:03] <apetrescu> RP: thanks.
[11:43:49] <apetrescu> RP: MaxRtrAdvInterval
[11:45:02] <apetrescu> slide: MTU Recommendation
[11:47:20] <apetrescu> slide: IPv4/v6 on the same transport connection
[11:48:48] <apetrescu> slide: service flow establishment
[11:50:25] <apetrescu> SDP: clarification on MTU
[11:50:32] <apetrescu> SDP: recommend 1500?
[11:50:49] <apetrescu> SDP: any different MTU issues? 16.8, 16d, 16e?
[11:51:02] <apetrescu> RP: default value 1500 should be good for all 16x
[11:51:20] <apetrescu> RP: minimum default in rfc2460 applies
[11:51:38] <apetrescu> RP: air interface link has capability to support... but backhaul links can be 1500bytes or less
[11:51:43] --- yowada has joined
[11:51:51] <apetrescu> RP: appendix has value lower than 1500
[11:51:59] <apetrescu> RP: MTU in WiMax is 1400
[11:52:09] <apetrescu> SDP: GPCS
[11:52:15] <apetrescu> SDP: you will fix this issue?
[11:52:21] <apetrescu> RP: not sure
[11:52:29] <apetrescu> RP: multiple different kinds of CS...
[11:52:39] <apetrescu> RP:this is recognized as an issue
[11:52:49] <apetrescu> RP: not working on that
[11:52:52] <apetrescu> Max Riegel
[11:52:58] <apetrescu> MR: 16g spec for GPCS
[11:53:09] <apetrescu> MR: GPCS hasn't classification spec'ed, just a pipe.
[11:53:20] <apetrescu> MR: 16-2004 is specifying classification rules
[11:53:32] <apetrescu> MR: limitation: for a particular CID the ... is restricted.
[11:53:40] <apetrescu> MR: for IPv4 then only IPv4 classifiers.
[11:53:48] <apetrescu> MR: there's no classification defined for GPCS.
[11:53:55] <apetrescu> RP: in terms of bandwidth.
[11:54:07] <apetrescu> RP: current state of technology, go with recommendation here which is IPCS
[11:54:10] <apetrescu> Suresh Krishnan
[11:54:14] <apetrescu> SK: MTU
[11:54:23] <apetrescu> SK: inter-RA, the host must take it.
[11:54:46] <apetrescu> SK: if the MTU in RA is smaller, then host must take it - makes not sense, because Host does MTU.
[11:54:51] <apetrescu> RP: needs to be a must
[11:54:59] <apetrescu> SK: needs to be a must
[11:55:01] <apetrescu> RP: ok
[11:55:10] <apetrescu> SK: not talk about PMTU, because that's a PATH
[11:55:13] <apetrescu> RP: right
[11:55:22] <apetrescu> SK: default value is 1500.
[11:55:37] <apetrescu> SK: 1280 i sminimum in 2460rfc but not 1500
[11:55:46] <apetrescu> SK: better use 2038(mtu)
[11:55:51] <apetrescu> RP: ok
[11:56:05] <apetrescu> SK: you can also use RA to put MTU greater than 1500.
[11:56:27] <apetrescu> RP: default value you can always use greater than that.
[11:56:34] <apetrescu> SK: just put text
[11:56:43] <apetrescu> RP: ok. identified as issue and gets captured.
[11:57:14] <apetrescu> slide: Conflicting BS vs AR indications
[11:59:01] <apetrescu> slide: dual-stack support
[12:00:31] <apetrescu> DT:is there any assumptions between transport connection and what IP sees? Can you have an IPv4 transport connection and an IPv6 connection and they both go to same transport interface?
[12:00:33] <apetrescu> RP: no
[12:00:48] <apetrescu> RP: classifiers are the ones.
[12:00:59] <apetrescu> RP: matter of classifier rules.
[12:01:36] <apetrescu> DT: "it is not legal to a host to use both CS, with different transport connections and treat them with same interface" is that correct?
[12:01:45] <apetrescu> RP: not sure I understand what we try to do there.
[12:02:07] <apetrescu> DT: compare to PDP, negotiate with IPCP... PDP has multi-link... is that legal or illegal in this context?
[12:02:29] <apetrescu> RP: yes... what would have happened is that there are two transport connections.
[12:02:50] <apetrescu> DT: make a statement: one transport connection goes to IPv6CS and the other to IPv4CS...
[12:03:15] <apetrescu> DT:... if you don't do then kind of leave up to implementatio... that's what Id like to hear but...
[12:03:28] <apetrescu> JA: remember kind of draft is says different interfaces...
[12:03:31] <apetrescu> JA: can be fixed
[12:03:35] <apetrescu> RP: yes
[12:03:52] <apetrescu> DT: it's simpler for hosts for users and operators if you can combine them
[12:04:07] <apetrescu> JA: intention of having soething in the document is to explain how the picture goes.
[12:04:22] <apetrescu> RP: it is not illegal Dave says.
[12:04:50] <apetrescu> RP: implementer is legal to see .16 as an interface over which both v4 and v6 can be transported... you need to make sure classifiers exist.
[12:05:09] <apetrescu> Erik Nordmark
[12:05:36] <apetrescu> EN: better setup a ip6... if you set up a ipv6 cs then don't try to send anything else on it...that's what oyu say right.
[12:05:37] <apetrescu> RP: yes
[12:05:42] <apetrescu> DT: don't over-constrain it
[12:06:11] <apetrescu> DT: is technically out of scope for draft?
[12:06:41] <apetrescu> DT: ETHCS starts tothinking about multiple encapsulations document. It would be more helpful to remove this discussion because not texh necessary.
[12:06:44] <apetrescu> RP: noted.
[12:06:51] <apetrescu> DT: text is scary.
[12:06:58] <apetrescu> DT: rest of doc is not blocked on
[12:07:08] <apetrescu> JA: removal then interoperability
[12:07:16] <apetrescu> DT: causes interoperabilit issues this text
[12:07:23] <apetrescu> DT: never share same DS on same link
[12:07:29] <apetrescu> DT: only a SHOUDL
[12:07:36] <apetrescu> DT: better not in the context in this draft
[12:07:55] <apetrescu> DT: question: if one station chosses IPCS and the other station chooses the other CS - can they talk to each other?
[12:08:11] <apetrescu> DT: without that kind of explanation this text makes no sense. better not go there.
[12:08:25] <apetrescu> MR: a BS is not a link, it's a concentration of hundreds of links
[12:08:31] <apetrescu> DT: ok that.
[12:08:43] <apetrescu> DT: document and slide are unclear as to what the requirements of the link
[12:09:02] <apetrescu> DT: two ways of solving: clarify the text or removing the text as outofscope. One or the other is fine
[12:09:07] <apetrescu> JA: need to talk about that more.
[12:09:12] <apetrescu> JA: talked to Bernard
[12:09:24] <apetrescu> JA: agreement we had with BErnard that this is required. Not removed.
[12:09:30] <apetrescu> JA: perhaps.
[12:09:38] <apetrescu> JA: let's talk to BErnard
[12:09:44] <apetrescu> RP: there's a default mode.
[12:10:03] <apetrescu> RP: you say that by default you should use IPCS
[12:10:14] <apetrescu> Marco Liebsch
[12:10:27] <apetrescu> ML: why idle mode support justifies such a huge interval? why?
[12:10:32] <apetrescu> ML: do that on layer 2 not 3
[12:10:46] <apetrescu> RP: in order to deliver RA you need to wake up the mobile
[12:10:55] <apetrescu> RP: the mobile has to then come up establish bearer.
[12:11:12] <apetrescu> ML: setting huge value so that wait that the ...
[12:11:25] <apetrescu> ML: why is there a req to deliver RA to idle mode?
[12:11:33] <apetrescu> RP: violating the IP stack...
[12:11:43] <apetrescu> ML: even if address expires then who cares, it can re-configure
[12:11:54] <apetrescu> RP: host expects
[12:11:59] <apetrescu> ML: what does mean idle mode?
[12:12:16] <apetrescu> RP: mobility detection may use this.
[12:12:35] <apetrescu> RP: separate document can you rely on RA or RS... breaks backward compatibility.
[12:12:47] <apetrescu> RP: we had this discussion with 2461bis...
[12:12:55] <apetrescu> ML: I don't see a technical reason.
[12:12:58] --- behcet.sarikaya has left
[12:13:02] <apetrescu> RP: not sending periodic RAs is not enough
[12:13:14] <apetrescu> Jun Ta
[12:13:32] <apetrescu> JT: idle mode, do you consider a Mobile IPv6 structure?
[12:13:35] <apetrescu> JT: idle mode
[12:13:46] <apetrescu> JT: roam under a different AR
[12:13:54] <apetrescu> JT: in normal mode should be considered.
[12:13:59] <apetrescu> JT: about Mobile IPv6?
[12:14:05] <apetrescu> RP: you mean RAs of MIP6?
[12:14:06] --- tsavo_work@jabber.org/Meebo has left: Logged out
[12:14:07] <apetrescu> JT: yes
[12:14:15] <apetrescu> JT: common behaviour...
[12:14:32] <apetrescu> JT: how is a kind of roam under different AR? Not ascending an ee-ooo
[12:14:38] <apetrescu> RP: not understand?
[12:14:45] <apetrescu> RP: movement detection mip6?
[12:14:47] <apetrescu> JT: yes
[12:14:52] <apetrescu> JT: yes because different...
[12:15:05] <apetrescu> JT: need to clarify, something we need to do with MIP6 or simple IPv6
[12:15:10] <apetrescu> RP: any difference?
[12:15:18] <apetrescu> JT: wait for idle mode
[12:15:31] <apetrescu> JT: we can consider this is coming far away from an original AR
[12:15:37] <apetrescu> JR: inform
[12:15:40] <apetrescu> JT: address
[12:15:48] <apetrescu> JT: any packets from hr link
[12:15:56] <apetrescu> JT: agreed you know AR
[12:16:01] <apetrescu> JT: duty in idle mode
[12:16:11] <apetrescu> JT: this problem is in MIP6 because only tight to RA
[12:16:17] <apetrescu> JT: how to pan enter a room
[12:16:35] <apetrescu> JT: idle mode then need to clarify something if we comit this way of terminal to handover
[12:16:38] <apetrescu> JT: between different AR
[12:16:51] <apetrescu> RP: draft is not talking things like half-four interfaces
[12:16:58] --- tsavo_work@jabber.org/Meebo has joined
[12:17:02] <apetrescu> JT: this needs to be seen and may
[12:17:08] <apetrescu> JT: need to do something analysis
[12:17:16] <apetrescu> JT: 2nd problem
[12:17:35] <apetrescu> JT: terminal can network based on ETHCS and ETHCS there are two scenarios: c-agent, ..
[12:17:46] <apetrescu> JT: how it can be decided which has by the temrinal
[12:17:54] <apetrescu> JT:clarifying in this spec.
[12:18:02] <apetrescu> RP: there's a separate document ETHCS IP over
[12:18:15] <apetrescu> RP: in the context of this doc which is specific to IPCS.
[12:18:20] <apetrescu> JT: problem idle mode
[12:18:22] <apetrescu> RP: write
[12:18:36] <apetrescu> RP: packets would not be delivered.
[12:18:39] <apetrescu> jT: ok
[12:18:45] <apetrescu> Jinhyeock Choi
[12:18:55] <apetrescu> JC: idle should be handled in ...
[12:19:04] --- ltn22@jabber.org has left
[12:19:07] <apetrescu> SDP: mailing list discussion for details.
[12:19:12] <apetrescu> slide: Next Steps
[12:19:14] --- dros66 has left
[12:19:19] <apetrescu> LC ends Mar 31st.
[12:19:30] <apetrescu> RP: I-D 09.
[12:19:38] <apetrescu> SDP: thanks for coming
[12:19:44] <apetrescu> SDP: see you in Fri morning session.
[12:19:54] <apetrescu> SDP: where's the bluesheet.
[12:20:03] --- jyg has left
[12:20:15] --- apetrescu has left
[12:20:25] --- tsavo_work@jabber.org/Meebo has left
[12:20:42] --- yowada has left
[12:21:05] --- ks has left
[12:39:29] --- m_ersue has joined
[12:39:53] --- m_ersue has left
[12:40:03] --- frodek has left
[12:55:33] --- behcet.sarikaya has joined
[14:13:44] --- behcet.sarikaya has left