IETF
v6ops
v6ops@jabber.ietf.org
Thursday, 8 November 2012< ^ >
joel jaeggli has set the subject to: v6ops LIM 10/28
Room Configuration

GMT+0
[14:40:40] ebersman joins the room
[14:40:45] ebersman leaves the room
[14:41:15] nygren@mit.edu/barnowl leaves the room
[17:12:41] danyork joins the room
[17:46:35] joel jaeggli joins the room
[17:47:12] joel jaeggli has set the subject to: v6ops IETF 85 thursday 1300 EST
[17:51:34] sarikaya2012 joins the room
[17:56:55] jpc joins the room
[17:57:17] <danyork> joel jaeggli: Is the audio stream up for the room? I'm getting an error
[17:58:37] <joel jaeggli> should be let me check
[17:59:15] <joel jaeggli> yeah I think they're all restarting themselves forthe afternoon sessions
[17:59:15] <danyork> I'm using http://ietf85streaming.dnsalias.net/ietf/ietf857.m3u
[17:59:37] <joel jaeggli> http://nagasaki.bogus.com:8000/ gives you the mount point status
[18:00:21] <joel jaeggli> should be back now
[18:00:37] <joel jaeggli> yup all there
[18:00:43] SM joins the room
[18:00:45] <joel jaeggli> Note Well
Any submission to the IETF intended by the Contributor for publication as all or part of an IETF Internet-Draft or RFC and any statement made within the context of an IETF activity is considered an "IETF Contribution". Such statements include oral statements in IETF sessions, as well as written and electronic communications made at any time or place, which are addressed to:
• The IETF plenary session
• The IESG, or any member thereof on behalf of the IESG
• Any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices
• Any IETF working group or portion thereof
• Any Birds of a Feather (BOF) session
• The IAB or any member thereof on behalf of the IAB
• The RFC Editor or the Internet-Drafts function
All IETF Contributions are subject to the rules of RFC 5378 <http://www.ietf.org/rfc/rfc5378.txt> and RFC 3979 <http://www.ietf.org/rfc/rfc3979.txt> (updated by RFC 4879 <http://www.ietf.org/rfc/rfc4879.txt>).
Statements made outside of an IETF session, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not IETF Contributions in the context of this notice.
Please consult RFC 5378 <http://www.ietf.org/rfc/rfc5378.txt> and RFC 3979 <http://www.ietf.org/rfc/rfc3979.txt> for details.
A participant in any IETF activity is deemed to accept all IETF rules of process, as documented in Best Current Practices RFCs and IESG Statements.
A participant in any IETF activity acknowledges that written, audio and video records of meetings may be made and may be available to the public.
[18:01:02] <danyork> joel jaeggli: Got it... audio is working now
[18:01:09] <joel jaeggli> document status
[18:01:35] <joel jaeggli> three documents in ron's in basket
[18:01:52] <joel jaeggli> three in the rfc editor queue - one waintg for reference from 6 man
[18:02:15] aacosta joins the room
[18:02:18] <joel jaeggli> agenda
[18:02:27] <joel jaeggli> 11 doucments on our agenda
[18:02:37] <joel jaeggli> one doc from dhc that will be discussed here
[18:03:02] <joel jaeggli> agenda bash time -
[18:03:07] <joel jaeggli> frist presentation
[18:03:39] <joel jaeggli> 1. Sharing /64 3GPP Mobile Interface Subnet to a LAN <http://tools.ietf.org/html/draft-byrne-v6ops-64share>
9-Oct-12 , <draft-byrne-v6ops-64share>
[18:03:51] <joel jaeggli> http://tools.ietf.org/agenda/85/slides/slides-85-v6ops-3.pdf
[18:05:11] <joel jaeggli> dhcp-pd not soon /64 share today
[18:05:28] <joel jaeggli> slide change at the ue
[18:06:18] <joel jaeggli> slide - next steps
[18:07:06] <joel jaeggli> bechet s - what if you connect to wlan first?
[18:07:43] <joel jaeggli> lorenzo c - support this, people wil ldo it anyway
[18:08:00] <joel jaeggli> ue - only consumes one address.
[18:08:25] <joel jaeggli> only works because the upstream is a point-to-point -
[18:08:45] <joel jaeggli> cameron b - specificay scope to 3gppp
[18:09:16] <joel jaeggli> alex p - interoperability between two implementations.
[18:09:43] cgrundemann joins the room
[18:10:12] jpc leaves the room
[18:10:45] <joel jaeggli> what kind of document is this going to be
[18:11:02] <joel jaeggli> fred - it would be nice to obey the principle of conservation of documents.
[18:11:16] <joel jaeggli> get authros to talk to each other
[18:11:46] <joel jaeggli> jonne s - we think this is a good document, dhcp v6 works as well
[18:12:04] jpc joins the room
[18:12:10] <joel jaeggli> we don't think wan connectivity is a problem/requirement.
[18:12:29] <joel jaeggli> keith ? - I think this is way better than nat
[18:13:00] <joel jaeggli> short prefixes to customers helps but sometimes you need this.
[18:13:09] vincent.levigneron joins the room
[18:13:22] <joel jaeggli> eric kline - what happens when the 3gpp context goes away
[18:13:40] <joel jaeggli> cameron b - haven't tried it.
[18:14:08] <joel jaeggli> eric k - tightly coupling uplink with ra timing
[18:14:40] <joel jaeggli> bechet sak - is this a standard tethering case
[18:15:54] bz@jabber.org joins the room
[18:16:28] <joel jaeggli> jouni ? - if the interface is unnumbered of the 3gppp side this working.
[18:16:48] <joel jaeggli> cameran - this is pushback on work on nd proxy
[18:17:21] <joel jaeggli> alex p - other than 3gppp this also works. currently I have a /64
[18:17:26] ebersman joins the room
[18:18:45] <joel jaeggli> joel j - prefix size discussion be careful
[18:19:22] <joel jaeggli> lorenzo c - we all agree point to point interface and no ndp
[18:20:35] <joel jaeggli> suresh k - I have a question about nud, hop limit, I rely on the 3gpp docs for the details ...
[18:20:48] <joel jaeggli> this a normal tether case,
[18:22:22] <joel jaeggli> did yo uread draft beringer lla and can we drop the global address on the pppp link?
[18:22:33] <joel jaeggli> fred - taking a quick hum
[18:22:51] <joel jaeggli> several people want this as a working group draft
[18:23:03] <joel jaeggli> hum in favor (substantial)
[18:23:08] <joel jaeggli> hum opposed (none)
[18:23:15] <joel jaeggli> next preso
[18:23:18] <joel jaeggli> gang chen
[18:23:26] <joel jaeggli> http://tools.ietf.org/agenda/85/slides/slides-85-v6ops-8.pdf
[18:23:35] <joel jaeggli> 2. NAT64 Operational Experiences <http://tools.ietf.org/html/draft-ietf-v6ops-nat64-experience>
8-Aug-12 , <draft-ietf-v6ops-nat64-experience>
[18:23:46] <joel jaeggli> slide - motivations
[18:24:32] <joel jaeggli> slide - comments
[18:26:40] <joel jaeggli> slide - topics we covered
[18:27:02] <danyork> Or "Deployment Guidelines"
[18:27:13] <joel jaeggli> philip m - change to deplyoemnt considerations rather than operational consideration
[18:27:33] <joel jaeggli> slide status and next step
[18:28:35] <joel jaeggli> fred = you have another version coming - we'lltake comments on that andif it looks resvolved perahps take it to WGLC
[18:28:58] <joel jaeggli> next preso - http://tools.ietf.org/agenda/85/slides/slides-85-v6ops-9.pdf
[18:29:06] <joel jaeggli> 3. Enterprise IPv6 Deployment Guidelines <http://tools.ietf.org/html/draft-ietf-v6ops-enterprise-incremental-ipv6>
15-Sep-12 , <draft-ietf-v6ops-enterprise-incremental-ipv6>
[18:29:19] <joel jaeggli> lee howard presented
[18:29:34] <joel jaeggli> several reviews on the list
[18:29:57] <aacosta> starting lee howard. Enterprise IPv6 deplyment guidelines
[18:30:07] <joel jaeggli> several questions for the wg -
[18:30:18] <joel jaeggli> mtu size recomendations
[18:30:53] <joel jaeggli> bechet - 1500
[18:31:16] <joel jaeggli> fred t - can't necessarily if there two tunnels
[18:31:33] <joel jaeggli> fred b - I would be hesitant to set the mtu that low.
[18:32:00] <joel jaeggli> 2460 says that the minimum mtu
[18:32:15] <joel jaeggli> lorezo - I think it might be 3%
[18:32:27] <joel jaeggli> loss to bandwidth
[18:32:41] <joel jaeggli> lee h - hereing consensus
[18:33:25] <joel jaeggli> philip mathews - seems undesirable to have smaller mtu than v4
[18:33:55] <joel jaeggli> ?- tested found a lot of mss the resolved to 1280
[18:34:32] <joel jaeggli> eric kline - those large operators has a lot to do with fragments and less to do with mtu available.
[18:34:52] <joel jaeggli> philip what were the alternatives?
[18:34:56] dougm.work joins the room
[18:35:17] <joel jaeggli> lee h - enterprises interest to deplyo native?
[18:35:59] <joel jaeggli> lorenzo c- if you take out native the statement is meaningless
[18:36:49] <joel jaeggli> native is better than anything else
[18:37:03] becarpenter joins the room
[18:37:52] <joel jaeggli> paul r- already talking about transistion technologies, behoves us to discuss this first
[18:38:56] <joel jaeggli> dave t - audience is the enterprise, agree with lorenzo remove this statement entirely.
[18:40:07] <joel jaeggli> kieth m - I 'm trying to think of a reason why an enterprise would not deploy ipv6
[18:40:23] <joel jaeggli> question is when how and in what timeframe
[18:41:27] <joel jaeggli> alex p - mechanics of limitations?
[18:41:35] <joel jaeggli> that would preclude deploying it
[18:41:55] <joel jaeggli> slide - dual stack where you can tunnel where you must
[18:42:18] <joel jaeggli> alain - durant disagree with that statement.
[18:43:39] <joel jaeggli> fred b - be careful about the arguement here - then I can never turn off v4
[18:44:35] <joel jaeggli> instead of the class of statement, native connectivity has significant value.
[18:45:29] <joel jaeggli> kieth m - native support for v6 is better than any v6 transition,
[18:45:44] <aacosta> answer to keith regarding: " I 'm trying to think of a reason why an enterprise would not deploy ipv6". My answer is that they don't see profit on it (do not need to relay)
[18:45:57] <joel jaeggli> brian c - it's important not to frighten network operators
[18:46:54] <joel jaeggli> joel no reason to read document if you don't see the point
[18:47:10] <joel jaeggli> slide - prefix size for a site
[18:47:47] <joel jaeggli> you may want to allocate less than a /48
[18:49:04] <joel jaeggli> lorenzo - not clear what should is - reader should make his own conclusion. the strucuture of the rir assignment allows for this.
[18:49:57] fdupont joins the room
[18:50:11] <joel jaeggli> vicktor k - two levels to addressing to it vs internally
[18:51:11] <joel jaeggli> fred baker - rfc 3177 bumped on /48 and bis pulled that out.
[18:52:25] <danyork> This PI vs PA somewhat leads into Lee's next slide :-)
[18:52:43] <danyork> This PI vs PA *discussion* ...
[18:53:40] <joel jaeggli> fred -
[18:53:44] <joel jaeggli> joel -
[18:54:12] <joel jaeggli> tim c - disparte means seperate dicussions
[18:54:53] <joel jaeggli> slide - pi vs pa
[18:56:12] <joel jaeggli> considiering - questions about what category it fits into.
[18:57:15] <joel jaeggli> keith -
[18:57:32] <joel jaeggli> philp m -
[18:57:42] <joel jaeggli> do you want to multihome
[18:59:49] <joel jaeggli> - joel -
[19:00:09] <danyork> +1 to these comments about including something about PI more in the context of multihoming
[19:00:11] <joel jaeggli> if your netowrk needs certain properties -
[19:00:29] <joel jaeggli> eric vinky - a firm wti ha network team
[19:01:32] <joel jaeggli> victor k - these are considerations about the routing implications
[19:02:14] <joel jaeggli> bob hinden - not so bothered by the size issue
[19:03:39] <joel jaeggli> brian c - get closer to what you're presenting on the slides
[19:03:40] <joel jaeggli>
[19:03:52] <joel jaeggli> ?-
[19:04:23] <joel jaeggli> slide - use npt66?
[19:04:47] <joel jaeggli> fred - says it provides no security whatsoever
[19:05:08] <joel jaeggli> philip m - what I would propose that you do it?
[19:05:57] <joel jaeggli> fred - if you're going to say that you have to address that you need to address ilnp
[19:06:44] <joel jaeggli> lorenzo - my sense is that it's not widely deployed so you may have breakage.
[19:07:26] <joel jaeggli> kieth m - I have to concur
[19:08:16] <joel jaeggli> tim c - we might have similar practice as today.
[19:08:47] <joel jaeggli> strongly discourage that
[19:11:07] <joel jaeggli> tim c - npt66 use cases?
[19:11:39] <joel jaeggli> lee h - ? think I have my anser of no consensus
[19:11:50] <joel jaeggli> slide still to be written
[19:12:24] <joel jaeggli> lorenzo - impact on vrrpv3 using multiple ras a similar way
[19:13:00] <joel jaeggli> tim -c do we consider SeND dead?
[19:13:28] <joel jaeggli> kk - we have some text on vrrpv3
[19:14:32] <joel jaeggli> next preso - http://www.ietf.org/proceedings/85/slides/slides-85-v6ops-4.pdf
[19:14:41] <joel jaeggli> A V -
[19:14:46] <joel jaeggli> slide scope
[19:15:09] <joel jaeggli> fred - we're going to discuss both documents what we should do with them
[19:15:53] <joel jaeggli> we see 3316 is out of data and not very helpful to vnedors
[19:16:16] <danyork> joel jaeggli: If we want something relayed, just preface with "mic:"?
[19:16:16] danyork leaves the room
[19:16:16] danyork joins the room
[19:16:16] <danyork> test
[19:16:51] <joel jaeggli> sure
[19:17:06] <joel jaeggli> slide next steps
[19:17:08] aacosta leaves the room
[19:17:08] vincent.levigneron leaves the room
[19:17:08] jpc leaves the room
[19:17:08] bz@jabber.org leaves the room
[19:17:08] becarpenter leaves the room
[19:17:08] danyork leaves the room
[19:18:00] <joel jaeggli> ? -
[19:18:09] <joel jaeggli> sslide scope and motivation
[19:18:21] <joel jaeggli> eric kline -requirement 17
[19:18:29] <joel jaeggli> don't do dad?
[19:18:58] becarpenter joins the room
[19:19:21] <joel jaeggli> a v - the address is own by ue, it is assured by the architecture that nobody else uses the address
[19:20:04] aacosta joins the room
[19:20:04] <joel jaeggli> fred bring up other group
[19:20:06] Dan York joins the room
[19:20:07] <Dan York> test
[19:20:08] bz@jabber.org joins the room
[19:20:13] vincent.levigneron joins the room
[19:20:16] <joel jaeggli> http://www.ietf.org/proceedings/85/slides/slides-85-v6ops-7.pptx
[19:20:21] <joel jaeggli> yeah we see you
[19:20:37] <joel jaeggli> jouni k -
[19:20:44] jpc joins the room
[19:20:56] <Dan York> Thanks.. had to switch jabber servers. My connection to Jabber.org <http://Jabber.org> is down.
[19:21:17] <joel jaeggli> slide motivation
[19:23:04] <joel jaeggli> slide - what has been changed
[19:23:46] danyork joins the room
[19:25:37] <joel jaeggli> slides - new additions
[19:26:54] <joel jaeggli> slide next steps
[19:27:42] <joel jaeggli> ? - will this conform with 3gpp specs
[19:27:58] <joel jaeggli> joiuni - non-normative lnaguage.
[19:28:27] <joel jaeggli> what's in node requirements that's not needed in 3gppp
[19:28:30] <joel jaeggli> suresh k -
[19:28:41] <joel jaeggli> ? -
[19:29:28] <joel jaeggli> fred - let me have a little different discussion - try to figure out what v6ops wants to do in this area
[19:29:35] Dan York leaves the room
[19:29:42] <joel jaeggli> two sets of authors that belive this need t o be updated
[19:30:03] <joel jaeggli> bob −6man updated the node requirements
[19:30:21] <joel jaeggli> fred - hum do we agree that
[19:30:54] <joel jaeggli> 3316 needs to be updated?
[19:31:15] <joel jaeggli> hum (in favor) some (opposed) none
[19:31:29] <joel jaeggli> fred - do we want to have a working group document
[19:32:06] <joel jaeggli> lorenzo - doc 1 is a shopping list document 2 is a treatis on how you implment ipv6 on 3316.
[19:32:30] <joel jaeggli> they're not covering the same domain
[19:33:15] <joel jaeggli> joone - agree with lorenzo - different objectives so they need to be trated differently
[19:34:18] <joel jaeggli> fred thinking one my feet - lets talk about the first document
[19:34:45] <joel jaeggli> it's coing from a set of operators - do you find it useful in your environment?
[19:35:07] <joel jaeggli> eric k - how much of the first document would be left after the second document?
[19:36:22] <joel jaeggli> ? first author - requirements in one place for profile
[19:37:06] <joel jaeggli> I don't think the other doucmnet is a useful because they're less specific (different scope)
[19:37:39] <joel jaeggli> suresh k - so the operators draft, things that are useful in v6 networks
[19:38:32] <joel jaeggli> jonne s - the first one is operator requirments - 2nds one says this is how it should work . there is some confuson in the industry
[19:39:06] <joel jaeggli> if the operators can agree on something that would be inice, this is a snapshot today .
[19:39:36] <joel jaeggli> it might make sense to see what the needed features that are needed today -
[19:40:07] <joel jaeggli> if it's a 3gpp specific doucment it might be better if it were done in3gpp
[19:41:05] <joel jaeggli> jouni - with most of comments. first one goes beyond whats required from the current ietf or 3gpp specifications
[19:42:21] <joel jaeggli> ? - don't want a war between documents, should avoid overlap
[19:43:28] <joel jaeggli> jari a - my motivation, we need to keep our specifications up to date.
[19:44:21] <joel jaeggli> on the first doc - questions as to where it should be done - 3gppp transition mechnanisms where should be that work.
[19:44:36] <joel jaeggli> be done
[19:44:39] Benno Overeinder joins the room
[19:45:17] <joel jaeggli> bechet - both of them are called 3316 update.
[19:45:45] <joel jaeggli> alex - looked at implmetnations
[19:46:19] <joel jaeggli> still have to struggle alot practical examples as to how to make it work
[19:47:24] <joel jaeggli> gang chen - at first I agreed they're complmentary, I guess 3gpp they produced a technical report not a standard
[19:49:12] <joel jaeggli> lorenzo - need to harmonize with new host requirements
[19:49:53] <joel jaeggli> lets make a descion on the second one as a natural update of 3316.
[19:50:45] <joel jaeggli> if we come to consensus on that as update, then we take the first document and andd the chrome wheels and the spoiler
[19:51:20] <joel jaeggli> ?-
[19:51:31] tonyhain joins the room
[19:51:48] <joel jaeggli> transition tools requirements do not exist today in 3gppp
[19:52:40] <joel jaeggli> ?- resubmitt document as not setting into 3316s shoes (1st document)
[19:52:54] <joel jaeggli> sri -
[19:53:08] <joel jaeggli> fred - calling the question -
[19:53:23] <joel jaeggli> we wanted to update 3316
[19:53:49] <joel jaeggli> is this document (2nd) as 3316 update? hum(some) none opposed.
[19:54:37] aacosta leaves the room: Machine going to sleep
[19:54:37] <joel jaeggli> and yes we'll take you up on the offer for the resubmission of the 1st document with a new title.
[19:54:37] Benno Overeinder leaves the room
[19:54:40] fdupont leaves the room: Computer went to sleep
[19:55:16] dougm.work leaves the room
[19:59:37] bz@jabber.org leaves the room
[20:00:09] becarpenter leaves the room
[20:00:11] becarpenter joins the room
[20:06:09] <danyork> joel jaeggli: Audio stream dropped out again
[20:07:14] <danyork> Hmmm... yes, http://nagasaki.bogus.com:8000/status.xsl shows no streams up
[20:09:51] bz@jabber.org joins the room
[20:10:26] <danyork> Stream back up
[20:11:51] aacosta joins the room
[20:13:43] <danyork> what are the slides for this?
[20:14:00] <danyork> I'm not seeing any on Materials or Agenda page that line up with draft
[20:14:18] <cgrundemann> 6. A Larger Loopback Prefix for IPv6 <http://tools.ietf.org/html/draft-smith-v6ops-larger-ipv6-loopback-prefix>
17-Aug-12 , <draft-smith-v6ops-larger-ipv6-loopback-prefix>
IPv6 Transition Technologies: Selection using DHCP/DHCPv6 <https://tools.ietf.org/agenda/85/slides/slides-85-v6ops-1.pdf>
[20:14:54] <cgrundemann> sorry - wrong slides
[20:15:10] <danyork> Right.
[20:15:22] <danyork> I guess the slides are now moot. :-)
[20:15:51] <cgrundemann> yeah - they were simple
[20:17:23] <joel jaeggli> brian - 1:: vrigin space
[20:17:44] <joel jaeggli> fred - d owe feel that a larger loopback space is useful ?
[20:18:14] <joel jaeggli> hum - some in favor, some opposed
[20:18:28] <joel jaeggli> next preso - philip mathews -
[20:19:08] <joel jaeggli> 7. Design Guidelines for IPv6 Networks <http://tools.ietf.org/html/draft-matthews-v6ops-design-guidelines>
22-Oct-12 , <draft-matthews-v6ops-design-guidelines>
[20:19:24] <joel jaeggli> http://www.ietf.org/proceedings/85/slides/slides-85-v6ops-6.ppt
[20:21:46] <joel jaeggli> slide mix ipv6 and ipv4
[20:22:03] <joel jaeggli> document is pretty much a rewirte
[20:23:53] Benno Overeinder joins the room
[20:24:03] <tonyhain> Option A is braindead !!!
[20:25:47] <joel jaeggli> slide lla next hop for static route
[20:25:48] Wes George joins the room
[20:26:17] <joel jaeggli> fred- michale behringers lla on draft?
[20:26:23] <joel jaeggli> philip m - I have
[20:26:33] <joel jaeggli> slide - one or two ebgp sessions
[20:29:25] <joel jaeggli> ? - if you peer over ipv6 some implmentations get this right.
[20:30:20] <joel jaeggli> rudigger volk - lesser fate sharing in option b
[20:30:57] <joel jaeggli> ? bt -
[20:31:20] <joel jaeggli> amsix considering using option a
[20:31:50] <joel jaeggli> ?- uses globla ipv6 next hops?
[20:32:51] <joel jaeggli> paragraph for peering over ipv6
[20:33:43] <joel jaeggli> new topic - seperate rrs for v4 and v6
[20:34:53] equinox joins the room
[20:34:56] cerezojp joins the room
[20:34:58] <joel jaeggli> joel - I use the same rr(s)
[20:35:26] <equinox> the RFC for BGP IPv4 routes with IPv6 nexthops is 5549 in case no one pasted that yet
[20:36:15] <joel jaeggli> I've deployed twice with different one's but only for scalabiltiy reasons
[20:36:28] <joel jaeggli> ?-
[20:37:40] <joel jaeggli> gunter v - as a pro for seperate is avoid v4 breaking v6 stuff
[20:38:15] <joel jaeggli> lorenzo - option a has the advantage that the ops guys know where to look.
[20:38:48] <joel jaeggli> fred - we're pretyt close.
[20:38:56] <joel jaeggli> kk - I like the document
[20:39:09] <joel jaeggli> how far do you want to take this?
[20:40:22] <joel jaeggli> philip - would like to look at vpns, opsf vs isis
[20:41:37] <joel jaeggli> tim c - will try again on address plan after this
[20:42:13] <joel jaeggli> fred - wg yes or no(hum) some in favor none opposed
[20:42:20] <joel jaeggli> resubmitt as draft ietf.
[20:42:55] <joel jaeggli> 8. IPv6 Operational Guidelines for Datacenters <http://tools.ietf.org/html/draft-lopez-v6ops-dc-ipv6>
20-Oct-12 , <draft-lopez-v6ops-dc-ipv6>
[20:43:13] <joel jaeggli> http://www.ietf.org/proceedings/85/slides/slides-85-v6ops-5.pptx
[20:44:32] <joel jaeggli> brief history
[20:45:01] <joel jaeggli> slide what's new in version 3
[20:47:06] <joel jaeggli> slide - coming 04
[20:48:57] <joel jaeggli> fred - comments ?
[20:49:13] <joel jaeggli> let me ask this working group a question?
[20:49:23] <joel jaeggli> do you like the direction?
[20:49:26] <danyork> Yes
[20:49:31] <danyork> Hum: yes
[20:49:59] <joel jaeggli> none in room for take it up
[20:50:08] <joel jaeggli> some for bake longer
[20:50:17] Benno Overeinder leaves the room
[20:50:52] <joel jaeggli> phlip mathews - algin dc and enterprise message?
[20:51:18] <joel jaeggli> 9. IPv6 Transition Technologies Selection using DHCP/DHCPv6 <http://tools.ietf.org/html/draft-yang-v6ops-ipv6tran-select>
15-Oct-12 , <draft-yang-v6ops-ipv6tran-select>
[20:51:46] <joel jaeggli> http://www.ietf.org/proceedings/85/slides/slides-85-v6ops-1.pptx
[20:52:04] <joel jaeggli> slide problem description
[20:54:25] danwing joins the room
[20:54:39] <joel jaeggli> slide problem description 3
[20:59:19] <Wes George> mic: wearing my sunset4 co-chair hat - this is a bigger issue than just around which IPv6 transition technology to choose. We've been discussing in sunset4 the need for a means to signal preference between IPv4 and IPv6 under the assumption that there will be multiple permutations of networks: some that offer IPv4 with or without NAT, IPv6, IPv6 with NAT64 and DNS64, DNS servers that only listen on IPv4, only on IPv6, or both such that happy eyeballs by itself may not make the right decision.
I'd rather see us solve this problem of conveying preference based on the network's capabilities and offered translation services once, rather than multiple times for multiple use cases.
[20:59:56] <joel jaeggli> slide further questions
[21:00:25] sarikaya2012 leaves the room
[21:00:32] <Wes George> joel are you jabber proxying?
[21:02:42] <tonyhain> the focus has been completely myopic and biased toward lethargic network operators that want to tell the device what to do. there needs to be input from the applications side as well that balances the reality so that networks don't preclude deployment of applications that people actually use.
[21:03:50] <joel jaeggli> I can
[21:04:04] <joel jaeggli> I read yours
[21:04:09] <joel jaeggli> i'll
[21:04:19] <tonyhain> As for the topic of focusing on dhcp, the problem statement appears to be broken in that it requires adding a new option to resolve the problem of inconsistency in current implementations.
[21:05:37] <joel jaeggli> tim c - tehe section of dslite out of scope - great to say what you're say
[21:05:54] Suz joins the room
[21:06:30] <joel jaeggli> philip m - we've identified that there is a gap -
[21:06:43] <joel jaeggli> fred - fair to say there's limited support for this?
[21:08:21] <becarpenter> technology interrupt while ppt is repaired
[21:08:44] <cgrundemann> next preso
[21:08:46] <cgrundemann> 10. Why Operators Filter Fragments and What It Implies <http://tools.ietf.org/html/draft-taylor-v6ops-fragdrop>
15-Oct-12 , <draft-taylor-v6ops-fragdrop>
Why Operators Filter Fragments and What It Implies <https://tools.ietf.org/agenda/85/slides/slides-85-v6ops-2.pdf>
[21:09:11] timc joins the room
[21:09:13] <cgrundemann> slide: the percieved problem
[21:11:19] <cgrundemann> slide: reactions on the list
[21:11:53] BillC joins the room
[21:12:20] <cgrundemann> slide: reactions on the list (cont'd)
[21:12:37] <cgrundemann> slide 5: reactions on the list (cont'd)
[21:13:20] <cgrundemann> slide 6: summing up
[21:13:48] <cgrundemann> "is fragment dropping justified?"
[21:14:15] <cgrundemann> "if so, when and when not?"
[21:14:27] <cgrundemann> discussion open
[21:16:16] <cgrundemann> Joel J: fragment dropping is a different issue than breaking PMTU, goal is to document practice not define rational
[21:17:08] <cgrundemann> Ron B: document practice, maybe the why, maybe if the why's are valid
[21:18:05] <cgrundemann> Ron B: documenting this tells folks that fragments are less reliable
[21:18:30] <cgrundemann> Brian C: no data in document, having that would be good
[21:18:57] <cgrundemann> RIPE study is quoted - 10% of paths drop fragments
[21:19:15] <cgrundemann> Brian C: could use more specific/granular data
[21:19:49] <tonyhain> This is a time sensitive issue in that 15 years from now what constitutes a fragment is likely to be different. There is no justification for dropping them in IPv6. In IPv4 overlaps were valid, so there was an attack vector to protect against. THat is no longer true, so we shoudl document why the concept needs to go away.
[21:21:36] danyork leaves the room
[21:22:42] <cgrundemann> Lorenzo: we filter fragments and have good reasons / we can; document problem, document reasons, document advice / advice won't work because we won't agree / reasons is out / as an ops group we have a duty to report what happens to others
[21:23:29] <cgrundemann> Ron B: more information would be good
[21:25:11] <cgrundemann> ___: DNS impacts? documenting the problem is good but looking for consensus on recomendations is better / can we solve the ops issues
[21:26:34] <cgrundemann> Joel J: educational problem
[21:27:00] <cgrundemann> Tony, do you want your comment relayed?
[21:27:09] <tonyhain> that might be helpful
[21:28:31] <cgrundemann> igor: we fragment, we have reasons / lets document this with basic recomendations to break less
[21:28:55] <cgrundemann> _____: what about ipv4?
[21:29:00] <cgrundemann> igor: yes.
[21:29:49] <cgrundemann> joel j: new assumptions in ipv6 - pmtu must work, fragments should work
[21:29:51] Chris Donley joins the room
[21:31:06] <tonyhain> thanks
[21:31:22] <cgrundemann> =)
[21:31:39] <cgrundemann> philip m: can those that filter tell us why?
[21:32:10] <cgrundemann> igor g: this is a security issue, details would open attack
[21:33:08] <cgrundemann> Eric?: fragments are also dropped in core
[21:33:32] <cgrundemann> closing discussion
[21:34:18] <joel jaeggli> next presentation
[21:34:32] <joel jaeggli> Operational Issues with Tunnel Maximum Transmission Unit (MTU) <http://tools.ietf.org/html/draft-generic-v6ops-tunmtu>
18-Oct-12 , <draft-generic-v6ops-tunmtu>
[21:34:45] <joel jaeggli> http://www.ietf.org/proceedings/85/slides/slides-85-v6ops-0.pptx
[21:36:25] Suz leaves the room
[21:37:58] <joel jaeggli> slide other considerations
[21:38:25] <joel jaeggli> slide - problem statement
[21:40:11] woolf joins the room
[21:41:51] <joel jaeggli> ron - if you had a signaling mechanism you could use it to jsut send smaller packets
[21:42:13] <joel jaeggli> philips mathews - need a sense of how common this problem is.
[21:42:58] <joel jaeggli> fred - we know a number of firewalls that does this intention or inadvertuly filter path mtu.
[21:44:16] <joel jaeggli> fred t - we don't control the whol path so we can't wire up the mtu.
[21:44:59] <joel jaeggli> next presentation -
[21:45:02] <joel jaeggli> from dhcp
[21:45:08] <joel jaeggli> er dhc wg
[21:45:09] <joel jaeggli> http://www.ietf.org/proceedings/85/slides/slides-85-v6ops-12.pdf
[21:47:40] <joel jaeggli> eric kline - I think this is a good idea
[21:49:27] <joel jaeggli> eric vynke - good thing to do, dhcp is not the right thing.
[21:49:50] cerezojp leaves the room
[21:50:21] jpc leaves the room
[21:50:30] <joel jaeggli> seng - it's frustrsting we bring up this issue in 6man -we have dhcp as a choice, 6man preffered it.
[21:50:46] <tonyhain> In general I agree with Eric Kline, but I would prefer to allow the host to at least inform about its preference as to what gets registered in DNS and with the firewall config, because it may only want to allow inbound on one address, which the network can't figure out.
[21:51:16] <joel jaeggli> lorenzo c - as a matter of advice, it's in your interest to have consensus that.
[21:51:49] <joel jaeggli> I agree with eric that doing this for security purposes is silly
[21:52:05] <joel jaeggli> the operators will tell you if dhcpv6 is right protocol
[21:53:13] <joel jaeggli> tim c - you can also use savi
[21:53:44] <joel jaeggli> fred - me speaking as an individual - wheter therre should be registration
[21:54:39] <joel jaeggli> the protocol to do that is (i asume syslog)
[21:54:57] <joel jaeggli> etiher dhcpv6 or ipfix
[21:55:56] <joel jaeggli> eric kline - creating an auditable process
[21:56:49] <joel jaeggli> lee howard - draft-ietf-dhc-addr-registration
[21:57:24] Chris Donley leaves the room
[21:57:42] danwing leaves the room
[21:58:10] danwing joins the room
[21:59:28] SM leaves the room
[22:00:47] <joel jaeggli> tim c - we use snmp
[22:02:23] <joel jaeggli> lorenzo - there is a use case
[22:03:13] <joel jaeggli> you can scrape neighbor table - wouldn't be nice that we had a way to do that that was more reliable.
[22:05:39] ebersman leaves the room
[22:05:39] aacosta leaves the room: offline
[22:05:51] vincent.levigneron leaves the room
[22:07:44] cgrundemann leaves the room
[22:07:51] timc leaves the room
[22:08:14] joel jaeggli leaves the room
[22:09:25] BillC leaves the room
[22:09:57] Wes George leaves the room
[22:10:47] joel jaeggli joins the room
[22:12:16] woolf leaves the room
[22:16:46] danyork joins the room
[22:20:54] becarpenter leaves the room
[22:22:53] danwing leaves the room
[22:26:56] ebersman joins the room
[22:27:06] ebersman leaves the room
[22:28:30] BillC joins the room
[22:28:37] becarpenter joins the room
[22:29:36] timc joins the room
[22:31:42] tonyhain leaves the room
[22:35:25] bz@jabber.org leaves the room
[22:35:55] timc leaves the room
[22:35:58] becarpenter leaves the room: offline
[22:43:27] bz@jabber.org joins the room
[22:48:35] woolf joins the room
[22:58:03] bz@jabber.org leaves the room
[23:01:21] joel jaeggli leaves the room
[23:02:19] joel jaeggli joins the room
[23:07:56] BillC leaves the room
[23:08:14] joel jaeggli leaves the room
[23:09:13] joel jaeggli joins the room
[23:13:30] joel jaeggli leaves the room
[23:13:49] joel jaeggli joins the room
[23:17:50] vincent.levigneron joins the room
[23:24:30] joel jaeggli leaves the room
[23:34:03] equinox leaves the room: Machine going to sleep
Powered by ejabberd Powered by Erlang Valid XHTML 1.0 Transitional Valid CSS!