[12:01:08] --- lars has joined
[12:25:50] --- briansmith has joined
[12:46:47] --- jeffa has joined
[13:01:01] --- dthaler has joined
[13:01:23] --- yushun has joined
[13:01:29] --- momose has joined
[13:01:30] --- shep has joined
[13:01:33] <dthaler> area status update
[13:01:55] <dthaler> er doing agenda bashing now
[13:02:05] --- iljitsch has joined
[13:02:20] --- dudi has joined
[13:03:03] <dthaler> agenda and status slides at http://www3.ietf.org/proceedings/06jul/slides/intarea-0.ppt
[13:03:33] <dthaler> now on slide 6
[13:03:38] <dthaler> no bofs this ietf
[13:04:09] <dthaler> HOKEY (thurs) in transport area is relevant, and NEA (Tues) in security area is relevant
[13:04:36] <dthaler> anycast bof declined but discussion occurred in opsarea meeting
[13:04:40] --- petrescu7 has joined
[13:04:55] <dthaler> new WGs: ANCP (formerly L2CP)
[13:05:00] --- nm has joined
[13:05:14] <dthaler> 16ng (IP over 802.16), technically challenging, help appreciated
[13:05:55] <dthaler> closed WG: IPoIB (ip over infiniband)
[13:06:16] <dthaler> IPoIB finished tasks except MIBs which were dropped
[13:06:51] --- weddy has joined
[13:07:01] <dthaler> WGs recharters or in progress: MIPSHOP, MIP4, MIP6, NEMO, SHIM6
[13:07:36] <dthaler> also HIP, 6LOWPAN, IPoDVB
[13:08:12] <dthaler> HIP will recharter for a few small items and then close and let the IRTF HIP RG continue
[13:08:47] <dthaler> 6LOWPAN has lots of stuff they want to add to charter, but only 2 now and a year behind :)
[13:08:57] <shep> his slide says "IRTF HIP WG" and he said "IRTF HIP Working Group", but it is in fact a HIP RG (research group) in the IRTF.
[13:09:06] --- lars has left
[13:09:15] <dthaler> right, I put RG in the jabber notes on purpose :)
[13:09:41] <dthaler> slide 10
[13:10:05] <dthaler> general status of PWE3, PANA, NETLMM
[13:10:17] --- washad has joined
[13:10:31] --- mallman has joined
[13:11:13] <dthaler> PANA is trying to simplify
[13:12:02] <petrescu7> Isn't HIP a WG too? http://www.ietf.org/html.charters/hip-charter.html
[13:12:19] <dthaler> yes that's what the status update was about
[13:12:34] <dthaler> there's both a WG and a RG group. the WG is close to being done but the RG will continue
[13:12:51] <dthaler> slide 11: going over area document status now
[13:13:20] --- cpignata has joined
[13:13:30] <dthaler> 2 in rfc editors queue, 2 being discussed today
[13:13:55] <dthaler> and KHI draft will go ahead as Experimental RFC
[13:14:18] <dthaler> Dave Meyer now coming up to do slide 12
[13:14:24] <petrescu7> who on mike?
[13:14:29] <dthaler> Dave Meyer
[13:14:35] --- marz has joined
[13:15:13] <dthaler> IAB is in planning stages on having a routing and address workshop. Discussion on rtgarea mailing list
[13:15:21] --- lars has joined
[13:15:29] <dthaler> https://www1.ietf.org/mailman/listinfo/routing-discussion to join
[13:15:43] <dthaler> goal is just requirements gathering, not solution discussion
[13:16:26] <petrescu7> switching computers.
[13:16:33] <dthaler> now up Marcelo Bagnulo on 3484 update: http://www3.ietf.org/proceedings/06jul/slides/intarea-4.pdf
[13:16:53] --- nm has left: Replaced by new connection
[13:16:53] --- nm has joined
[13:16:53] --- nm has left
[13:17:18] <dthaler> issues with ULA not handled
[13:17:43] <dthaler> e.g., prefer ULAs or private IPv4 addrs?
[13:18:02] <dthaler> additional tools for policy table handling, some drafts by arifumi
[13:18:20] <dthaler> handling of unreachable source addresses
[13:18:34] <petrescu7> slide: Identigied issues
[13:18:37] <petrescu7> slide: scenario
[13:18:51] <petrescu7> slide: limitaitons of rfc3484
[13:19:05] <dthaler> (can you jabber scribe when I present?)
[13:19:20] <petrescu7> I'll try.
[13:19:21] <dthaler> (they didn't get any volunteers at the beginning)
[13:19:27] <petrescu7> I saw that.
[13:19:50] <petrescu7> (do you mind me sending slide:?)
[13:20:06] <dthaler> slide 6: 3484 provides an ordered list of dest addrs, but just one source
[13:20:32] <dthaler> slide 7
[13:20:58] <dthaler> update source addr sel to take into account unreachable src/dest pairs
[13:21:47] <petrescu7> DT: I definitely think 2nd bullet worht working on, not pref for 1st.
[13:21:52] <petrescu7> Pekka Savola PS
[13:22:03] <dthaler> marcelo asks whether this would be interesting work
[13:22:04] <petrescu7> PS: the 2nds bullet we should be doing. Not sure about 1st.
[13:22:17] <dthaler> first bullet is guidance to apps, second bullet is updating source addr sel as noted above
[13:23:17] <dthaler> guidance would be like retrying with another source address, like doc says now app should retry with multiple dest addresses returned
[13:23:26] <petrescu7> MB: 2nd part is really the complez one. (MB: Marcelo Bagnulo)
[13:23:52] <dthaler> Tim Chown: there's other problems with 3484 that need to be solved too, but maybe it's quicker to just do the other ones
[13:23:59] <dthaler> ...and do this later
[13:24:16] <dthaler> Stig Venaas: quite complicated for applications
[13:24:32] <dthaler> ...should TCP do this or app?
[13:25:16] --- gurtov has joined
[13:25:24] <petrescu7> MB: when IP layer selects, either IP layer iterates and sees decision, so that you achieve comm, or at least has some info or idea that is lkely to be working.
[13:25:30] <petrescu7> SV: UDP can be hard to know which layer.
[13:25:41] <petrescu7> MB: yes, hard, that's why asking here.
[13:26:22] <petrescu7> ... Pasi: Windows Vista includes v4 or v6 local addresses, tries to figure out which combination makes sense. Similar idea here, app, not limited to src addr selection.
[13:26:28] <petrescu7> MB: also hear "connect by name"
[13:26:43] <petrescu7> DT: confirm both true, any time a platform provides API...
[13:26:57] <petrescu7> something as app, connect by a name, or specs a list, name would be more appropriated.
[13:27:08] --- weiler has joined
[13:27:09] <petrescu7> ... it is really complex for app developpers to do that right,
[13:27:22] <petrescu7> diff is whether small number of places, or large number of places.
[13:27:34] <petrescu7> MB: if connect by name is sufficient, and everybody solves problem then happy.
[13:27:54] <petrescu7> DT: communities do by name, other non-IETF communities..
[13:28:03] <petrescu7> HS Hesham Soliman
[13:28:08] <petrescu7> HS: I agree problem to be solved.
[13:28:15] <petrescu7> HS: multiple combinations possible.
[13:28:26] <petrescu7> HS: sense of what priority is the problem to solve first?
[13:28:30] <dthaler> (e.g., the web services world uses URLs in protocols like SOAP)
[13:29:04] <petrescu7> MB: how important to chnange that rfc (insert no) is to change now here?
[13:29:46] <petrescu7> HS agrees, : did you look at hints for ND for src addrs selection?
[13:29:54] <petrescu7> HS: prefixes, preferred lifetime goes to 0.
[13:30:29] <petrescu7> Stig Venaas: conect by name good for TCP but for UDP much more difficult.
[13:30:34] <dthaler> yep
[13:30:34] <petrescu7> Bob Hinden
[13:31:24] <petrescu7> BH: open to this being extended but think real hard doing it, based on demonstrated stuff, hoping vendor impl experience.
[13:31:50] <petrescu7> BH: should work better than default rules...
[13:32:08] <petrescu7> Mohsen Souissi I think
[13:32:27] <petrescu7> MS: best pair of locators, maybe solved by shim6
[13:32:57] <petrescu7> MB: shim6 requires both ends updated. While here, if you have 2 prefixes, establisheing comm qith other end then you need entire Internet to be aware.
[13:33:09] <dthaler> shim6 doesn't do anything at initial connect time
[13:33:43] <petrescu7> JA: interesting work, but make sure not too much experimental, ok with you?
[13:34:03] <petrescu7> MB: encourages any kind of feedback
[13:34:57] <dthaler> Marcelo Bagnulo on hash functions in CGA
[13:35:18] <dthaler> http://www3.ietf.org/proceedings/06jul/slides/intarea-1.pdf
[13:35:32] <dthaler> now on slide 5
[13:35:59] <dthaler> SHA1 is hard coded in CGA spec, but some recent attacks against SHA1
[13:36:17] <dthaler> current apps are not affected by the attacks
[13:36:34] <dthaler> but may be future attacks which do affect
[13:36:48] <dthaler> slide 6: encode hash function algorithm?
[13:37:06] <dthaler> propose using sec field for both current sec info and hash function
[13:37:22] <dthaler> reserve 3 values as currently defined
[13:37:37] <dthaler> encoding it anywhere else would result in weaker CGAs
[13:38:15] <dthaler> 000,001,010 as currently used, but reserve higher sec values for possible algorithm change in future
[13:38:23] <petrescu7> Iljitsch: why will it be necessary to know the hash function by looking at the address iid? There needs to be a lot info ...
[13:39:01] <dthaler> MB: if you don't encode it, an attacker can use SHA1 in place of the stronger one to attack
[13:39:32] <petrescu7> I think Donald Eastlake raised the question
[13:39:35] <dthaler> yes
[13:39:48] <dthaler> DE: if they can do that why can't they change the bits in the packet?
[13:40:47] <dthaler> PS: interesting but is this the right time for it? can wait for 5 years even
[13:41:36] <dthaler> MB: because in 5 years a higher sec value might already be used in some places
[13:42:20] <dthaler> Gabriel Montenegro
[13:42:22] <petrescu7> Gabriel Montenegro: support for agility of the hash function
[13:42:34] <petrescu7> GM: agility about the public key techno being used.
[13:42:40] <petrescu7> GM: hardcoded RSA in SEND
[13:42:48] <petrescu7> GM: particular ECC interesting for some apps.
[13:42:57] <petrescu7> GM: for some appsECC is the best
[13:43:04] <petrescu7> GM: agility? legibility?
[13:44:03] <petrescu7> Shepherd, Tim
[13:44:13] <petrescu7> TS: not same concern about the down...rade attack.
[13:44:39] <petrescu7> TS: if the attacks on SHA-1 get better and SHA-1 dont protect us, and we dont have this ... preserve... values, then we're stuck.
[13:44:46] <petrescu7> TS: attacker could always downgrade.
[13:44:57] <petrescu7> TS: this is the only thing now needed.
[13:45:16] <petrescu7> MB: still I'd like to understand about the Gabriel's point.
[13:45:44] <petrescu7> GM: motivations different. SHA-1 vs RSA.
[13:46:55] <petrescu7> L. Dondetti: secbits are used for figure out the length of modifier?
[13:47:04] <petrescu7> MB: no, used to determine the no of zeros...
[13:47:22] <petrescu7> LD: in that case aren't we forcing sha-1 go with a particular length?
[13:47:33] <petrescu7> MB: no because sec value and the hash function
[13:47:48] <petrescu7> LD: ok so
[13:48:00] <dthaler> changes the computation to be a lookup table
[13:48:08] <dthaler> Ron Bonica http://www3.ietf.org/proceedings/06jul/slides/intarea-5.ppt
[13:49:11] <dthaler> slide 3
[13:49:23] <dthaler> experimental or PS?
[13:49:41] <dthaler> this is draft-bonica-internet-icmp
[13:50:07] <dthaler> general feedback is needs improvement before PS, impacts draft-ietf-mpls-icmp and deployments
[13:50:43] <dthaler> implementations already exist for IPv6
[13:51:08] --- mo7sen has joined
[13:51:16] <petrescu7> IPv6 and MPLS
[13:51:18] <dthaler> slide 4 "not good for deployment to happen without IETF spec"
[13:51:35] --- weddy has left
[13:51:56] --- venaas has joined
[13:52:04] <petrescu7> Joe Touch
[13:52:12] <dthaler> (i'm up next so signing off jabber...)
[13:52:20] <petrescu7> slides please
[13:52:34] <dthaler> my slides are at http://www3.ietf.org/proceedings/06jul/slides/intarea-2.ppt
[13:52:35] <petrescu7> JT: IPv6 and IPv4 ...
[13:52:54] <petrescu7> JT: IETF shouldn't bother w/ this if there's no IP layer motivation for this
[13:52:55] --- dthaler has left
[13:53:26] <petrescu7> JT: sole reason v4 sol and delving v6 seems to be ... protocols was not designed to support. Not sure why IETF should worry
[13:53:32] <petrescu7> reopening a debate
[13:53:42] <petrescu7> JT: there are implementations for MPLS traceroute...
[13:53:57] <petrescu7> Mark Townsley: we've decided to do it for IPv4, should we also do it for IPv6?
[13:54:12] <petrescu7> JT: primary motivation for IPv6 it's because there's a motviation...
[13:54:55] <petrescu7> JT: if you'd say in this example, would be useful IPv6 as a separated item? Sure. But if conclusion is IPv6 version for PS I'm against.
[13:55:04] <petrescu7> Ron Bonica: let's focus on Atlas.
[13:55:08] <petrescu7> JT: it's experimental.
[13:55:10] <petrescu7> Pekka Savola
[13:55:40] <petrescu7> PS: Internet layer implication here, the amount of data ICMP implementations sends for their stuff when not related to MPLS, in other direction how much data the receivers can expect to have in the icmp error messages.
[13:56:01] <petrescu7> PS: from this perspecticve I'd support Proposed Standard for this., We can't to PS if not support IPv6
[13:56:04] <petrescu7> JA: in same document?
[13:56:15] --- rjaksa has joined
[13:56:20] <petrescu7> PS: problem space is suffucielently similar, enough to do in same doucment, just duplication of text.
[13:56:41] <petrescu7> Rob Austeni: not oppinion whether we do work per se, but ICMPv4 and v6 should be as close as possible. I've probably spend much time on SIIT.
[13:56:51] <petrescu7> Austein
[13:57:30] <petrescu7> BH: driving this will show up in other SDOs (3gpp). There's a lot of stuff IP might be underneath. Wimax stuff,,,... will show up otherw places... not sure it's a good idea.
[13:57:37] <petrescu7> BH: a special case for MPLS may be bad idea.
[13:57:45] <petrescu7> JA: separation ... we discuss.
[13:58:04] <petrescu7> BH: lot of other stuff, switches underneath... mechanisms like this help figure out what's going on/
[13:58:12] --- idli has joined
[13:58:15] <petrescu7> BH: maybe we should think about a protocol doing this kind of stuff.
[13:58:40] <petrescu7> MT: we do have a separation... MPLS object, labels advance elsewhere. Here we decide create that generic thin.g
[13:58:50] <petrescu7> BH: there should be a same way of doing it.
[13:59:25] <petrescu7> MT: v4 and v6 should be as close toghether here (I've heard)
[13:59:52] <petrescu7> MT: hopefully the MPLS label object is advancing in the mpls WG could plug in whatever we do in v4 with what we do in v6.
[14:00:06] <petrescu7> MT: if we have it for v4, we should have it for v6....
[14:00:16] <petrescu7> JA: it was clear that we want to do the same thing v4 vs v6
[14:00:30] <petrescu7> JA: what's less clear whether it's justified PS status. I've heard both sides.
[14:00:40] <petrescu7> JA: questions :
[14:00:57] <petrescu7> JA: dowe feel this should go Stds Track ? and then Experimental
[14:01:08] <petrescu7> JA: who feels this should be Stds Trck hum
[14:01:11] <petrescu7> humms
[14:01:15] <petrescu7> JA: I've heard smthing
[14:01:20] <petrescu7> JA: not on the stds track?
[14:01:24] <petrescu7> JA: heard nothing
[14:01:44] <petrescu7> JA: preference for Stds Track, not a whole lot of people with strong oppinion.
[14:01:58] <petrescu7> RB: conclusion to add a section on v6> ? another section on v6?
[14:02:07] <petrescu7> JA: add a section, and we'll talk to yopu later.
[14:02:13] <petrescu7> RB: sounds good thanks
[14:02:21] <petrescu7> Dave Thaler presents http://www3.ietf.org/proceedings/06jul/slides/intarea-2.ppt
[14:03:31] <petrescu7> slide: A Comparison of Mobility-Related Protocols: MIP6, SHIM6 and MHIP draft-thaler-mobility-comparison-01.txt
[14:03:39] <petrescu7> slide: Goal of this presentation
[14:04:10] <petrescu7> gslide: Disclaimers
[14:05:22] <petrescu7> slide: Terminology
[14:05:47] --- thomas.heide.clausen@gmail.com has joined
[14:05:54] <petrescu7> nice common terminology
[14:07:00] <petrescu7> slide: Extension Header Order
[14:07:07] --- julien.bournelle has joined
[14:07:20] <petrescu7> nice hypothetical order of headers for all
[14:07:41] <jeffa> < laughter >
[14:08:11] <petrescu7> slide: Layering
[14:08:24] <petrescu7> HS: did you lump the sender and rcver?
[14:08:42] <petrescu7> HS: not tightinh RH and DoH
[14:08:44] <petrescu7> DT: yes
[14:08:54] <petrescu7> L2TP not considered
[14:09:03] --- nm has joined
[14:09:51] <petrescu7> slide: Feature Comparison 1/2
[14:10:16] --- lars has left
[14:10:34] <petrescu7> one commonality: all preserve something across a locator
[14:11:00] <petrescu7> DT: what if both want to change simulatenously
[14:11:32] <petrescu7> none of these individually solves the entire problem
[14:11:46] <petrescu7> breaking in the middle of the net somewhere
[14:12:07] --- mkomu has joined
[14:12:08] <petrescu7> hip doesn't have algos to detect failures
[14:12:25] <petrescu7> Vijay Devarapalli is VD
[14:12:38] <petrescu7> DT: dynamic update in DNS
[14:13:00] <petrescu7> DT: if you don't have those mobility protocols then you need the dynamic update DNS (Ithink he said)
[14:13:31] <petrescu7> VD: outages dealing, is that an IP mobility problem?
[14:13:34] <petrescu7> DT: so
[14:13:43] <petrescu7> VD: network outage is happening differently
[14:13:46] <petrescu7> Thomas Narten
[14:13:57] <petrescu7> TN: useful to flesh out the rose you have, whether the rose is right thing.
[14:14:03] <petrescu7> TN: MIP has dependency on HA
[14:14:16] <petrescu7> TN: capture where the dependency is captured.
[14:14:22] <petrescu7> DT: was added in resp
[14:14:25] <petrescu7> Jeff Houston
[14:14:32] <petrescu7> JH: the night...share of the ...
[14:14:39] <petrescu7> JH: in shim6 is different rdv
[14:15:06] <petrescu7> Margaret Wasserman MW
[14:15:33] <petrescu7> slide: Feature Comparison 2/2
[14:16:17] <petrescu7> Tim Shepherd
[14:16:29] <petrescu7> TS: you could certainly do a referral with ah ip locator, no modif required.
[14:16:36] <petrescu7> DT: some proto prefer one thing.
[14:16:44] <petrescu7> DT: you can not append ..dated to that.
[14:17:01] <petrescu7> DT: the specific case: the very specific case the OS sess is connect()
[14:19:13] --- mallman has left: Computer went to sleep
[14:19:26] <petrescu7> MW: one of the things interesting to compare... mostly about mip and shim6... where things happen?
[14:19:28] <petrescu7> MW_where_
[14:19:43] <petrescu7> MW: MIP6 system has the view whether or not has the view whether something moved.
[14:19:51] <petrescu7> MW: in shim6 the ack is on the other end host.
[14:19:56] <petrescu7> MW: this has archi implications.
[14:20:13] <petrescu7> MW: can you get hints from up layers... other archi implications, hestiating saying to security.
[14:20:26] <petrescu7> MW: policy can be applied whether or not for a particula connection, this cna be changed.
[14:20:45] <petrescu7> MW: interesting: shim6 vs mip, pull of the locators, who decides whether or not to deide to failover.
[14:20:59] <petrescu7> MW: but in Enterprise, we'd like to have an intermediary. Big archi differentiator.
[14:21:27] <petrescu7> DT: my point in draft is not to compare the details of solutions other than the rose(?) you see here. What prbolem solves one sol, what problem solves other solution.
[14:21:43] <petrescu7> DT: local policy control
[14:21:53] <petrescu7> HS: if you condier a new version...
[14:22:00] <petrescu7> DT: internal protocol? go to that WG
[14:22:20] --- FDupont has joined
[14:22:28] <petrescu7> HS: archi diffs ok, but clarify end-2-end vs end-2 -ha is only applicable to one mode of mip ops (the other is ro).
[14:22:30] <petrescu7> DT: yes.
[14:22:36] <petrescu7> Tim TS:
[14:22:58] <petrescu7> TS: all these groups have a problem.
[14:23:16] <petrescu7> TS: how you view how you fill in boxes depends on how the archi you assume, which is not on paper.
[14:23:38] <petrescu7> TS: previous slide box looked ok, but then if you look at it... under archi assumptions make differnt for box filling.
[14:23:45] <petrescu7> TS: you miss, L2TP was a joke?>
[14:23:46] <petrescu7> laughs
[14:23:50] <petrescu7> DT: sctp I could too.
[14:23:59] <petrescu7> TS: the ones that are deployed.
[14:24:05] <petrescu7> TS: IPsec VPN a column for tha.t
[14:24:16] <petrescu7> DT: only comparing these 3 but
[14:24:27] <petrescu7> TS: I;ll think about the architectural
[14:24:30] <petrescu7> Pekka PS
[14:24:42] <petrescu7> PS: important to change the stable addresses on MIP to assumed.
[14:24:57] <petrescu7> PS: MIP HA placement is similarly effective with runembering with shim6.
[14:25:22] <petrescu7> PS: similar renumbering and other considerations in shim6.
[14:25:26] <petrescu7> Vijay Devarapalli
[14:25:27] <petrescu7> VD:
[14:25:40] --- mallman has joined
[14:25:46] <petrescu7> VD: we have extensions to make MIP support renumbering, and change HoA change.
[14:26:20] --- mallman has left: Computer went to sleep
[14:26:22] <idli> wonder why MOBIKE + IPsec-tunneling (i.e. applications using SGW-provided address) is not mentioned in the draft
[14:27:06] --- esa has joined
[14:27:19] <petrescu7> slide: efficiency considerations
[14:27:39] <petrescu7> actually in my previous notes "rose" is "rows".
[14:29:34] <petrescu7> George Tsirtsis
[14:29:48] <petrescu7> GT: if not using RO (route optimization) then should not be included in the table.
[14:29:54] <petrescu7> DT: RO is just an optimization
[14:30:15] <petrescu7> GT: but you compare mip to shim6 with ro in mind, end2end.
[14:30:28] <petrescu7> DT: some other slides later
[14:33:24] <petrescu7> slide: Deployment Considerations
[14:34:53] --- weiler has left
[14:34:54] <petrescu7> HS: efficiency, there are WG docs RFC to reduce to 1 packet
[14:35:16] <petrescu7> HS: worth mentgioning IPsec support
[14:35:51] <petrescu7> TN: middle section connect overhead? What it means for mip? MN to HA , MN to CN
[14:36:00] <petrescu7> TN: for shim6 only latter is interesting.
[14:36:08] <petrescu7> DT: end2end connect, tcp connect.
[14:36:33] <petrescu7> DT:TCP connect time on MIP, ethereal would see 2 messages.
[14:36:48] <petrescu7> TN: so RO?
[14:36:50] <petrescu7> DT: yes
[14:37:05] <petrescu7> TN; no need to start RO to CN unless you feel so
[14:37:10] <petrescu7> TN: same with shim6
[14:37:18] <petrescu7> DT: you say if happy with HA then stick with it.
[14:37:20] <petrescu7> TN: yes
[14:37:51] <petrescu7> TN: movement physically necessary update.
[14:38:00] <petrescu7> DT: hapyt to accept textual corrections to draft.
[14:38:14] <petrescu7> HS: happy to send you text, you may never need 6 messages.
[14:38:20] --- mkomu has left
[14:38:24] <petrescu7> slide: Deployment Considerations.
[14:38:31] <petrescu7> "idli" is in the room?
[14:38:42] <petrescu7> George GT
[14:39:09] --- thomas.heide.clausen@gmail.com has left: Logged out
[14:40:03] <petrescu7> GT: shim6 doesnt olook like having deployment dependeicneis, but it has, because you must be multihomed.
[14:40:09] <petrescu7> DT: multi addresses on interface
[14:40:14] <petrescu7> GT: that's multihomed
[14:40:30] <petrescu7> GT: do you need both things at the same time, or if one goes away, does the protocol help you?
[14:40:44] <petrescu7> DT: you can look at it either way
[14:40:47] <petrescu7> questioner:
[14:40:52] <idli> oh yes. just far from mike and large room ;)
[14:40:59] <petrescu7> q: DoS protection? Important piece.
[14:41:15] <petrescu7> idli: not sure anybody asked why no mobike in the doc, just somebody said vpn.
[14:41:36] <jeffa> that was Andrei Gurtov
[14:41:38] <idli> vpn is static, mobike is mobile, vpn question was mostly nonsense by l2tp guys I believe.
[14:41:48] <idli> at least as far as I understood it anyway.
[14:41:51] <petrescu7> DT: a minimum and maximum sec, the range is smaller in hip, minimum and max different for.
[14:41:59] <idli> (l2tp and ipsec-vpns are not really mobile)
[14:42:10] <petrescu7> idli: I agree with you. I think this is the initial shot at the document, he;ll probably update if he looks at it.
[14:42:37] <petrescu7> GM: for efficiency, battery rquirements, how often have to wake up refresh a binding.
[14:42:40] <petrescu7> JA: quick please, no mo
[14:42:51] <petrescu7> VD: do you want to consier maturity and deployment experience?
[14:43:03] <petrescu7> DT: no, but could be added to ... considerations, how long been out there.
[14:43:31] <petrescu7> GT: you made clear at the beguinning, but in doc too, this is about comparing protocols in e2e mode. for mip significant difference if ro used.
[14:43:43] <petrescu7> DT: that's why netlmm and nemo not mentioned.
[14:44:14] <petrescu7> Lars Eggert, AD (Transport)
[14:44:18] <petrescu7> slide: background
[14:44:25] <iljitsch> maybe it would make sense to split mip into mip + route optimization and mip - route optimization
[14:44:58] <idli> arguably NETLMM hub-and-spoke model is about as e2e as MIP MN-HA-CN triangle ;) oh well.
[14:46:05] --- marz has left: Disconnected.
[14:46:15] <petrescu7> idli, always wondered, people oppose NETLMM as not being end2end... is route updating happening in the net because links up/down end2end?
[14:46:45] <idli> NETLMM hub-and-spoke is arguably end2end-ish, but I do not personally see justification for whole NETLMM effort in the first place, seems duplication of effort.
[14:46:51] <petrescu7> slide: Example Assumptions
[14:47:04] --- dthaler has joined
[14:47:07] <petrescu7> dupplication of what
[14:47:19] <idli> of what other WGs are doing/have already done.
[14:47:24] <petrescu7> slide: Reality Check
[14:47:32] <dthaler> slides at http://www3.ietf.org/proceedings/06jul/slides/intarea-3.pdf
[14:47:36] --- venaas has left
[14:47:45] --- mallman has joined
[14:48:42] <petrescu7> slide: Consequences
[14:49:15] <petrescu7> slide: What Could Be Appropriate
[14:50:18] <petrescu7> slide: Not a New Idea
[14:51:22] <petrescu7> slide: General Principle
[14:51:38] <petrescu7> John Loguhney JL
[14:51:42] <petrescu7> Loughney
[14:52:03] <petrescu7> slide: What Next
[14:52:29] <dthaler> http://www.ietf.org/mailman/listinfo/ternli
[14:52:38] <dthaler> typo should be https above
[14:52:42] <petrescu7> JL: traditional transport proto TCP generally assume uniform path
[14:53:00] <petrescu7> JL: we're at a lot of changes with mobility, multihoming is where path changes.
[14:53:10] <petrescu7> LE: already the case with BGP.
[14:53:17] <petrescu7> JL: not with respect to RTT (usually)
[14:53:19] --- jpc has joined
[14:53:41] <petrescu7> LE: sctp does multihoming at transport layer, but we';re been conservatibe the path changes would not happen more freqy compared to rtt
[14:53:47] <petrescu7> that was JL
[14:54:02] <petrescu7> JL: not just changes in Internet at net layer...
[14:54:10] <petrescu7> JL : it's interesting for both layers of stack
[14:54:14] <petrescu7> Geoff Huston
[14:54:25] <petrescu7> GF: not clear you understand the architectural lines behind this.
[14:54:51] <petrescu7> GF: how to understand whatyou're trying to do in terms of feedback control mechanisms and the securioty of the mechanisms, and possiblity
[14:54:54] <petrescu7> of disruptuive.
[14:55:12] <petrescu7> generally most of these systems try to improve responses of tranposrt times, in multiple times of rtt
[14:55:18] <petrescu7> GH sorry
[14:55:33] <petrescu7> GH: we found other protocols that some of this time it's fgood to let things happen
[14:55:50] <petrescu7> GH: to what extenet when you try to improve feedback ....
[14:55:58] <petrescu7> to what extend you're exposing vulnarieblity
[14:56:20] <petrescu7> HG: lots of considerations. this is not new space for network protocols to venture into, issu is archi. What feedback response mechanisms
[14:56:31] <petrescu7> LE: agree this is known open space before.
[14:56:56] <petrescu7> LE: this sorts of interesting things... there's energy in ietf because we get people want to work on this in some way
[14:57:09] <petrescu7> LE: how would that look like, that's for discussion., irtf heavily involved here
[14:57:16] <petrescu7> GH: rocket ship to Pluto
[14:57:22] <petrescu7> GH: interest to sanity
[14:57:36] <petrescu7> GH: not what to work on. but what works in terms archi.
[14:57:50] <petrescu7> LE: the green is that there is some very simple and few things that would give good benefit
[14:57:56] <petrescu7> LE: dont want t optimize.
[14:58:11] <petrescu7> GH: the way in which you use the information, not the complexity.
[14:58:40] <petrescu7> HS: totally agree about how to use info; extremely useful , looked at it link to upper, and for management of mobility itself.
[14:59:00] <petrescu7> HS: as far as transferring outcoume of mob results to upper. Theres static and dynamic info to transfer.
[14:59:06] <petrescu7> HS: you've stressed the path change issue.
[14:59:15] <petrescu7> HS: I don't think upper layers care about path change.
[14:59:35] <petrescu7> LE: upper layer interested is what happens in the past on the link layer says what woill happen in the future.
[14:59:38] <petrescu7> HS: useful?
[14:59:42] <petrescu7> people: yes
[14:59:56] <petrescu7> HS: wireless, one wl link to another, conditions identicial.
[15:00:02] <petrescu7> LE: how can you know? may be luck
[15:00:07] <petrescu7> LE: low bw to high bw...
[15:00:19] <petrescu7> LE: TCP very slowly to accomodate low bw.
[15:00:30] <petrescu7> LE: in the hother direction, low to high, TCP gets losses.
[15:00:37] <petrescu7> LE: certain info can be usefu.l
[15:00:49] <petrescu7> HS: not agree, in the example you gave, conditions changed but exactly the same.
[15:00:54] <petrescu7> LE: deployable to Internet?
[15:00:58] <petrescu7> LE: not know talking about
[15:01:03] --- mundofer has joined
[15:01:16] <petrescu7> TN: Jeff said, I get nervous if temptation is to get performance faster... problems in the past.
[15:01:24] <petrescu7> TN: we don't do any thing coul dbe better.
[15:01:41] <petrescu7> TN: MN moves signals to HA new location, that could be used byu HA, path has changed, significant reset.
[15:02:01] <petrescu7> LE: other folks, sort of proposed response, never go faster, never go up, always go down.
[15:02:09] <petrescu7> LE: some protection against problems.
[15:02:31] <petrescu7> TN: your approah iis right, the trick is get a critcial mass of people work on that, need coherent proposal, before russhing too fast.
[15:02:35] <petrescu7> LE: a certain list.
[15:02:40] <petrescu7> questioner:
[15:02:51] --- esa has left
[15:02:56] <petrescu7> q: careful with trying to do the same thing in different layers, by passing information between them.
[15:03:10] <petrescu7> q: both layers do same thing, whiole thing falls appart
[15:03:13] <petrescu7> LE: layer congestio
[15:03:16] <petrescu7> q: not fight
[15:03:19] --- dthaler has left
[15:03:19] --- idli has left
[15:03:21] --- momose has left
[15:03:22] --- mallman has left: Computer went to sleep
[15:03:24] <petrescu7> ADs: adjourned
[15:03:24] --- FDupont has left
[15:03:24] --- jeffa has left
[15:03:24] --- washad has left: Computer went to sleep
[15:03:31] --- shep has left
[15:03:35] --- petrescu7 has left
[15:03:39] --- gurtov has left
[15:05:33] --- iljitsch has left
[15:10:49] --- dudi has left: Replaced by new connection
[15:14:07] --- idli has joined
[15:14:08] --- idli has left
[15:14:34] --- petrescu7 has joined
[15:14:57] --- petrescu7 has left
[15:18:21] --- rjaksa has left: Replaced by new connection
[15:18:37] --- cpignata has left
[15:18:37] --- cpignata has joined
[15:20:21] --- julien.bournelle has left
[15:23:13] --- dudi has joined
[15:23:56] --- dudi has left: Replaced by new connection
[15:26:58] --- nm has left
[15:27:19] --- nm has joined
[15:30:28] --- mo7sen has left
[15:30:39] --- mo7sen has joined
[15:31:04] --- mo7sen has left: Logged out
[15:32:49] --- mundofer has left
[15:37:30] --- mallman has joined
[15:37:42] --- mallman has left: Computer went to sleep
[15:45:09] --- mallman has joined
[15:45:18] --- mallman has left
[15:45:53] --- nm has left
[16:18:27] --- nm has joined
[16:36:05] --- nm has left: Replaced by new connection
[16:36:05] --- nm has joined
[16:36:05] --- nm has left
[17:02:13] --- yushun has left
[17:15:08] --- LOGGING STARTED
[17:18:51] --- jpc has joined
[17:20:02] --- cpignata has joined
[17:26:51] --- cpignata has left
[17:56:59] --- jpc has left