[03:41:22] --- tsavo_work@jabber.org/Meebo has joined
[04:07:54] --- apetrescu has joined
[04:08:06] <apetrescu> slide: Agenda - Friday (1/2)
[04:08:16] <apetrescu> slide: Agenda - Friday (2/2)
[04:08:44] --- saphira@jabber.no has joined
[04:08:55] --- bxmina has joined
[04:10:03] <apetrescu> slide: WG Status (as of today)
[04:11:30] <apetrescu> slide: Mileston Updated
[04:11:55] <apetrescu> (apparently some slides at https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=68 search for 16ng)
[04:13:10] <apetrescu> MAx Riegel presenting next
[04:13:58] --- behcet.sarikaya has joined
[04:13:58] <apetrescu> slide: IP over ETH over IEEE802.16
[04:14:32] <apetrescu> slide: Outline
[04:15:24] <apetrescu> slide: Achievements since IETF-67
[04:17:48] <apetrescu> slide: Issues raised on mailing list
[04:19:55] <apetrescu> slide: Issues raised on mailing list
[04:24:03] <apetrescu> SDP: whats going on on in terms in MBS in WiMax - what's going on there?
[04:24:11] <apetrescu> MR: WiMax starting to address MBS.
[04:24:19] <apetrescu> SDP: forming a new group this year?
[04:24:24] <apetrescu> MR: not say starting
[04:24:51] <apetrescu> MR: part of release 1.5, WiMax Foirum NWG has a team starting trying to define what kind of MBS, sublayer, just a couple of people wking together
[04:25:00] <apetrescu> MR: there'll be a subteam working on protocol details
[04:25:19] <apetrescu> MR: currently nailing down scoping/reqs, what mbs., broadacast an dmcast mean, they try to define MBS service
[04:25:27] <apetrescu> MR: by deploying uma? bicast.
[04:25:37] <apetrescu> MR: may be metter MBS whne multicast CIDs
[04:25:59] <apetrescu> SDP: as you know, probably couple meeting back, several 16ng worried about MBS, regarding mcast/bcast service over 16ng
[04:26:11] <apetrescu> SDP : you wanna take and this and include in this doc?
[04:26:18] <apetrescu> SDP: any relationship ETHCS and IPCS?
[04:26:46] <apetrescu> SDP: IPCS doc is not taking care of MBS and this sort in this doc, but ETHCS has MBS, but both doc obviously target proposed std in IETF
[04:26:54] <apetrescu> SDP: from WG perspective trying to clarify between them
[04:26:59] <apetrescu> SDP: between ICPS and ETHCS
[04:27:10] <apetrescu> SDP: or do we have to ammend IPCS and ETHCS in connection to MBS?
[04:27:30] <apetrescu> MR: timing. MBS just started and so IPCS is not able to address MBS in detail because no reference
[04:27:58] <apetrescu> MR: for IPETHCS we're later, we may be able to address MBS service, but we have possiblility to provide provisioning, how things relate to each other
[04:28:07] <apetrescu> MR: maybe early enough, maybe good undesrtadnaint.
[04:28:29] <apetrescu> MR: for MBS you must install a sort of multicast service flow management, maybe related to link model, but we have to see how design ed in spec
[04:28:35] <apetrescu> MR: for current approach we not use MBS
[04:28:51] <apetrescu> MR: even if designed, not sense, if other group is doing (market-relevant)
[04:29:02] <apetrescu> MR: but good idea, good hint, maybe even in annex.
[04:29:07] <apetrescu> MR: how MBS related to this doc.
[04:29:16] <apetrescu> SDP: IPCS and ETHCS and consistency between those
[04:29:29] <apetrescu> MR: we have to clarify in 16ng we are addressing it, IPCS is done, not reference.
[04:29:46] <apetrescu> MR: ETHCS has a couple of months ahead, so we can take into account, but should be kept aligneed
[04:29:53] <apetrescu> SDP: document structure, WiMax implication
[04:30:06] <apetrescu> MR: in IPCS we only have generic text in main, all wimax text moved to appendix
[04:30:12] <apetrescu> sorry that was SDP not MR
[04:30:17] <apetrescu> SDP: how about ETHCS
[04:30:32] <apetrescu> MR: ETHCS was written such that independent of link, no ref to Wimax
[04:30:39] <apetrescu> MR: Wimax spec only provides...
[04:30:49] <apetrescu> MR: we take 16ng approach and put it into wimax archi
[04:30:56] <apetrescu> SDP: not described in this doc right?
[04:31:13] <apetrescu> MR: wimax takes care of 16 spec, if you take them together sidebyside you ssee how works
[04:31:23] <apetrescu> MR: we made modifs to both, basic approach in the 16mng doc
[04:31:36] <apetrescu> MR: in wimax spec we provide the details see how works together
[04:31:43] <apetrescu> Gorry Ferhurst
[04:32:07] <apetrescu> GF: ARP must not be implemented, but must be turned off? what protocol rec?
[04:32:18] <apetrescu> GF: NDno relay, but ARP relay? why?
[04:32:35] <apetrescu> SDP: we remmoved ND relay, because multicast multicast snooping in place, do whats necessary for ND
[04:32:50] <apetrescu> GF: you snooping all? not what a snooping bridge did, but ok
[04:33:06] <apetrescu> MR: filtering out some, not a for bcast, that's why ARP relay to filter bcast.
[04:33:13] <apetrescu> MR: thats why
[04:33:25] <apetrescu> GF: my notion of ND bridge doesnt snoop a ...
[04:33:31] <apetrescu> Dave Thaler
[04:33:52] <apetrescu> DT: mld snooping switch, and since nd is multicast...
[04:34:02] <apetrescu> DT: what not have igmp that works snooping for bcast.
[04:34:10] <apetrescu> DT: not option for igmp proxy there
[04:34:37] <apetrescu> slide: Revision -01.txt
[04:35:51] <apetrescu> (name 'Gorry Ferhurst' is certainly not correct, but cant find the right spelling, sorry)
[04:37:08] <apetrescu> slide: Does RFC4562 solve this issue?
[04:38:34] <apetrescu> Bernard Aboba
[04:38:46] <apetrescu> BA: other potential alternative: dynamic VLANs
[04:39:03] <apetrescu> MR: Ive seen, but this RFC is a nice spec, same issues in wireless networks.
[04:39:11] <apetrescu> MR: mobile terminals arent handled in spec
[04:39:28] <apetrescu> MR: havent seen support for enterprise lan scenario, and IPv6 support not completed, but thinks
[04:39:48] <apetrescu> MR: most difficult thing we have to cope in spec, 4562 is informational, no normative reference.
[04:40:05] <apetrescu> MR: little bit tricky to understand all details in there, missing xplanatiopn of reasoning.
[04:40:09] <apetrescu> ...
[04:40:38] <apetrescu> slide: Conclusion and further proceeding
[04:41:13] <apetrescu> Jari Arkko
[04:41:25] <apetrescu> JA: we have a process for 'down'drafts(?)
[04:41:36] <apetrescu> JA: not impossible, but most of time there's a reason why informational or experimental
[04:41:48] <apetrescu> JA: not a particular grasp of this draft here, nit will make...
[04:42:08] <apetrescu> DT: questio: 4562 is informational, came through as a draft-individual, is it independent or an IETF
[04:42:14] <apetrescu> BA: independent
[04:42:19] <apetrescu> DT: not IETF consensus
[04:42:27] <apetrescu> MR: good information
[04:42:35] <apetrescu> DT: if you use it as problem description
[04:42:45] <apetrescu> DT: if you say you have to do that behaviour.
[04:42:52] <apetrescu> DT: not sure anything normative in there
[04:43:07] <apetrescu> MR: nothing normative there
[04:43:17] <apetrescu> DT: MLD snooping _is_ IETF product
[04:43:24] <apetrescu> DT: MLD snooping is informational
[04:43:41] <apetrescu> GF: point to 4605
[04:43:55] <apetrescu> GF: 4605 standards track
[04:44:24] <apetrescu> slide: Conclusion and further proceeding
[04:45:18] <apetrescu> BA: general q, there are people deploying this, is this doc in sync with networks already operating?
[04:45:40] <apetrescu> MR: believes there are people who are already deploying IP over Eth 802.16, these are in discussion, working, getting comments
[04:45:45] <apetrescu> MR: trying to keep it into sync
[04:45:54] <apetrescu> MR: with this spec we try to address large infra
[04:46:05] <apetrescu> MR: people doing small deployments is only Base Station
[04:46:12] <apetrescu> MR: keen on getting final link
[04:46:23] <apetrescu> MR: not know of details of such implementation
[04:46:26] <apetrescu> MR: not working
[04:46:39] <apetrescu> SDP: comment? feedback?
[04:47:24] <apetrescu> slide: Agenda - Friday (2/2)
[04:48:59] <apetrescu> SDP: requests feedback on syam's IPv4 over IPv4CS document
[04:49:03] <apetrescu> SDP: ok?
[04:49:17] <apetrescu> slide: IPv4 over 802.16 IP CS
[04:49:58] <apetrescu> slide: Objective
[04:50:08] <apetrescu> slide: IPv4 Convergence Sublayer
[04:50:43] <apetrescu> slide: Network Architecture
[04:51:03] <apetrescu> slide: Frame Format
[04:51:10] <apetrescu> slide: Maximum Transmission Unit (MTU)
[04:51:34] --- m_ersue has joined
[04:51:55] <apetrescu> DT: given this one is not Ethernet, why is default ethernet 2038 and not...
[04:52:09] <apetrescu> DT: the only req is 1500 or larger, but you choose lower - why?
[04:52:16] <apetrescu> BA: because the draft looks like Ethernet
[04:52:23] <apetrescu> DT: but this is not Ethernet, right?
[04:52:33] <apetrescu> SDP: not any MTU problem by using the IPv4 CS
[04:52:39] <apetrescu> (BA and DT private discussion)
[04:52:53] <apetrescu> SDP: repeats, I'll doublecheck, but
[04:53:15] <apetrescu> JA: will be simple to just have one value.
[04:53:33] <apetrescu> JA: also in the other v6 doc, theres discussion backend archi architecture influencing how influences
[04:53:34] <apetrescu> SDP: yes
[04:53:42] <apetrescu> DT: 1500 best value to avoid frag?
[04:53:49] <apetrescu> DT: or just picked up in the air?
[04:53:59] <apetrescu> JA: seems like wrong value because Eth frag
[04:54:13] <apetrescu> DT: maybe less than 1500, as long as above 1280 fine.
[04:54:19] <apetrescu> DT: 1484 or something
[04:54:37] <apetrescu> GF: 1482 mtu then strnage for ... discovery?
[04:54:39] <apetrescu> DT: no
[04:54:46] <apetrescu> GW: I thought preferred value
[04:54:52] <apetrescu> DT: anything above 1280 is fine
[04:55:08] <apetrescu> GW: but new ... discovery algorithms, choose... rather than ... redirect
[04:55:21] <apetrescu> BA: probably you choose ... hundreds and then fragment down
[04:55:42] <apetrescu> DT: JA point was that if you say 1500 you frag, BA says that even if below 1500 then frag
[04:55:48] <apetrescu> BA: initial vs ongoing frag
[04:55:54] <apetrescu> BA: continue to frag?
[04:56:04] <apetrescu> GF: a separate path mtu discovery discussion.
[04:56:15] <apetrescu> GF: if you... then...
[04:56:26] <apetrescu> slide: Address Assignment
[04:56:40] <apetrescu> SDP: MTU implications is very closed to 15 network characteristics...
[04:56:59] <apetrescu> SDP: after reading the doc, please make the comment on the mailing list, if serious concern please raise comment on MTU
[04:58:46] <apetrescu> SDP: answers the rfc3021 link - not need to take care of all these kinds of implications
[04:59:10] --- m_ersue has left
[04:59:33] <apetrescu> BA: there may be an interaction here, may be unfortunate
[04:59:58] <apetrescu> BA: if Ethernet exposes an Ethernet interface then DNA triggered... then DHCP, so ARP is sent, then you figure out what to do
[05:00:49] <apetrescu> slide: Address Resolution Protocol (ARP)
[05:01:40] <apetrescu> BA: problem dropping ARPs - you wont get an address if you do that, because in DNA you dont dhcp...
[05:01:46] <apetrescu> BA: no connectivity if dropping the arp.
[05:01:51] <apetrescu> SDP: but Connection ID
[05:02:02] <apetrescu> BA: in any operating system you'll have no address
[05:02:06] <apetrescu> SDP: why
[05:02:13] <apetrescu> BA: if exposing yourself as Ethernet...
[05:02:33] <apetrescu> DT: respond to any MAC address, sounds as if what youre proposing, manufcature ARP response... ARP goes on wire
[05:02:39] <apetrescu> DT: ARP successful..
[05:02:43] --- cabo--tzi--org@jabber.org has joined
[05:02:47] <apetrescu> BA: not get DHCP but get (MAC) address
[05:03:04] <apetrescu> DT: AR will not see dhcp request, but it will first plumb an address and try to use it
[05:03:11] <apetrescu> DT: if AR relaying DHCP...
[05:03:21] <apetrescu> BA: not just filtering, but manufacturing ARPs back
[05:03:42] <apetrescu> DT: that problem may have a different problem if you rely on ... bridge that; BA says if you do that...
[05:04:11] <apetrescu> DT: if you had an address and come back and renegotiate, CID says you're still on same, expecting AR to still maintain his IP address gotten...
[05:04:42] <apetrescu> SDP: this doc this kind of implications, let me try to have more comment and feedback on the mailing list and then we try to clarify on this issue.
[05:04:46] <apetrescu> BEhcet Sarikaya
[05:04:53] <apetrescu> BS: one slide back
[05:05:20] <apetrescu> BS: assigning an IP address, here the recommendation was to recommend a private address, with subnet mask unique for each mobile?
[05:05:28] <apetrescu> SDP: youre suggesting we need to cosidner NAT?
[05:05:43] <apetrescu> BS: because no prefix, havent read 3021, subnet mask is one thats used.
[05:05:53] <apetrescu> BS: subnet mask unique for each mobile node.
[05:06:07] <apetrescu> SDP: issue raised by mailing list, this should be considered
[05:06:18] <apetrescu> BS: communicated privately with Syam, not on mailing list.
[05:06:21] <apetrescu> SDP: have to check.
[05:06:28] <apetrescu> slide: Multicast Address Mappipng
[05:07:36] <apetrescu> SDP: considers need to map multicast address to mbs channel
[05:07:52] <apetrescu> SDP: once having more clear information from MBS then we have to consider this point of view.
[05:08:03] <apetrescu> slide: Way Forward: Adopt as a WG draft?
[05:08:08] <apetrescu> SDP: any technical comment?
[05:08:37] <apetrescu> SDP: initial document is available, please have a look at the draft, if enough discussion on the mailing list until next mtg, then WG will try to adapt
[05:08:49] <apetrescu> SDP: any concern, please speak up on the mailing list.
[05:09:41] <apetrescu> slide: Using DHCPv6 and AAA Server for Mobile Station PRefix Delegation
[05:09:50] <apetrescu> Behcet Sarikaya presenting
[05:10:01] <apetrescu> slide: Problem Statement
[05:11:37] <apetrescu> slide: Prefix Request Procedure
[05:13:30] <apetrescu> slide: Prefix Release Procedure
[05:14:14] <apetrescu> slide Prefix Delegation through AAA
[05:15:45] <apetrescu> BA: revising 3557... not thought of a use case for changing the ...
[05:16:00] <apetrescu> (its 3576 I believe)
[05:16:31] <apetrescu> DT: question, the sequence diagram, was the normal DHCP-PD stuff, right?
[05:16:46] <apetrescu> DT: that talks between AR and DHCP server with DHCP, but another slide AAA
[05:16:56] <apetrescu> DT: alternative AAA - DHCP? what relationship?
[05:17:02] <apetrescu> BS: alternative
[05:17:06] <apetrescu> DT: two different ways
[05:17:17] <apetrescu> BA: prefix delegation is still dhcp prefix delegation either way
[05:17:24] <apetrescu> DT: coming back ...
[05:17:38] <apetrescu> DT: two different ways of doing same thing, which one is mandatory?
[05:17:45] <apetrescu> BS: not recommending anything
[05:17:50] <apetrescu> DT:
[05:17:54] <apetrescu> BS: DHCP is better
[05:18:11] <apetrescu> DT: but BA that disadvantage might not be there
[05:18:15] <apetrescu> Jonne Soininen
[05:18:30] <apetrescu> JS: is this the normal procedure, is there something special related to .16?
[05:18:34] <apetrescu> BS: no new option
[05:18:45] <apetrescu> BS: comes up in this context, AR can use it in this approach
[05:18:55] <apetrescu> JS: more general thing, more somewhat, or concentrating on .16
[05:19:25] <apetrescu> JA: documenting the existing ways to do this, doesn tie to 16ng in any particular way, not in Charter
[05:21:48] <apetrescu> ...
[05:22:34] <apetrescu> SDP: has specification
[05:22:40] <apetrescu> SDP:...
[05:22:56] <apetrescu> BA: existing prefix attribute in ... could be actually be used to...
[05:23:42] <apetrescu> ...
[05:23:55] <apetrescu> closing...
[05:23:56] --- behcet.sarikaya has left
[05:24:00] --- apetrescu has left
[05:24:53] --- behcet.sarikaya has joined
[05:25:11] --- bxmina has left
[05:26:18] --- behcet.sarikaya has left
[05:30:55] --- tsavo_work@jabber.org/Meebo has left
[06:05:19] --- saphira@jabber.no has left
[07:19:07] --- cabo--tzi--org@jabber.org has left