[14:55:51] --- LOGGING STARTED
[18:20:04] --- frodek has joined
[18:21:10] --- rhe has joined
[18:25:16] --- dthaler has joined
[18:25:45] --- fdupont has joined
[18:26:53] --- fdupont has left
[18:32:13] --- venaas has joined
[18:33:00] --- yangwoo has joined
[18:33:11] --- john.zhao has joined
[18:34:13] --- mike has joined
[18:34:56] <john.zhao> at now alan is speaking
[18:35:52] <venaas> Alain talking about all the pieces that need to be changed, lots of work
[18:36:00] <venaas> alain: better move to ipv6
[18:37:17] --- nm has joined
[18:37:19] <venaas> dave thaler: says assumption that can code now and decide about public/private later is not true
[18:37:26] --- shinta has joined
[18:38:36] <venaas> dave: thinks may be ok to use 240 space between consenting adults...
[18:39:13] --- florent.parent@gmail.com has joined
[18:39:13] <venaas> Eliot: thinks it's worth doing this even if we have v6. it's a large chunk of the v4 space
[18:40:31] <venaas> Eliot: think it's worth doing this to give people more time to transition
[18:41:31] <venaas> iljitch: thinks it's the correct way to do, even if it doesn't buy us anything
[18:42:20] <venaas> Iljitch: it's too much stuff out there that cannot be changed, so will not be fully useable
[18:43:09] <venaas> jari: when might this become useful address space and what would the use of these addresses be then
[18:43:38] <venaas> eliot: when it might be useful depends on the use. useful earlier for limited use than general....
[18:43:59] <venaas> Eliot: a few years...
[18:45:02] <venaas> someone: think should conclude on something to make vendors start changing code... (I think)
[18:45:52] <venaas> Eliot: this might help a few people, but we need to move to v6 anyway
[18:46:07] --- florent.parent@gmail.com has left
[18:46:32] --- trond has joined
[18:46:42] --- cpignata has joined
[18:48:39] <venaas> someone else: might have limited uses etc (had trouble getting all that he said)
[18:49:27] <dthaler> (clarifying the note above about what I said about consenting... I said it's only possibly acceptable in controlled environments where you have control over all the devices, protocols, and applications; anything else is a non-starter... this implies it's necessarily private not public space btw)
[18:50:23] <venaas> someone else saying how this can be useful in his own private high density deployment I think
[18:53:06] <venaas> dave: two separate questions whether to use it in tightly controlled environments and mandating code changes for general use
[18:53:18] --- ricp has joined
[18:53:55] --- yoshi has joined
[18:53:59] <venaas> bofs this week
[18:54:12] <venaas> source address verification bof tomorrow
[18:54:26] <venaas> cga extensions and maintenance thursday morning
[18:55:03] <venaas> multicast mobility bof was not approved
[18:55:24] <venaas> asking mobopts RG for recommendatoins
[18:55:29] <venaas> tictoc bof
[18:55:40] <venaas> 2nd bof. lots of interest
[18:56:05] <venaas> had a charter that had reasonable acceptance
[18:56:12] <venaas> will see if might become a wg
[18:56:16] <venaas> wg news
[18:56:17] <venaas> MEXT
[18:56:42] <venaas> mext new. rechart discussions on a few other groups
[18:56:50] <venaas> 6man group up and running
[18:57:01] <venaas> v6ops will discuss if new transition work is needed
[18:57:29] <venaas> iab/iesg tracking situation with regards to new work in 6man/v6ops/behave
[18:57:29] <ricp> conference audio seems to be having problems
[18:57:46] <venaas> iab statement on nat-pt
[18:57:50] <venaas> area document status
[18:58:02] <venaas> cheshire-ipv6-acd in iesg review
[18:58:15] <venaas> ipv6-source-routing-is-evil not going forward
[18:58:36] <venaas> a question whether should do something though
[18:58:51] <venaas> 240space just discussed
[18:58:55] --- ricp has left
[18:59:01] <venaas> addreslect api...
[18:59:31] <venaas> router-alert-iana discussed today. atlas-icmp-unnumbered on list. icmptype11code0 discussed on list
[18:59:46] --- shikob has joined
[19:00:06] <venaas> Issues with the IP Router Alert Option
[19:00:14] <venaas> draft-manner-router-alert-iana-00
[19:00:30] <dthaler> Router Alert IANA Considerations <http://www3.ietf.org/proceedings/07dec/slides/intarea-1.pdf>
[19:00:37] <venaas> identified problem and some solutions
[19:00:52] <venaas> ipv4 RAO value 0. ipv6 has several values
[19:01:05] <venaas> 1 ipv4, 36 ipv6
[19:01:35] <venaas> multiple v4 values used but no procedure for allocation
[19:02:02] <venaas> NSIS needs new v4/v6 rao values
[19:02:26] <venaas> ipv6 has 2 rao values for rsvp (only one needed)
[19:03:03] <venaas> rfc3175 has ipv4 rao values that should be in a registry
[19:03:24] --- yangwoo has left: Computer went to sleep
[19:04:04] <venaas> Bob Hinden, doesn't see much point in aligning v4 and v6
[19:04:37] --- xiaohunhun has joined
[19:04:44] <venaas> jukka (the presenter) wants to have rsvp aggregation levels for v4 as well. the alignment is not the most important
[19:05:14] <venaas> someone: is this about documenting what is in use
[19:05:23] <venaas> jukka: yes mainly a cleanup
[19:05:48] --- mike has left
[19:05:56] <venaas> same someone: could we have some value for experimental... he is using something unspec
[19:06:04] <venaas> jari: think he said that was a good idea
[19:06:38] <venaas> Tony Li: RRG update
[19:07:12] <dthaler> RRG Update <http://www3.ietf.org/proceedings/07dec/slides/intarea-3.ppt>
[19:07:18] <venaas> looking into scalable routing and addressing
[19:07:39] <venaas> 20 different proposals and updates
[19:08:09] <venaas> produced design goals document. some taxonomy work
[19:08:27] <venaas> updates to lisp, apt, six/one this week. 3 new proposals
[19:08:56] <venaas> still open for new proposals, but starting to work towards some convergence. process may take a year
[19:09:29] <venaas> wants proposals to compare themselves according to goals, taxonomy etc
[19:09:52] <venaas> many of the current proposals are map and encap
[19:10:23] <venaas> a common issue with tunneling is pmtud, asking if audience agrees
[19:11:04] <venaas> some agreement
[19:11:43] <venaas> iljitch: noting issue is many hosts with DF set and not accepting incoming icmp
[19:12:22] <venaas> Iljitch: fragment anyway, minimum mtu of say 1600 in network etc...
[19:12:28] --- raj has joined
[19:13:31] <venaas> fred: agreeing with Iljitch. asking for network in general to have at least 2000 byte mtu I think
[19:14:59] --- john.zhao has left: Computer went to sleep
[19:15:00] <venaas> someone: talking of performance issues with fragmentation I think. claims many stacks not doing pmtud correctly today I think
[19:15:14] <venaas> DHCP-based Authentication
[19:15:18] <dthaler> DSL Authentication Discussion <http://www3.ietf.org/proceedings/07dec/slides/intarea-2.ppt>
[19:15:26] <venaas> introduction and background by Jari
[19:15:49] <venaas> moving away from PPPoE in DSL, want to keep business models and infrastructure
[19:16:31] <venaas> several potential approaches like 8021x, pana, dhcp etc. considering here whether dhc should be rechartered to work on this
[19:16:50] <venaas> discussing here and not dhc because not clear dhc is the best solution
[19:17:53] <venaas> might need to extend dhc changing state machine etc. would be fundamental changes that need to be discussed in the ietf
[19:18:19] <venaas> want to get sense of the room whether should do dhcp work on this
[19:18:35] <venaas> maybe guidance on alternatives
[19:18:55] <venaas> dslf meeting next week so need to get some sense of the room here to have something to tell them
[19:19:54] <venaas> Mark: AD hat off rest of the meeting. explaining the problem
[19:20:36] <venaas> mark: the problem space. migration from PPPoE to IP changing as little equipment as possible
[19:20:59] <venaas> gradual migration
[19:21:38] <venaas> subscriber line option 82 auth
[19:21:52] <venaas> bob: what is driving the changing. why do they want to do this
[19:22:14] <venaas> mark: there are many reasons, bottom line is its happening
[19:22:36] --- ldondeti has joined
[19:22:47] <venaas> talking of dhcp subscriber line option 82 authentication
[19:25:40] <venaas> option 82 not always sufficient
[19:26:58] <venaas> Sam: discover initiates by home gateway or equipment behind it
[19:27:31] <venaas> mark: lots of different things out there. done in several ways
[19:27:46] <venaas> Ric Pruss continues the presentation
[19:28:28] <venaas> one model is dedicated vlan with one vlan per customer
[19:29:11] <venaas> expensive to deploy. more common to use shared vlan with some bridging
[19:30:12] <venaas> one driver for getting rid of pppoe is efficient multicast
[19:30:35] <venaas> about 16 different variations on architectures
[19:31:08] <venaas> dhcp-auth as "drop-in" for PPPoE without new dhcp messages (alt 1)
[19:31:27] <venaas> reverse auth etc not supported
[19:31:37] <venaas> dhcp-auth with earp pass through (alt 2)
[19:31:50] <venaas> s/earp/EAP
[19:32:04] --- john.zhao has joined
[19:32:38] <venaas> dhcp fragmentation had lots of discussion on the list
[19:33:00] <venaas> says have 1240 bytes available for payload in dhc and EAP requires minimum 1020
[19:34:15] <venaas> what if home gateway a bridge. option 60 (vendor id) can be used to tell difference between boxes in the home to treat them differently
[19:34:42] <venaas> option 60 has been used in various proprietary ways
[19:34:50] --- UlrichHerberg has joined
[19:35:42] --- Bill has joined
[19:35:45] <venaas> IPv6: many open issues for how to do IPv6 in DSL deployments
[19:36:26] <venaas> next draft will address authentication in dhcpv6
[19:37:16] <venaas> Sam: on eap. who are the end-points
[19:37:45] <john.zhao> where to find the presentation just presented by Mark? This seems not part of the intarea-2.ppt.
[19:37:53] <venaas> Ric: hgw is an eap endpoint in typical deployments
[19:38:26] --- UlrichHerberg has left
[19:38:46] <venaas> Sam: asking if endpoints are always hgw (sending dhc discover) and dhc server
[19:40:16] <venaas> think Mark is saying that is typical
[19:40:39] <venaas> sam: must be careful of using NAS because has particular meaning in EAP spec
[19:41:12] --- nm has left: Replaced by new connection
[19:41:12] --- nm has joined
[19:41:20] --- nm has left
[19:41:24] --- nm has joined
[19:41:48] <venaas> Ric: saying something about relay vs proxy...., server override etc
[19:42:21] <venaas> Ric: trying to clarify terms like relay and proxy
[19:44:08] <venaas> someone: asking something I didn't get
[19:44:30] <venaas> mark: explaining various ways of doing wholesale
[19:45:32] <venaas> Ric: more on wholesale...
[19:45:43] <venaas> Jari: presenting issues to think about
[19:45:51] --- yangwoo has joined
[19:46:18] <venaas> good to move away from PPPoE and can move CPE device to new locations
[19:46:31] <venaas> IETF spec instead of vendor specific good
[19:47:23] <venaas> potential solutions on l2 (ieee), pana, dhcp with chap/eap
[19:47:41] <venaas> dhcp drafts are in very early stages, needing significant work
[19:48:31] <venaas> cannot evalue solutions entirely on e2e behaviour. cpe vs hosts in the home, ability of network betw dslams. future developments like v6
[19:49:30] <venaas> securing dhcp transactions vs using dhcp for access control. what happens if manual config is possible
[19:50:00] <venaas> access to link vs beyond the link
[19:50:25] <venaas> dhcp-based solution not working with ipv6 slaac
[19:50:39] <venaas> server vs relay responding to messages
[19:51:00] <venaas> retransmission responsibility on client vs server side
[19:51:03] <venaas> chap vs eap
[19:51:33] <venaas> other issues from the list: mtu issues, offer vs ack, key binding, session ids
[19:51:49] <venaas> acceptable solution requirements
[19:53:17] --- Bill has left
[19:53:54] <venaas> must solve detailed tech issues. must not place requirements on hosts, must handle both v4 and v6, deal with backwards compatiblity issues and fit the state machine, must accurately describe limitations and applicability of the solution, must conform to existing dhcp rfcs
[19:54:06] <venaas> we will now have discussion
[19:54:20] <venaas> and next get sense of the room on the directions
[19:54:59] <venaas> dave hankins: false advertising. it's wrong that dhcp can take as muc as 1020
[19:55:52] <venaas> ric: seems he don't think it's a real issue
[19:56:24] --- simon.schuetz has joined
[19:58:11] <venaas> iljitch: saying that would require lots of changes to dhcp, changes are not easy to make, CPEs may need to be updated etc. it's horrible, terrible...
[19:58:28] <venaas> iljitch: please don't do this. don't give this to the dhcp people
[19:59:20] <venaas> Ric: any authentication on a CPE needs to be upgraded
[19:59:29] <venaas> ric: needs to change dhcp regardless
[19:59:33] <venaas> jari: not necessarily true
[20:00:09] <venaas> iljitch: how it won't work with various combinations of v4, v6, dhcp, slaac
[20:00:17] <venaas> jari: not doing this for slaac
[20:01:06] <venaas> iljitch: wants something working with both v4 and v6, not separetly
[20:02:09] <venaas> someone: 802.1x problem is tunneling or going beyond the first hop. sees a good case for dhcp auth
[20:02:33] <venaas> jari: thinks ieee has extensions for 802.1.x through switches
[20:03:01] <venaas> aboba: missed what he said
[20:03:19] <venaas> erik: hard to tie together authentication and address assignment
[20:03:53] <venaas> Ric: agrees need to do auth before assignment
[20:04:18] <venaas> Ric: who you are may determine what address you get
[20:05:01] <venaas> Ralph: agrees solution must do both v4 and v6. however they may not need to be done the same way
[20:05:24] <venaas> jari: agrees. just need to be some way
[20:05:28] <venaas> mark: agrees with Ralph
[20:05:51] <venaas> mark: doesn't know yet what part dhcpv6 will play
[20:06:55] <venaas> mark: how does ipv4 shouldn't dictate v6 architecture
[20:07:26] <venaas> mark: will explain at dslf next week how important v6 is
[20:07:45] <venaas> ralph: disagrees auth has to be done before assigment
[20:08:00] <venaas> ralph: says auth and assignment are independent
[20:08:34] <venaas> ted lemon: about mtu and 1500 byte packets. saying can't assume it works with all relay agents
[20:08:39] --- xiaohunhun has left
[20:09:41] <venaas> ted: curious to know why requirement from dslf was to use dhcp and not pana (he says he doesn't care but wants to know)
[20:10:41] <venaas> mark: consensus was for dhcp at the last dslf meeting. says pana has been presented a few times
[20:11:17] <venaas> Ric: pana would need to change all elements in the aggregation arch
[20:11:44] <venaas> Ric: dhcp auth is a small step
[20:12:19] <venaas> Aboba: is it possible to satisfy all of Jari's requirements with just chap and not a big draft
[20:13:09] <venaas> Ric: started with just chap, told by several that need to do eap
[20:13:54] <venaas> Sam: don't make same mistake as others have before. assume that people in the future need stronger auth. use eap, not a particular auth mech
[20:14:09] <venaas> sam: need to make sure have reasonable endpoints and know who are talking to
[20:14:28] <venaas> sam: assume that the security association may be used for other stuff
[20:14:36] <venaas> sam: so that don't need to start all over again soon
[20:15:24] --- yangwoo has left
[20:15:34] <venaas> fred templin: on fragmentation. he has a proposal on dhcp reassembly that could work if relay agent can't defragment
[20:17:29] --- simon.schuetz has left
[20:18:16] <venaas> some guy: about auth before assignment. impact on scaling in the nas, important in many cases. wants dhcp wg to work on it
[20:19:06] <venaas> some other guy: dhc is least path of resistance, but still the number of changes required are very significant
[20:19:54] <venaas> same guy: disagrees with Ralph, saying need auth before assignment
[20:20:19] <venaas> alper: shouldn't we understand requirements better, we are jumping the gun
[20:21:19] <venaas> some guy: would like to see a proper analysis
[20:21:40] <venaas> Ric: with pana needs something new to address l2 security. says many more issues
[20:21:47] <venaas> same guy: would like to see those issues
[20:22:33] <venaas> some guy: didn't get what he said
[20:22:51] <venaas> Jari: we don't have enough info on why dslf decided on this etc
[20:23:09] <venaas> Jari wants an initial sense of the room to have something to tell DSLF and get more discussion on list
[20:23:30] <venaas> humm if should NOT go forward with dhcp
[20:23:39] <venaas> some humms
[20:23:58] <venaas> then humm for SHOULD go forward. some humms again
[20:24:00] <venaas> no decision
[20:25:12] <venaas> asking for show of hands
[20:25:27] <venaas> roughly 50 says SHOULD NOT do dhcp, about 35 says SHOULD
[20:25:32] --- yoshi has left
[20:25:39] <venaas> done, meeting over
[20:25:43] --- venaas has left
[20:25:48] --- shinta has left
[20:25:51] --- nm has left
[20:26:08] --- shikob has left
[20:26:16] --- raj has left
[20:26:38] --- cpignata has left
[20:26:38] --- cpignata has joined
[20:27:56] --- john.zhao has left: Computer went to sleep
[20:33:56] --- ldondeti has left
[20:43:16] --- frodek has left
[20:45:40] --- trond has left: Disconnected
[20:46:12] --- dthaler has left