[03:46:28] --- llhotka has joined
[03:46:47] --- llhotka has left: offline
[03:47:02] --- llhotka has joined
[03:47:06] --- llhotka has left: offline
[03:52:09] --- apetrescu has joined
[03:53:29] --- tsavo_work@jabber.org/Meebo has joined
[03:55:12] --- jlcjohn has joined
[03:56:35] --- iljitsch has joined
[03:59:58] --- gih900 has joined
[04:00:31] --- rhe has joined
[04:01:31] --- apetrescu has left: Replaced by new connection
[04:01:39] --- apetrescu has joined
[04:02:21] <apetrescu> apparently some slides at https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=68 search for INTAREA
[04:03:16] <iljitsch> or keep your fingers crossed and hope the presenters use a readable font size...
[04:05:04] --- dthaler has joined
[04:05:54] --- fujiwara has joined
[04:05:56] --- brabson has joined
[04:06:06] --- menno pieters has joined
[04:06:17] --- andrewdmcgregor@jabber.psg.com has joined
[04:06:18] --- townsley@jabber.psg.com has joined
[04:06:18] --- tony1athome@jabber.org has joined
[04:06:21] --- ltn22@jabber.org has joined
[04:06:24] --- peetu has joined
[04:06:29] --- ldondeti has joined
[04:06:37] --- becarpenter has joined
[04:06:37] --- dku has joined
[04:06:38] --- arifumi has joined
[04:06:40] --- dowstreet@jabber.postel.org has joined
[04:06:40] <apetrescu> Thomas Narten speaking
[04:06:45] --- cabo has joined
[04:06:48] --- shep has joined
[04:06:57] --- sbrim has joined
[04:07:01] <apetrescu> Jari Arkko JA
[04:07:06] --- shikob has joined
[04:07:06] --- mtcarrasco has joined
[04:07:10] <apetrescu> slide: Why are we here?
[04:07:11] --- sbrim has left
[04:07:14] <dowstreet@jabber.postel.org> the plan is for limited discussion / questions until the end of the session
[04:07:23] --- elwynd has joined
[04:07:23] --- shinta has joined
[04:07:29] <apetrescu> slide: Goals of the Next 2.5 Hours
[04:07:33] --- narten has joined
[04:07:41] <cabo> https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=68#wg-intarea
[04:07:52] --- marka has joined
[04:08:27] <apetrescu> slide: Scope of the meeting
[04:09:06] <apetrescu> slide: High level boundary questions to keep in mind
[04:09:29] --- jclee has joined
[04:09:36] <apetrescu> slide: Initial Proposal from the ADs
[04:10:32] --- venaas has joined
[04:11:03] <apetrescu> slide: Next Steps
[04:13:11] <apetrescu> name of co-chair?
[04:13:11] --- joelja has joined
[04:13:41] <apetrescu> David Ward speaking
[04:14:02] <apetrescu> slide: Why is the routing community here? Tune in, turn on, no time out...
[04:14:12] <tony1athome@jabber.org> This is an old problem.
[04:14:18] <gih900> v.old
[04:14:34] <tony1athome@jabber.org> Trying to talk about new perspectives
[04:14:49] <narten> co-chairs: Peter Schoenmaker <pds@lugs.com>, Thomas Narten <narten@us.ibm.com>
[04:14:56] <tony1athome@jabber.org> Need clear problem statement and bounds on solution space
[04:15:06] <tony1athome@jabber.org> Do we need new tools and toolsets?
[04:15:26] <tony1athome@jabber.org> Or smaller tools and be less aggressive in change
[04:15:29] <iljitsch> fud for discussion??
[04:15:45] <apetrescu> slide: Fundamental Requiremenfs from Routing Community
[04:15:46] <tony1athome@jabber.org> rib/fib needs to flatten (or be negative)
[04:16:00] <tony1athome@jabber.org> Dynamics of the routing system have to sow down
[04:16:06] <tony1athome@jabber.org> s/sow/slow/
[04:16:49] <apetrescu> slide: Baseline PReferences (nod to Vince Fuller, Dave O. and Dino F.)0
[04:17:09] <tony1athome@jabber.org> ID -> {locators}
[04:17:16] <tony1athome@jabber.org> forward on locators
[04:17:28] <tony1athome@jabber.org> IDs may not be routable
[04:17:32] --- cabo has left
[04:17:37] --- lars.eggert@googlemail.com has joined
[04:17:45] <tony1athome@jabber.org> reachability is on locators
[04:17:46] --- stbryant has joined
[04:18:00] <tony1athome@jabber.org> incremental deployability
[04:18:17] <tony1athome@jabber.org> small change (???!)
[04:18:28] <tony1athome@jabber.org> reduction in transit state
[04:18:58] --- ltn22@jabber.org has left
[04:18:58] <tony1athome@jabber.org> no new ID->locator mapping service (???!!!!)
[04:19:13] <tony1athome@jabber.org> Align benefits and costs
[04:19:22] <apetrescu> slide: Site-BAsed Goals
[04:19:35] --- ltn22@jabber.org has joined
[04:19:38] <tony1athome@jabber.org> sites need mutihoming, provider changes
[04:19:55] --- dudi has joined
[04:19:56] <tony1athome@jabber.org> mobility, roaming TE desires
[04:20:50] --- resnick has joined
[04:21:18] <apetrescu> slide: Provider-Based Goals
[04:21:29] <tony1athome@jabber.org> providers need hardware scalability
[04:21:38] <tony1athome@jabber.org> competing requirements on hw
[04:21:52] <tony1athome@jabber.org> power & cost = f(pps, features)
[04:22:12] <apetrescu> its power || cost :-)
[04:22:22] <tony1athome@jabber.org> Which makes NO sense. ;-)
[04:23:01] <tony1athome@jabber.org> Providers need maximize their links
[04:23:07] <andrewdmcgregor@jabber.psg.com> (power, cost) would make more sense...
[04:23:12] <tony1athome@jabber.org> Need mobility, roaming, basic security
[04:23:16] <tony1athome@jabber.org> Agreed.
[04:23:32] <apetrescu> slide: ...the end of the beginning
[04:23:33] <townsley@jabber.psg.com> I think the point is "power = f(pps, features)" || "cost = f(pps, features)"
[04:23:35] <tony1athome@jabber.org> Internet needs re-architecting
[04:23:48] <tony1athome@jabber.org> Why ||?
[04:24:00] <tony1athome@jabber.org> In C, that's one or the other. We have both.
[04:24:02] <townsley@jabber.psg.com> the equation applies to both
[04:24:28] <townsley@jabber.psg.com> perhaps && makes more sense
[04:24:55] <townsley@jabber.psg.com> or (power, cost) as was suggested.
[04:24:56] <tony1athome@jabber.org> Other issues: manet, security, service locators, multiple service domains (MTR)
[04:25:25] <tony1athome@jabber.org> two databases:
[04:25:26] <apetrescu> slide: A tale of two databases
[04:25:30] <tony1athome@jabber.org> RIB & FIB
[04:25:37] <tony1athome@jabber.org> name -> address
[04:25:42] <lars.eggert@googlemail.com> about the projector: the same issue existed during nsis. it does not like macs. project from a pc
[04:25:47] <apetrescu> screen gets flickery...
[04:25:50] <tony1athome@jabber.org> Still in evolution
[04:26:11] <iljitsch> may help to adjust the screen resolution / refresh rate
[04:26:21] <apetrescu> screen is off temporarily
[04:26:31] --- vidya has joined
[04:26:43] <tony1athome@jabber.org> routing maps address to path
[04:26:47] <apetrescu> slide: (next)
[04:27:00] --- nov has joined
[04:27:07] <tony1athome@jabber.org> need topology
[04:27:17] <gih900> slide: Two databases directly related
[04:27:40] --- narten has left
[04:27:43] <tony1athome@jabber.org> have name -> address, address->path
[04:27:55] <tony1athome@jabber.org> need address -> locator, SNPA
[04:28:16] <iljitsch> are there any trained mimes in the room?
[04:28:17] <apetrescu> Margaret Wasserman
[04:28:17] <apetrescu> MW
[04:28:21] <apetrescu> MW: clarifying q
[04:28:40] <apetrescu> MW: in earlier slide you said routing commu didnt want to map, now you say reverse, trying to understand?
[04:28:52] --- miyahiro has joined
[04:28:53] <apetrescu> DW: routing commu realizes abslultely realizes must be a mapping function
[04:29:01] <apetrescu> MW: didnt earlier said you dont want that?
[04:29:05] <apetrescu> DW: if possible, we want
[04:29:06] <tony1athome@jabber.org> need to reuse technology
[04:29:17] <tony1athome@jabber.org> need new mapping function, but want to use OLD mapping mechanism
[04:29:23] <tony1athome@jabber.org> (?!?!)
[04:29:30] <tony1athome@jabber.org> There's a swamp
[04:29:37] <gih900> Slide: Operational issues
[04:29:41] <tony1athome@jabber.org> Policy on the swamp sucks
[04:29:57] <tony1athome@jabber.org> Ok, policy itself sucks
[04:30:12] <tony1athome@jabber.org> full table doesn't scale
[04:30:29] <tony1athome@jabber.org> More specifics may not need to be global
[04:30:39] <apetrescu> slide: summarizing the overview
[04:30:45] <tony1athome@jabber.org> BGP mods in rtg area mtg
[04:31:09] <tony1athome@jabber.org> RRG to deal with routing design (and architecture)
[04:31:19] <tony1athome@jabber.org> Need scalable router solution
[04:31:35] --- stjepan.gros has joined
[04:31:39] <tony1athome@jabber.org> Codependence of routing and mapping need to be considered thoroughly
[04:31:44] <tony1athome@jabber.org> What is the time frame?
[04:32:04] <tony1athome@jabber.org> No clarity on requirements currenty
[04:32:15] <apetrescu> Hesham Soliman waiting at mike HS
[04:32:16] <lars.eggert@googlemail.com> about the projector: the same issue existed during nsis. it does not like macs. project from a pc
[04:32:22] <stbryant> need short med and long term solns
[04:32:30] <apetrescu> HS: two qs clarifying,
[04:32:35] <apetrescu> DQ: b etter ask
[04:32:40] <apetrescu> HS: baseline preference line?
[04:32:53] <tony1athome@jabber.org> Mobility protocols exist today
[04:32:54] <apetrescu> HS: list of issues needs to be addressed, are really just solved today by a number of mobil protocols
[04:33:03] <apetrescu> HS: didnt think the change of ... is the core...
[04:33:06] <tony1athome@jabber.org> mobility doesn't exist
[04:33:10] <apetrescu> HS: not sure what to make out of that
[04:33:30] <tony1athome@jabber.org> Not a discussion of existing solution, just pointing out that mobility is a topology problem
[04:33:31] <apetrescu> DW: not meant discussion of specific solution IP mobility (4 or 6) but right now addresses bound to sites, when you change sites, not directly the IP mobility
[04:33:38] <apetrescu> DW: not th emobile phone walking around
[04:33:50] <tony1athome@jabber.org> redundancy not listed?
[04:33:50] <apetrescu> HS: other q on following slide, site multihming, didnt see redundancy as req
[04:33:53] <apetrescu> DW: sure
[04:34:09] <apetrescu> DW: trying to clarify TE and MH... certainly redundnancy and utilisation of multiple link
[04:34:15] <apetrescu> Ja Mason Level 3
[04:34:30] <iljitsch> are we having the discussion part now?
[04:34:37] <tony1athome@jabber.org> Multihoming more important than mobility
[04:34:41] <apetrescu> JM: site-based, provider-based, service provide rperspective, multhimoning problem than mobility more important
[04:34:56] <apetrescu> JM: dont know possibliity we can perhaps look at this from two DT perspective
[04:34:58] <tony1athome@jabber.org> Two solutions?
[04:35:11] <apetrescu> JM: some folks pursue as multihoming solution, others as mobility solution, both painleslly
[04:35:18] <apetrescu> JM: overloading too many goals...
[04:35:29] <apetrescu> JM: very early at this stage but just a concern I have
[04:35:55] <apetrescu> JM: 2nd point, real problem is gonna be solving for multihoming and we need to be very focused on that, mapping databse, that is really is the fundamental issue
[04:35:59] <tony1athome@jabber.org> Mapping is fundamental (well, yeah)
[04:36:09] <tony1athome@jabber.org> How do we scale it?
[04:36:11] <apetrescu> JM: extremely large amount of time we spend ... on .. we dont have anything in that area...
[04:36:32] <apetrescu> JM: encapsulation and wired formats we can talk, but distraction from core problem, how do we solve that mapping funciton, how to scale that
[04:36:34] <apetrescu> DW: agrees.
[04:36:44] <apetrescu> DW: probably endup which scheme we choose ...
[04:36:57] <tony1athome@jabber.org> claifications only!
[04:36:57] <apetrescu> TN: clarifyin q and keep brief
[04:37:02] <apetrescu> Vince (?) talking
[04:37:04] <stbryant> very long lines have formed
[04:37:16] <townsley@jabber.psg.com> Vince Fuller
[04:37:17] <tony1athome@jabber.org> Lots of similar solutions
[04:37:20] <apetrescu> V: all dance around the issue how you perform this mapping, regardless which specific solution
[04:37:27] <apetrescu> laughs
[04:37:44] <apetrescu> V: suprised you looed at sort of the , 2 ways to look at this problem,
[04:37:56] <apetrescu> V: we can look at trying to get control of undesirable gold patterns...
[04:38:11] <tony1athome@jabber.org> Control growth and accept growth
[04:38:16] <apetrescu> V: other side we need an Internet archi that satisfies users, such as widespread multihoming,
[04:38:22] <tony1athome@jabber.org> get dynamics under control and add functionality
[04:38:23] <apetrescu> V: one is getting control of dynamics
[04:38:28] <apetrescu> V: other is...
[04:38:37] <apetrescu> V: surprised not see this on slide, given we discussed this before
[04:38:43] <apetrescu> DQ: additional goals we stress
[04:38:48] <apetrescu> V: comment on priorities
[04:38:53] <apetrescu> sorry DQ is DW
[04:39:00] <apetrescu> Dimitri Papadimitriou
[04:39:05] <tony1athome@jabber.org> what's the diff between a service locator and a locator?
[04:39:11] <apetrescu> DP: difference between locator and service locator
[04:39:26] <tony1athome@jabber.org> Locators provide connectivity
[04:39:26] <apetrescu> DW: endpoint, reachability to high speed, dont care if service is connectivity
[04:39:32] <apetrescu> DW: if looking for ...
[04:39:33] <tony1athome@jabber.org> Service locators are service specific
[04:39:44] <tony1athome@jabber.org> MTR (???)
[04:39:48] <apetrescu> DW: you need to have ability get into that correct service topology, or services associated with ...
[04:39:53] <apetrescu> DW: notion of Service Domain?
[04:39:59] <apetrescu> sorry that's DP
[04:40:01] <tony1athome@jabber.org> This is now a service domain
[04:40:16] <apetrescu> DW: multiple overlay topologies, for services to traverse part of topolopogy
[04:40:26] --- jclee has left: Replaced by new connection
[04:40:33] <apetrescu> DP: it would assume you have a ... relationship user-network.
[04:40:43] <apetrescu> Alain Durand AD
[04:40:43] <tony1athome@jabber.org> Service domains are different than best effort
[04:40:57] <apetrescu> AD: this I couldnt have the... dissident in the IPPv class..
[04:41:01] <tony1athome@jabber.org> How are costs distributed?
[04:41:11] <tony1athome@jabber.org> Providers come in different sizes
[04:41:13] <apetrescu> AD: site vs providers, Id like to make providers provide different shape of ...
[04:41:18] <tony1athome@jabber.org> core vs access
[04:41:21] <apetrescu> AD: core of network, or to edges
[04:41:27] <apetrescu> DW: no comment on that specific...
[04:41:39] <apetrescu> DW: when architecture changes we need to understand, otherwise people are hurt
[04:41:42] <apetrescu> AD:...
[04:41:46] <apetrescu> DW agrees
[04:41:50] --- jclee has joined
[04:41:51] <tony1athome@jabber.org> Costs need to be assigned to the particular provider subset
[04:41:52] <apetrescu> somebody
[04:42:03] <tony1athome@jabber.org> Transport is about dynamics
[04:42:05] <andrewdmcgregor@jabber.psg.com> From the point of view of the sender of a flow, what is the difference between multihoming and mobility? Is there one?
[04:42:10] <tony1athome@jabber.org> worry about transport on top
[04:42:15] <apetrescu> s: end2end transport, change the archi think how it works iwth transport protocols, but best archi is not as useful as ... TCP
[04:42:17] <tony1athome@jabber.org> Hosing TCP would be bad.
[04:42:19] <apetrescu> DW: agrees
[04:42:23] <apetrescu> operator guy
[04:42:30] <shep> Many people seem to assume that if we have an ID/locator split that there then must be a way of mapping a bare ID into a locator. But there are alternative architectures, for example the FARA stuff that was done in the Newarch project years ago. My understanding is that they showed that an architecture where you start with a name and looking up the name in the directory (think DNS) gives you a (set of) locator(s). Then you use the locator to communicate directly with the relevant endpoint, which can tell you what ID (and perhaps what other locators) to use. So splitting out ID from locator does *not* imply that we must have a (network wide) mechanism for mapping bare IDs to locators (nor to anything else in particular).
[04:42:38] <tony1athome@jabber.org> Rudiger Volk, DT
[04:42:55] --- joelja has left
[04:42:55] --- stjepan.gros has left
[04:43:06] <shep> ...... and perhaps this next talk will talk about this (I hope).
[04:43:08] --- pds@jabber.gin.ntt.net has joined
[04:43:22] <shep> ( next talk == Dave Thaler's talk)
[04:43:24] <tony1athome@jabber.org> sites have pi, tier 1s have those sites
[04:43:25] --- csperkins has joined
[04:43:27] <townsley@jabber.psg.com> Shep. stay tuned to later presentations...
[04:43:28] --- apetrescu has left: Replaced by new connection
[04:43:33] <tony1athome@jabber.org> we got here
[04:43:35] --- apetrescu has joined
[04:43:40] <tony1athome@jabber.org> Applying policy to a swamp is a mess
[04:43:50] --- ldondeti has left: Replaced by new connection.
[04:43:56] <apetrescu> slide: Outline
[04:44:02] <tony1athome@jabber.org> terminology
[04:44:05] <tony1athome@jabber.org> core problems
[04:44:10] --- becarpenter has left
[04:44:15] <tony1athome@jabber.org> solution flexibility and constraints
[04:44:16] <apetrescu> slide: Starting from basics
[04:44:21] <tony1athome@jabber.org> users have names
[04:44:21] --- becarpenter has joined
[04:44:26] --- resnick has left
[04:44:36] <tony1athome@jabber.org> DNS names
[04:44:42] <tony1athome@jabber.org> routing deals with locators
[04:44:50] <tony1athome@jabber.org> security deals with identities
[04:45:04] <apetrescu> slide: Routing Scalability Basics
[04:45:12] <tony1athome@jabber.org> aggregation broken by
[04:45:16] <tony1athome@jabber.org> pi addressing
[04:45:19] <tony1athome@jabber.org> multihoming
[04:45:20] <tony1athome@jabber.org> TE
[04:45:27] --- joelja has joined
[04:45:30] --- ldondeti has joined
[04:45:34] <tony1athome@jabber.org> Local operational state propagated globaly
[04:46:10] --- Magnus W has joined
[04:46:26] <apetrescu> slide: Mobility Basics
[04:46:26] <tony1athome@jabber.org> Needs of the one foisted on the many.
[04:46:39] <tony1athome@jabber.org> Mobility could be handled by routing
[04:46:43] --- mtcarrasco has left
[04:46:46] <tony1athome@jabber.org> but doesn't scale and doesn't converge
[04:46:57] <apetrescu> right...
[04:47:02] <tony1athome@jabber.org> If naming had speed, then mobility could be handled by naming
[04:47:13] --- csperkins has left
[04:47:17] <apetrescu> slide: Host Mobility 1: Accept new connections immediately after a move
[04:47:20] <tony1athome@jabber.org> host mobility: new connections after a move
[04:47:33] <tony1athome@jabber.org> DNS can't cope with fast changes
[04:47:44] <tony1athome@jabber.org> Addresses get cache
[04:47:48] --- saphira@jabber.no has joined
[04:48:03] <tony1athome@jabber.org> DNS resolvers ignore small TTLs
[04:48:14] <tony1athome@jabber.org> Applications don't respect TTL
[04:48:25] <apetrescu> slide: Host Mobility 2: Preserve established connections
[04:48:31] <tony1athome@jabber.org> Session propagation
[04:48:33] <shep> such DNS resolvers (that don't respect (small) TTLs) are unambiguously broken, no?
[04:48:42] <tony1athome@jabber.org> Locators change
[04:48:51] <tony1athome@jabber.org> May be disconnected
[04:49:11] <tony1athome@jabber.org> Some layer must do transparent reconnection
[04:49:24] --- jyg has joined
[04:49:36] <tony1athome@jabber.org> Apps can handle it directly
[04:49:38] --- dward@jabber.org has joined
[04:49:53] <tony1athome@jabber.org> Benefits to doing it that way
[04:50:04] <tony1athome@jabber.org> Would app mobility be sufficient?
[04:50:09] --- resnick has joined
[04:50:11] <tony1athome@jabber.org> No
[04:50:18] <tony1athome@jabber.org> Real time interactive apps aren't fast enough
[04:50:25] <tony1athome@jabber.org> Need to happen below the app
[04:50:27] --- resnick has left
[04:50:27] --- resnick has joined
[04:50:32] <apetrescu> slide: Site Mobility: Ease Reunmbering
[04:50:34] <tony1athome@jabber.org> Site mobility: easy renumbering
[04:50:51] <tony1athome@jabber.org> WHere are addresses recorded?
[04:51:01] <tony1athome@jabber.org> hosts, routers, infrastructred, middle boxes
[04:51:18] <tony1athome@jabber.org> How many must change?
[04:51:22] <shep> ... and it depends on how much of the changing is automated.
[04:51:34] <tony1athome@jabber.org> Multihoming problems
[04:51:36] <apetrescu> slide: Multihoming: Support redundancy, load sharing, etc (RFC3582)
[04:51:52] <andrewdmcgregor@jabber.psg.com> And how much automation you can do depends on what identifies the rules in all those databases.
[04:51:52] <tony1athome@jabber.org> names map to hosts with multiple locators
[04:51:54] --- csp has joined
[04:52:03] <tony1athome@jabber.org> set of locators must be communicated
[04:52:36] <tony1athome@jabber.org> One end sends set of communicators, other end selects
[04:52:41] --- venaas has left: Logged out
[04:52:42] <tony1athome@jabber.org> Current model is only one locator
[04:52:58] <tony1athome@jabber.org> No rebinding on locator changes
[04:53:07] <apetrescu> slide: Location Privacy
[04:53:16] <tony1athome@jabber.org> Hide topology from outsiders
[04:53:48] <tony1athome@jabber.org> today its visible unless you use nat, or tunnel
[04:54:17] <apetrescu> slide: What can we change (/12)
[04:54:17] <tony1athome@jabber.org> What can be changed?
[04:54:27] <apetrescu> questioner
[04:54:34] <apetrescu> Gregory
[04:54:52] <apetrescu> G: locator used as identifier, do you believe what people wanna do ther is to hide id or lacotr?
[04:54:57] --- dowstreet@jabber.postel.org has left: Logged out
[04:55:11] <apetrescu> DT:both prevent the locator on one end from being seen by other end
[04:55:14] <tony1athome@jabber.org> Tunneling and nat hide local portion of locator
[04:55:18] <apetrescu> DT: what's being tried to hide is locator
[04:55:31] <apetrescu> DT: at least not all the nitty-gritty details of locator
[04:55:34] <apetrescu> MW: abstraction
[04:55:53] <apetrescu> DT: basic idea is so, one of the many reasons people use NAT because they think topolo is flat.
[04:56:10] <tony1athome@jabber.org> managed systems are easier than unmanaged
[04:56:19] <tony1athome@jabber.org> managed ones have automated system management
[04:56:31] <tony1athome@jabber.org> Non automated things are rarely if ever updated
[04:56:50] <tony1athome@jabber.org> Homes manage hosts, but not routers
[04:57:00] <tony1athome@jabber.org> corps maintain routers but not hosts
[04:58:00] <tony1athome@jabber.org> Embedded hosts are never managed
[04:58:01] <apetrescu> slide: What can we change (2/2)
[04:58:07] <tony1athome@jabber.org> Apps
[04:58:16] <tony1athome@jabber.org> can't change all apps, but can fix new ones
[04:58:38] <tony1athome@jabber.org> New apps moving to higher level apis
[04:58:45] <tony1athome@jabber.org> Away from sockets (yeah!)
[04:59:17] <tony1athome@jabber.org> management and security systems
[04:59:22] <tony1athome@jabber.org> hard to change
[04:59:39] <tony1athome@jabber.org> most assume identifier == locator
[05:00:09] <tony1athome@jabber.org> loc/id split makes it harder to filter and determine id
[05:00:28] <tony1athome@jabber.org> have to fix all mgmt systems before deployment
[05:00:44] <apetrescu> slide: Incentive Structure
[05:00:46] <tony1athome@jabber.org> preserve locator== ident within corpo
[05:01:01] <tony1athome@jabber.org> Best if changes done by those feeling pain
[05:01:06] <tony1athome@jabber.org> motivation aligned
[05:01:09] --- cabo has joined
[05:01:10] <apetrescu> (joke on changing a lighbulb, a version never heard)
[05:01:16] <iljitsch> what does "long pole" mean??
[05:01:19] --- tim.polk has joined
[05:01:31] <tony1athome@jabber.org> providers can change routers
[05:01:32] <gih900> s/change/cost/ is perhaps closer to the actual situation
[05:01:36] <tony1athome@jabber.org> users can change hosts
[05:02:07] <tony1athome@jabber.org> mobility benefits acrue to mobile hsot
[05:02:10] <tony1athome@jabber.org> host
[05:02:24] <tony1athome@jabber.org> Only one end gets pain
[05:02:35] <apetrescu> slide: Design questions
[05:02:36] --- sureshk has joined
[05:02:37] <tony1athome@jabber.org> identifier properties
[05:02:58] <tony1athome@jabber.org> must work with legacy apps, destiations, referrals
[05:03:00] <apetrescu> slide: Support referrals
[05:03:10] <tony1athome@jabber.org> redirects need to work
[05:03:18] <tony1athome@jabber.org> Why not use a name?
[05:03:25] <tony1athome@jabber.org> Requires mapping again
[05:03:30] --- raeburn@mit.edu has joined
[05:03:43] <tony1athome@jabber.org> could provide locator hint
[05:04:13] <tony1athome@jabber.org> some apps only cache addresses
[05:04:25] <tony1athome@jabber.org> some apps only defined about addrs
[05:04:33] <tony1athome@jabber.org> some apps never get name (e.g., servers)
[05:04:57] --- farinacci@gmail.com has joined
[05:05:05] <apetrescu> slide: 1. How is mapping secured? (1/3)
[05:05:13] <tony1athome@jabber.org> fun graphics
[05:05:39] <tony1athome@jabber.org> lots of block diagrams with lots of mappings left out
[05:05:44] <apetrescu> TLS over ROAP over bottom of slide :-)
[05:05:48] <tony1athome@jabber.org> is there something between idents to locators
[05:06:01] <townsley@jabber.psg.com> A question mark
[05:06:10] <tony1athome@jabber.org> mappings: ident -> connection
[05:06:12] <tony1athome@jabber.org> ident -> locator
[05:06:14] --- raeburn@mit.edu has left
[05:06:17] <tony1athome@jabber.org> Locator->connection
[05:06:21] <tony1athome@jabber.org> name -> locator
[05:06:36] <tony1athome@jabber.org> name -> connection (TLS)
[05:06:46] <tony1athome@jabber.org> name -> identifer (DNSsec (sic))
[05:07:09] <tony1athome@jabber.org> Is there some other namespace between ids and locators and how do we secure that
[05:07:28] <tony1athome@jabber.org> every mapping needs to be secured
[05:07:49] <apetrescu> slide: Security Basics
[05:07:56] <tony1athome@jabber.org> Do we need other mappings? {tli}
[05:08:08] <tony1athome@jabber.org> Need chain of trust from name to connection
[05:08:25] <apetrescu> slide: 1. How is mapping secured? (1/3)
[05:08:39] <apetrescu> slide: 1. How is mapping secured? (3/3)
[05:08:58] <tony1athome@jabber.org> identifier dervied from identity?
[05:09:00] --- stjepan.gros has joined
[05:09:04] --- raeburn@mit.edu has joined
[05:09:10] <tony1athome@jabber.org> identifier/locator mapping is signed?
[05:09:28] <tony1athome@jabber.org> return routability check only?
[05:09:42] <apetrescu> slide: 2. Mapping name to identifier
[05:09:46] <tony1athome@jabber.org> if name == identifier this is trivial
[05:10:13] <tony1athome@jabber.org> otherwise, need existing mechanism (DNS, SIP)
[05:10:18] <tony1athome@jabber.org> need security
[05:10:25] <tony1athome@jabber.org> can there be multiple identifiers?
[05:10:31] --- jgs@jabber.org has joined
[05:10:36] <apetrescu> slide: Mapping identifier to locators (1/3)
[05:10:40] <tony1athome@jabber.org> Need dynamically changing locators
[05:10:46] <tony1athome@jabber.org> multiple localtors security
[05:10:59] <tony1athome@jabber.org> Where?
[05:11:03] <apetrescu> slide: Mapping identifier to locators (2/3)
[05:11:17] <apetrescu> Dino Farinacci
[05:11:24] <tony1athome@jabber.org> Q: reachability of locators?
[05:11:26] <apetrescu> DF: also reachability of locators, that's different from changing
[05:11:28] <tony1athome@jabber.org> yes
[05:11:28] <apetrescu> DT: yes
[05:11:40] --- dowstreet@jabber.postel.org has joined
[05:11:41] <tony1athome@jabber.org> Vertical locus:
[05:11:54] <tony1athome@jabber.org> applicaiton, session, transport, nework layer, below IP
[05:12:14] <apetrescu> Margaret MW
[05:12:22] <tony1athome@jabber.org> Horizontal: within host or out in network
[05:12:49] <tony1athome@jabber.org> Network based doesn't work as host changes network
[05:12:56] <sureshk> alex are we on slide 16?
[05:12:56] <tony1athome@jabber.org> also centralizes burden
[05:13:03] <tony1athome@jabber.org> 21
[05:13:08] <sureshk> thx
[05:13:25] <apetrescu> MW: add if the network q of how is the ... ... also requireiring return traffic transit same path as forward traffic
[05:13:28] <tony1athome@jabber.org> Q: is this brittle, does it require symmetry?
[05:13:31] --- miyahiro has left: Replaced by new connection
[05:13:40] --- csp has left
[05:13:41] <tony1athome@jabber.org> When do you map id->loc
[05:13:42] <apetrescu> slide: Mapping identifier to locator (3/3)
[05:13:49] <tony1athome@jabber.org> on demand?
[05:14:02] <tony1athome@jabber.org> name resolution time, but not all apps resolve names
[05:14:08] <tony1athome@jabber.org> eg. servers
[05:14:15] <tony1athome@jabber.org> at time of first packet
[05:14:17] --- jpc has joined
[05:14:23] <tony1athome@jabber.org> what to do with first packet?
[05:14:30] <gih900> ("when" also implies for how long do you remember the mapping before you re-perform the mapping function)
[05:14:36] <tony1athome@jabber.org> circular dependency between routing and lookup?
[05:14:50] <tony1athome@jabber.org> when do you get changes to mapping
[05:15:50] <apetrescu> slide 23: Implications on Mapping Function (nod Ross Callon)
[05:15:54] <tony1athome@jabber.org> Is mapping in router?
[05:16:12] <tony1athome@jabber.org> on demand forwarding plane update puts demands on router control plane
[05:16:21] <tony1athome@jabber.org> Event rate could be high
[05:16:36] <tony1athome@jabber.org> high forwarding plane exceptions can still swamp CPU
[05:16:47] <tony1athome@jabber.org> 10^-10 or better
[05:17:04] <tony1athome@jabber.org> mapps tables might become as large and dynamic as todays fibs
[05:18:08] <tony1athome@jabber.org> Pushing problem around?
[05:18:18] <apetrescu> DF: first subbullet, assumes box doing fwd based on caching
[05:18:25] <apetrescu> DF: but caching doesn t imply...
[05:18:25] <tony1athome@jabber.org> Q: this implies caching, that's not required
[05:18:32] --- venaas has joined
[05:18:42] <apetrescu> DT: exactly, if you are going to fwding plane and kicking off a box, not your bullet
[05:18:48] <apetrescu> DT: not on demand i f you do that
[05:18:52] <apetrescu> MW: two observations
[05:19:16] --- gorryf has joined
[05:19:17] <apetrescu> MW: we arent, but MPLS have experience with things packets go up to control plane to set up flows with rsvp, and learn how does that work,
[05:19:45] <apetrescu> MW:once you developped that can manage this thing that can be larger, why not this BGP, maybe different reqs? reqs not clear enough to know as...
[05:20:06] <apetrescu> MW: probably larger for wevery mh host a host entry and for every site a prefix... fear of routing table grows towards that motivates us, we
[05:20:10] <apetrescu> MW: why not moving back
[05:20:17] <apetrescu> DT: question over time, no answert oday
[05:20:22] <apetrescu> DT: Ross you answer that?
[05:20:26] <apetrescu> Ross Callon
[05:20:37] <apetrescu> RC: my comments on your slide, a pretty good interpretation what we talk about
[05:20:46] <apetrescu> RC: really in miy mind 2 aspects 3
[05:21:02] <apetrescu> RC: if you get a packet, is the cache entry already there, are you ready to fwd somewhere else, a delay?
[05:21:12] <apetrescu> RC: some solutions a way where is a cache, others
[05:21:19] <apetrescu> RC: a total load of the control plane
[05:21:22] <apetrescu> RC: PE routers
[05:21:25] --- behcet.sarikaya has joined
[05:21:36] <apetrescu> RC: rate to which fwd packets, 10 to the fourth slower
[05:21:54] <apetrescu> RC: if get a packet for every ... you can't handle 1 in 1000 packets because no bw.
[05:22:03] <apetrescu> RC: could re-design routers fundamentally but not eager
[05:22:09] <apetrescu> RC: or put on routers where that is not true
[05:22:21] <apetrescu> RC: which routers we put this on? or bigger than control plane can handle
[05:22:24] <apetrescu> Aline There
[05:22:30] <sureshk> Eliot Lear?
[05:22:37] <tony1athome@jabber.org> Yah
[05:22:38] <gih900> yep Eliot
[05:22:42] <apetrescu> AT: what problem you solve, if you look ... id-locator mapping, routing space
[05:22:54] <apetrescu> EL: very different sorts of ... if we solve the one we give benefit to other
[05:23:01] <apetrescu> EL: no data in all presentations we saw todayr
[05:23:06] <apetrescu> Vijya Jain
[05:23:11] <sureshk> lixia
[05:23:11] <gih900> Lixia Zhang
[05:23:29] <apetrescu> VJ: the existence, a long history of prior work, the graphic, mapping function, only cause bigger pressure recently
[05:23:38] <apetrescu> LZ: this implications somehow had specific solution approach in mind
[05:23:47] <apetrescu> LZ: different designs can have different implementations
[05:23:54] <apetrescu> LZ: at this point, not the specific detail
[05:23:59] <apetrescu> LZ: we dont know that space much yet
[05:24:01] <apetrescu> DT: yeap
[05:24:07] <apetrescu> Tim Shepard
[05:24:23] <apetrescu> TS: earlier the talk you assume you dont need id-locator
[05:24:33] <apetrescu> DT: at the point, that was given here's why we are here/
[05:24:40] <apetrescu> DT: independent of using a loc-id...
[05:24:47] <apetrescu> TN: clarifying qs please, keep brief
[05:25:04] <apetrescu> DT: qs I'm going through, qs you need to answer.
[05:25:31] <apetrescu> TS: id-locator stuff requires to be aware , name-to id, ... is actually, but there are alternative archis, you're reluctant to explore possibliitye in this particular talk
[05:25:33] <apetrescu> DT: ok
[05:25:36] <apetrescu> TS: you wanna comment
[05:25:41] <apetrescu> DT: not, afterwards
[05:25:42] <apetrescu> Jim Bound
[05:26:07] <apetrescu> JB: on this slide, wondrs why th eoperators big ones, router vendors, building service plans.
[05:26:15] <apetrescu> JB: vs building some... new product.
[05:26:35] <apetrescu> JB: Dino said, wondering can we address this as abstract w/o including smth from services plane, the business of IETF
[05:26:56] <apetrescu> JB: this talk I assume, is are all examples, from community, not pushing, just examples, not pusing
[05:27:02] <apetrescu> DT: yes not pushing any answers
[05:27:06] <apetrescu> JB: thanks
[05:27:16] <apetrescu> DT: just asking what the answers are, thos who habe need to answer
[05:27:17] --- r.szabo has joined
[05:27:32] <apetrescu> MW: kind of referral we never think about, application layer, not sure referral or not, but example
[05:27:48] <apetrescu> MW: you might want to look at node try to figure out whose ressources, TCP conneciton table see whose connected...
[05:27:55] <apetrescu> MW: maybe this is kind posing problem.
[05:28:00] <apetrescu> MW: src , remote ip address
[05:28:15] <apetrescu> MW: thosemanagement level things, like referrals, consider separately, bnecause possiblitiy to use a name
[05:28:24] <apetrescu> JS: short please
[05:28:29] <apetrescu> Ruediger smth
[05:28:41] <apetrescu> R: distinguish with various name spaces, surprised to see enssentially
[05:28:42] <tony1athome@jabber.org> Volk
[05:28:57] <apetrescu> RV: nothing between user handle and security and locator,
[05:29:07] <apetrescu> RV: identifier space to applicaiton or transport handle?
[05:29:18] <apetrescu> DT: this is a core base you cantbe around
[05:29:40] <apetrescu> RV: my q, is it loogin into structure of comm system, isnt that basics that's also one of the levels where you have to name things?
[05:29:50] <apetrescu> LZ: clarrification
[05:30:00] <apetrescu> LZ: session to id, or exploring the solution space?
[05:30:04] <apetrescu> DT: not under
[05:30:09] <apetrescu> DT: not exploring solution space
[05:30:23] <apetrescu> slide: Is identifier routable or not?
[05:31:37] <tony1athome@jabber.org> non-routable is good for scalability
[05:31:48] <apetrescu> slide 25: 4. Explicit in data packet or not?
[05:31:49] <tony1athome@jabber.org> is id->locator mappin in packet?
[05:32:00] <tony1athome@jabber.org> what do middle boxes see?
[05:32:16] <tony1athome@jabber.org> Explicity tunneling makes it more obvious
[05:32:52] <tony1athome@jabber.org> Implicit makes it hard to find identifier, which makes it harder for filtering
[05:33:04] <tony1athome@jabber.org> Asymmetry means you may not see mapping state
[05:33:20] <apetrescu> JS: keep to end of presentation please
[05:33:31] <apetrescu> slide 26: Summary
[05:33:40] <tony1athome@jabber.org> align deployment and incentives
[05:34:01] <tony1athome@jabber.org> Are there multiple solutions?
[05:34:17] <tony1athome@jabber.org> Align solutions with motiviations
[05:34:26] <apetrescu> Pekka Nikander going to present
[05:34:48] <apetrescu> slide: Design features vs potential benefits of id/loc separation
[05:35:16] <apetrescu> slide: Presentation outline
[05:35:45] <apetrescu> slide: Design features
[05:36:08] --- bhoeneis has joined
[05:36:14] <tony1athome@jabber.org> deployment scenarios, implementation loci, id structure and properaties, resolution models
[05:36:38] <apetrescu> sorry, all previous JS is PS Pete Schoenmaker
[05:36:41] <tony1athome@jabber.org> fully routable ids
[05:36:58] <apetrescu> slide: Deployment scenarios (stolen from the LISP draft)
[05:37:10] <tony1athome@jabber.org> s1.5: ids routtable over other infrastructure
[05:37:18] <tony1athome@jabber.org> s2: id/locator mapping via DNS
[05:37:28] <tony1athome@jabber.org> s 3: new id/loc mapping
[05:38:45] <apetrescu> slide 5: Implementation loci (L O C I)
[05:39:01] <tony1athome@jabber.org> Split in ip stack (vertical)
[05:40:10] <tony1athome@jabber.org> horizontal split in (host, first hop router, site border router, isp, backbone)
[05:40:17] <apetrescu> slide 6: Identifiers: Structure and Properties
[05:40:29] <tony1athome@jabber.org> structure: hierarchical/flat/other
[05:40:38] <tony1athome@jabber.org> uniqeness: statistical/managed
[05:40:47] <tony1athome@jabber.org> API: v4/v6/both
[05:40:56] <tony1athome@jabber.org> routability: global/local/none
[05:41:06] <tony1athome@jabber.org> security: self-authenticating/not
[05:42:07] <apetrescu> slide 7: Resolution models
[05:42:18] <tony1athome@jabber.org> Query based or id-routing based
[05:42:36] <tony1athome@jabber.org> query mapping first?
[05:42:46] --- sbrim has joined
[05:42:53] <tony1athome@jabber.org> Or, route with ID, and get locator info in addition?
[05:43:24] <apetrescu> slide 8: Presentation outline
[05:43:24] <townsley@jabber.psg.com> Did the jabber room crash?
[05:43:34] <tony1athome@jabber.org> No
[05:43:46] <apetrescu> not 'crashed' until now, but one group disconnection yes.
[05:43:57] <apetrescu> not sure that's wireless or jabber
[05:44:04] <tony1athome@jabber.org> stable ids
[05:44:12] <tony1athome@jabber.org> no need for PI addrs
[05:44:14] <apetrescu> slide 9: Obvious benefits (not included in the comparison matrices)
[05:44:19] <tony1athome@jabber.org> ISP change
[05:44:25] <tony1athome@jabber.org> no NAT
[05:44:45] <apetrescu> (jabber crashed completely yesterday afternoon during manet and during mip4)
[05:44:49] <apetrescu> questioner: define stable
[05:44:57] <sbrim> that was Dino
[05:44:58] <apetrescu> PN: defines it...
[05:45:16] --- sbrim has left
[05:45:22] <apetrescu> PN: today people want to provider-eindepentendt addresses, stable addresses, provider-assigned addresses are not...
[05:45:39] <apetrescu> PN: to ease the cost of dynamics of networks renumbering, of mobility and so on, there are many places...
[05:45:46] <apetrescu> slide 10: Potential benefits
[05:46:16] <tony1athome@jabber.org> Smaller locator tables
[05:46:26] <tony1athome@jabber.org> better TE, multihomeing
[05:46:36] <tony1athome@jabber.org> more mobility and multi-access
[05:46:40] <tony1athome@jabber.org> sub-network mobility
[05:46:48] <tony1athome@jabber.org> interoperability between v4 and v6
[05:46:57] <tony1athome@jabber.org> middle boxes become first class citizens
[05:47:08] <tony1athome@jabber.org> delegable app naming
[05:47:14] <tony1athome@jabber.org> DoS protection
[05:48:27] --- elwynd has left
[05:48:29] --- elwynd has joined
[05:48:30] --- gorryf has left
[05:48:44] <apetrescu> slide 11: Background for the next slide (see the additional slides)
[05:49:03] <tony1athome@jabber.org> revis proposals vs benefits
[05:49:10] <tony1athome@jabber.org> extract options and benefits
[05:50:01] <apetrescu> slide 12: Summary
[05:50:02] <tony1athome@jabber.org> More features coming
[05:50:22] <tony1athome@jabber.org> Benefits limited if we go network based
[05:50:45] <tony1athome@jabber.org> above-IP approaches limit RIB/TE benefits
[05:50:53] <tony1athome@jabber.org> two communities
[05:51:00] <tony1athome@jabber.org> jack-up/routing focus
[05:51:11] <tony1athome@jabber.org> id/loc split / mobility focus
[05:51:26] <tony1athome@jabber.org> social or technical contrast?
[05:51:35] <tony1athome@jabber.org> One solution or two?
[05:53:00] <apetrescu> slide: scrolling
[05:53:28] <apetrescu> Iljitsch vb, Alain Durand, Erik Nordmark
[05:53:37] <apetrescu> PS: opens mmike
[05:54:07] <apetrescu> Mark Townsley: invites speakers up to dronf, Dave, John
[05:54:31] <apetrescu> Thomas Narten: open qs open discussion, helpful to focus, in a sense all you worry, what we gonna go forward...
[05:54:37] <apetrescu> TN: enough here to form WG?
[05:54:46] <apetrescu> TN: network-based vs host-based or combination?
[05:54:54] <apetrescu> TN: what existing applis API and backwards appli
[05:55:01] --- bhoeneis has left
[05:55:02] <apetrescu> TN: IP address looks as locator, unchanged
[05:55:09] <apetrescu> TN: IPv4 or IPv6 solutions or both?
[05:55:16] <apetrescu> TN: timeframe deployed in signidicafnt
[05:55:20] <apetrescu> TN: 3-4-5 years
[05:55:38] <apetrescu> TN: functions we include: mobility or smth else, or exlclusileyve routing scalability.
[05:55:41] <apetrescu> Alai D
[05:55:43] <apetrescu> Alain Durand
[05:55:46] <apetrescu> AD: slide 12
[05:55:49] <apetrescu> TN: which says?
[05:55:56] <apetrescu> AD: plese display the slide
[05:56:00] <apetrescu> TN: tough to go through slides
[05:56:08] <apetrescu> DT: in IPv6 hardest and last to change,
[05:56:12] <apetrescu> DT: thats slide 12
[05:56:25] <apetrescu> AD: we've learned smth from that, this discussion may run in reverse and bump
[05:56:34] --- stjepan.gros has left
[05:56:38] <apetrescu> AD: boxes in middle doing security control function make assumption id and locator is same
[05:56:41] <apetrescu> AD: what we care is id
[05:57:06] <apetrescu> AD: if we split, in single packet, retrieve the id from locator there's going to be huge problems in middle boxes, undeployable, non starter
[05:57:18] <apetrescu> EN: clarifyin arhci q
[05:57:27] <apetrescu> EN: rleated to rate of change of mapping function
[05:57:44] <apetrescu> EN: down the path id/loc split then some people want to use that for mobility, but quick rate of change in databse
[05:57:49] <apetrescu> EN: others want that stable
[05:58:03] <apetrescu> EN: danger, policyt for that, after midnight there's this mapping... risk of saying
[05:58:18] <apetrescu> EN: depending archi, quite some dynamic for some peole and who controls, another flavor of BGP
[05:58:25] <apetrescu> NE: is it the site or ISP?
[05:58:28] --- Mundofer has joined
[05:58:31] <apetrescu> EN: never saw this archi q in slides
[05:58:31] --- mstenber has joined
[05:58:35] <apetrescu> EN: need aware
[05:58:59] <apetrescu> ILVB: mapping database, two sorts both 20yr old: dns and bgp, both have problems in this area
[05:59:12] --- csp has joined
[05:59:19] <apetrescu> IVB: bgp doesnt scale if we want to do this, we bgp may want to do extra stuff mh and mobi.
[05:59:24] <apetrescu> IVB: cant do either of this.
[05:59:32] <apetrescu> IVB: both bgp and dns entrenched, important
[05:59:44] <apetrescu> IVB: important to build smth new from ground up, modern 21st century
[05:59:58] <apetrescu> IVB: imagines a system where you can flood and publish info that is updated, as soson as smth happens
[06:00:08] <apetrescu> IVB: but also less dynamic info, jumpign off-point
[06:00:12] <apetrescu> IVB: if...
[06:00:19] <apetrescu> IVB: if dioing mobility, different
[06:00:39] <apetrescu> IVB: if someone sends me packets, pthrough my home net, before reaches me - that's not a problem if ic can do ooptim... later.
[06:00:54] <apetrescu> IVB: smart systems can do this w/o having to scale to what mobi needsm and mh.
[06:01:12] <apetrescu> IVB: Dave's slides, first half, he has good limitation of what we can /cant do, shim6 undeployable
[06:01:19] <apetrescu> IVB: shim6 hard, with IPv4 harder
[06:01:32] <apetrescu> IVB: either middleboxes, site-exit routers or ISP networks - they're the incentives
[06:01:42] <apetrescu> IVB: if you leave out to the inside.. take 20yr
[06:01:58] <apetrescu> DW: matches one of my points, incremental deployability, cookie at every break (laughs)
[06:02:19] <apetrescu> DW: resolve this, handle, routing community incremental deploymentability is required, primary goals: increm deploy...
[06:02:26] <apetrescu> DW: those who believe yes raise hands
[06:02:27] <gih900> incremental deployment is truly the only way forweard
[06:02:38] --- jpc has left: Lost connection
[06:02:55] <apetrescu> IVB: if we want to solve this problem, I have this id/loc split in some way, it makes sense to build from ground up
[06:03:03] <apetrescu> IVB: rather than mapping systems we have today
[06:03:05] <gih900> The experience with disruptive deployments is that the drivers for such deployment require massive changes in the service model and the service economics
[06:03:12] <tony1athome@jabber.org> Does SIN count as incremental deployability?
[06:03:12] <apetrescu> IVB: engineering it properly is deployabele
[06:03:24] <apetrescu> PN: youre speaking about what Dave and I refer about
[06:03:31] <apetrescu> PN: horizontal is deploiyment consensus
[06:03:44] <apetrescu> PN: when you decide which point of stack, multiple pojnts of time
[06:03:52] --- dcrocker has joined
[06:03:57] <apetrescu> PN: you can cheat in meantime by reusing existing infra, for doing that in small scale
[06:04:14] <apetrescu> PN: different dimesnions here, you need deplopyabaility, but at the end of day maybe new infra is needed.
[06:04:23] <apetrescu> TN: a long line, point of order. 2 minutes per person.
[06:04:24] --- csp has left
[06:04:29] <apetrescu> LZ: one minute only
[06:04:42] <apetrescu> LZ: repeats q, is this for how long solution space exploration?
[06:04:53] --- dcrocker has left
[06:04:55] <apetrescu> LZ: some presentations are ... this is job RRG, I came here see wishes
[06:05:18] <apetrescu> LZ: eg renumbering there's still lots of people thinking renumbering is automated, others say its way beyond that
[06:05:24] <apetrescu> LZ: deal ... new archi
[06:05:30] <apetrescu> Jari Arkkko
[06:06:00] <apetrescu> JA: touch to answer, agrees, we do need to focus with reqs, biggest when out of mtg, are we addressing all these things or focusing on service provider needs?
[06:06:03] <apetrescu> Mark Townsley
[06:06:09] --- raeburn@mit.edu has left
[06:06:13] --- lebobits has joined
[06:06:31] <apetrescu> MT: we want to look at design boundaries, there's a point where you have to break and start giving, balance talk problem and getting solution, this mtg strikes balance
[06:06:43] <apetrescu> MT: we want to talk about what kinds of solutions, and if engi then WG
[06:07:02] <lebobits> lines are way too long to go to mic
[06:07:10] --- jpc has joined
[06:07:12] <lebobits> so might try to voice here
[06:07:19] <apetrescu> MW: likes to see form a WG, not know Charter (laughs), this work should happen in the greater communi and type of , like Wg, but we need time figure out Charter, I love idea interim meetin gin May
[06:07:27] <apetrescu> MW: opportunitstic
[06:07:31] <shep> Where will the meeting be, and which week in May will it be???
[06:07:34] <apetrescu> MW: eventually WG, but Charter?
[06:07:37] <lebobits> Think a WG is too small to address this
[06:07:46] <shep> (May is 5 weeks away.)
[06:07:48] <apetrescu> MW: solution for IPv4 and IPv6 endnonde applis, service level they get may be different,
[06:08:12] <apetrescu> MW: reasonable if IPv4 solution had, because limitation address space, different space numbering system, perhaps
[06:08:27] <apetrescu> MW: part of limitation of NAT, might be able to do smth better in IPv6, be open to that sort of possibliity
[06:08:30] <lebobits> probably need an area, w/ different WGs in it to draw a wide enough audience of experts in different areas of focus
[06:08:44] <apetrescu> MW: there'll be IPv6 in endsinde, but cant assume there'll be IUPv4 only endside of nodes
[06:09:01] <apetrescu> MW: where solution new mapping function? from RRG? WG has to focus on smth else
[06:09:18] <apetrescu> MW: honestly thinks its gonna require breakthroughs to come up with a new mapping funciton
[06:09:25] <gih900> I think a Working Group would be very tough right now - there are many questions and many perspectives and frankly this is an area that requires real trade-odffs as there is no Universally Acceptable solution
[06:09:31] <apetrescu> MW: not like ther'es every possible mapping funciton out there an dpic ko one
[06:09:37] --- stjepan.gros has joined
[06:09:53] <apetrescu> HS: agrees with 99.99999% in presentaiton, should be a concernt o all of us (laughs)
[06:10:09] --- stjepan.gros has left
[06:10:11] <apetrescu> HS: looking at problem, different people, kind of years late. We all pretty much all know what are the solution, whats the gap?
[06:10:21] <shep> Perhaps there should be a new area within the IETF. Two ADs and a bunch of WGs and BOFs.
[06:10:22] <apetrescu> HS: hard to answer any q, bcause there's no input,..
[06:10:23] <gih900> Trade-offs are not well handled in a working group context simply becuase workig groups in rough consensus mode tend to compromise by accepting almost everything. So as a working group problem it would be highly challenging
[06:10:29] <apetrescu> HS: which area if WG?
[06:10:36] <apetrescu> HS: where's missing porotocol that needs to modify?
[06:10:42] <apetrescu> MT: exactly
[06:10:46] <apetrescu> HS: plenary last nite
[06:10:53] <apetrescu> MT: where the gaps, what should we charter?
[06:11:03] <apetrescu> MT: write on in terms of _that_'s we need to unstand.
[06:11:21] <apetrescu> HS: good step maybe smth that can be send to int-area or new mailing list, divide problem in subproblems...
[06:11:26] <apetrescu> DW: can you explain?
[06:11:55] <apetrescu> DW: members of rope directorate, no 1 thing is in Charter, try to write this down, try to id the problems, space, when we have smth written down...
[06:12:17] <apetrescu> TN: we had a meeting of directors, a first smth circulate to community decide wht the ps problem is.
[06:12:21] <apetrescu> HS: gapa analysis in that ps.
[06:12:26] <apetrescu> Ross Callon
[06:12:36] <apetrescu> RC: some thins we agree (my throat is unhappy)
[06:13:03] <apetrescu> RC: emergent problem, I see a lot people lot of experience in Internet, willing to work on, really ready to invest, their companies money theyr own time go
[06:13:08] --- bensons has joined
[06:13:10] <apetrescu> RC: wilingness try do quickly
[06:13:32] <apetrescu> RC: we dont agree on timeline, not precieslye on problem is, what the universe of diesrianble solutions is, best next step
[06:13:46] --- stjepan.gros has joined
[06:13:53] <apetrescu> RC: occured to him if you look at smbdy who believes... asking that sperson to implement solution tomorrow - not a good idea.
[06:14:12] <apetrescu> RC: useful to have different people work on different areas, best have people work on their problems.
[06:14:23] <apetrescu> RC: if some people believe no problem, then productive for them to work on
[06:14:39] <apetrescu> RC: iwhat is the universal possible solution and tradeoffs?
[06:14:46] <apetrescu> RC: implement and test prototype tomorrow?
[06:14:58] <apetrescu> RC: focus on hard problems if so some think.
[06:15:08] <apetrescu> RC: how is the mapping function.. before trust ...
[06:15:21] <apetrescu> RC: some hard problems I see: where is the mapping done, what sort, how dynamic, how big
[06:15:24] <apetrescu> RC: transition
[06:15:31] <apetrescu> RC: with partial deployments, how to secure all this
[06:15:37] <apetrescu> RC: allign cost and benefits
[06:15:51] <apetrescu> RC: scale? all in DNS? that might be aligned cost/benefit.
[06:15:59] <apetrescu> PS: Ross, long line, please.
[06:16:10] <apetrescu> RC: we disagree on what next, nonethelss we dont have to be disagreeable.
[06:16:27] <apetrescu> RC:...
[06:16:32] <resnick> In school when I was on the debate team, they taught a small course called "word economy." Perhaps we should have that class taught at the IETF.
[06:16:52] --- sureshk has left
[06:16:53] <apetrescu> RC: quotes grandmother
[06:16:56] <gih900> thanks Ross - good perspective here about the scope of the diversity of perspectives at play here and some ideas as to how to proceed effectively
[06:17:20] <apetrescu> .. hesham
[06:17:32] <apetrescu> why pu ton slides requirement of q to hide locators?
[06:17:37] <shep> Very good point RC has made. We need alternatives, and the alternatives need the opportunity to grow.
[06:17:45] <apetrescu> ..h: why such thing on slide?
[06:17:47] <jclee> Alex, always thanks for scribing ;-)
[06:17:53] <gih900> And the alternatives need to 'compete' in some fashion
[06:18:01] <apetrescu> TN: old slide, but pepole do...
[06:18:09] <gih900> Which is certainly what we've done already with HIP and SHIM6 and SCTCP and...
[06:18:15] <apetrescu> DT: in MIP RO, if not RO, if you have a number of area code...
[06:18:22] <apetrescu> ..h: always someone out
[06:18:25] <apetrescu> DT: hard to hear
[06:18:33] <apetrescu> ..h: area code is visible
[06:18:43] <apetrescu> DT: best analysis phone number
[06:18:45] <apetrescu> Fred Templin
[06:18:57] <apetrescu> FT: in Pekka's slide, jack-up people and loc/id people split.
[06:19:01] --- stjepan.gros has left
[06:19:05] <apetrescu> FT: jackup solution not limited ...
[06:19:15] <apetrescu> FT: loc/id is not loose inside of the areas type of things...
[06:19:27] <apetrescu> PN: two communities, you're right
[06:19:31] <apetrescu> Vidya Narayanan
[06:19:38] <apetrescu> VN: from router supports, ram list glad is up
[06:19:45] <apetrescu> VN: interested to form a WG?
[06:19:57] <apetrescu> VN: Internet deployabaility, archi going to do it, not sure one solution solves
[06:20:15] <apetrescu> VN: other problems in problem states like mobility and that
[06:20:15] <apetrescu> VN: scalability in different perepsepctive
[06:20:15] --- marshall has joined
[06:20:18] <apetrescu> VN: consult both by same...
[06:20:21] <apetrescu> VN: what's there...
[06:20:48] <apetrescu> JA: we actually plan to have divide/conquer approach, we have RRg, we have this mtg, for this mtg makes sense (for IETF) look at short term
[06:21:01] <apetrescu> JA: that we can do based on what can be delployed,
[06:21:05] <apetrescu> JA: we are looking at other stuff, but in the gr
[06:21:18] <apetrescu> Danny McPherson
[06:21:47] <apetrescu> DMP: network or host? at the end of the day, host is challenge, state in network is somth you have to have, incremental deploy no flag day
[06:22:13] <apetrescu> DMP: when you guys presnet, recommend you represent Int community or Routing community please
[06:22:33] <apetrescu> DMP: when you speak that you say 'thi is is what rtg community believes' no t sure consensus careful
[06:22:49] <apetrescu> EN: what scope of this potential WG?
[06:23:05] <apetrescu> EN: total scope is very big, different components, what would be done here vs rrg (hard time to see)
[06:23:14] <apetrescu> EN: JA said not worry about smth
[06:23:23] <apetrescu> EN: if we do that... then those things wont match.
[06:23:40] <apetrescu> EN: not see how we can get to that point wo understanding archi, premature WG go on.
[06:23:46] --- dthaler has left
[06:23:52] <apetrescu> MT: the q is ithat if there are pieves about this...
[06:24:00] --- tim.polk has left: Replaced by new connection
[06:24:05] <apetrescu> MT: when we define this with.. these things will be more clear.
[06:24:11] <apetrescu> JA: definitely not chartering now
[06:24:27] <apetrescu> LZ: this has knows pop, from a rtg area problem.
[06:24:55] <apetrescu> MT: this is was specifically for id/loc split design and problem space. we asked for inpt from rtg esperts, brought last 6 mths emergency
[06:25:06] <apetrescu> MT: this afternoon they talk in rtg area, but not id/loc split.
[06:25:13] <apetrescu> MT: two things to mention, tomorrow
[06:25:16] --- marka has left
[06:25:33] <apetrescu> LZ: maybe my misunderst, whether it makes sense to make archi changes, not many....
[06:25:48] <apetrescu> TN: much more open ended q, we try to scope, any change here should address rtg concern
[06:25:52] <apetrescu> Tim Chown:
[06:25:56] <apetrescu> TC: managebaility
[06:26:14] --- marka has joined
[06:26:20] <apetrescu> TC: learnt from IPv6 from we need to idenify smae nodes, IPv4 and IPv6 addresses, many solutions proposed.
[06:26:49] <apetrescu> TC: IPv6 seen as stumbling block. I think that pt of view you have to underst id/loc, there has to be some way for management tools to udnerst know what's going on
[06:26:58] <apetrescu> TC: ops area? well they should be discussed ...
[06:27:09] <apetrescu> 9forgot name)
[06:27:33] --- lars.eggert@googlemail.com has left
[06:27:34] <apetrescu> questioner: interest of capacity, in longer terms, debate, lots of discussion...
[06:27:55] <apetrescu> this is an importnat point, there... how is the system working today for future.
[06:28:13] <andrewdmcgregor@jabber.psg.com> Wants to see numbers
[06:28:14] <apetrescu> q: is there any need for further analysis of quantititiave assessment vs just qualitiative analysis.
[06:28:33] <apetrescu> q: assessment of what the system should support in the future.
[06:28:50] <apetrescu> quantitative work in future system will support.
[06:29:04] <apetrescu> MW: relays message
[06:29:29] <apetrescu> DW: in rtg system, has been discussed in other WG as well, some data will be presented
[06:29:40] --- lebobits has left: Logging off
[06:29:41] <apetrescu> q: any intention to continue on this kind of analysis?
[06:29:49] <apetrescu> DW: until designed difficult to analyse
[06:30:00] <apetrescu> DW: clearly... we have to understand the impact its going to have.
[06:30:06] <apetrescu> DW: should we form a WG or not?
[06:30:18] <apetrescu> DW: for those working on solutions, do they feel there's an outlet,
[06:30:29] <apetrescu> DW: experimental, informational... is this a home for this?
[06:30:32] <apetrescu> DW: Rrg?
[06:30:36] <apetrescu> room: yes, no
[06:31:09] <apetrescu> DF: from a protocol implementers perspective, hard questions with easy answers, good provides direction going forward, otehrwise I think difficult decisions in vacuum
[06:31:17] --- bensons has left
[06:31:25] <apetrescu> DF: can we use same solutions for ipv4 and ipv6?
[06:31:30] <apetrescu> DF: should we?
[06:31:33] <apetrescu> room: must
[06:31:54] <apetrescu> DT: solutions that use the same preferred, if possible, its preferred
[06:32:03] <apetrescu> DF: do you believe we have a short and long term solution
[06:32:14] <apetrescu> chadefine short and long
[06:32:32] <apetrescu> JA: we do believe negineering-type right now, and also longer term with... that as well, both.
[06:32:34] --- peetu has left: Logged out
[06:32:48] <apetrescu> DF: long term is going is to be replaced (but if it takes too long wont)?
[06:32:49] --- andrewdmcgregor@jabber.psg.com has left
[06:33:00] <apetrescu> DF: cant make operators turn too often, you have to air in simplicity
[06:33:18] <apetrescu> PS: long term should take short term into considerations, need to look at both
[06:33:38] <apetrescu> PC: what we can do we can try to make short term solutions make forward compatible, no guaranteee it will work
[06:33:52] <apetrescu> DF: short term solution should be in the hands of people to deploy?
[06:33:55] <apetrescu> speaker
[06:34:01] <apetrescu> speaker near chairs says.
[06:34:16] <gih900> John Scudder says that a short term solution will linger forever!
[06:34:19] <apetrescu> DF: what do you think needs to be deployed
[06:34:28] <apetrescu> room: why do you ask these questions
[06:34:46] <apetrescu> DW: short term solution should be deployable for IPv4 addresses in enterprise, which may have occured.
[06:35:05] <apetrescu> TN: idea of shortterm solution misnomer, if solution, then future.
[06:35:13] <apetrescu> DF: short term will take one or two problem statements.
[06:35:26] <apetrescu> DF: fast mobility is non starter for shor tterm
[06:35:29] --- stbryant has left
[06:35:42] <apetrescu> DW: are there multiple solutions for thiese problems, restating your answer
[06:36:05] <apetrescu> DF: we need careful we dont have preferred solutions, Internet hard to run, smart people, invalidate build something new.
[06:36:16] --- marka has left
[06:36:17] <apetrescu> DF: on simplicity, problems we try to solve are the ones we solve.
[06:36:23] <apetrescu> DF: really hard decision.
[06:36:30] --- brabson has left
[06:36:32] <apetrescu> TN: 5minutes after. 1min per person.
[06:36:35] --- marka has joined
[06:36:38] --- Mundofer has left
[06:36:43] <apetrescu> TN: line is closed after MW
[06:36:49] <apetrescu> LZ: I agree with dino.
[06:37:08] --- behcet.sarikaya has left
[06:37:10] <apetrescu> LZ: summarize , document, last ,, attachment, anyody interested in solution please subscribe to rrg mailing list, thank
[06:37:11] <apetrescu> you
[06:37:15] <apetrescu> Tim Shepard
[06:37:32] <apetrescu> TS: best possible... we need alternatives implemented and demonstrated.
[06:37:43] --- Magnus W has left
[06:37:57] --- menno pieters has left
[06:37:57] <apetrescu> TS: one my frustration, the only thing they come off and implemented, has problems, I wish there were 1000 people, and argue which implementaiton is better...
[06:38:20] <apetrescu> TS: no archi changes at IETF, we're stuck on this archi... diversity, natural selection nto so good, I'd like to see Dino meeting on a plane.
[06:38:29] <apetrescu> Eric (schmidt>?)
[06:38:38] <apetrescu> E: research is what, and engineering is.
[06:38:48] <apetrescu> E: role of what happens in rrg will consider.
[06:39:00] <apetrescu> E: people have to contribute to that discussion. scope of work is not clear.
[06:39:06] <apetrescu> E: not because we define the work...
[06:39:18] <tony1athome@jabber.org> Aaron Falk, chair of IRTF
[06:39:32] <apetrescu> MW: I subscribe to RRG, I have concerns maybe poweropoint , new mechanisms that can become technology
[06:39:35] --- Suzanne has joined
[06:39:41] <apetrescu> MW: designing a solution or archi shouldnt happen in RG.
[06:39:52] <apetrescu> MW: not same principles of oppennes.
[06:40:15] <apetrescu> MW: maybe its ignorance but lot of stuff we sit up here, so many people trying to contribute, not sure RG has that.
[06:40:18] <apetrescu> JA: concluding remarks
[06:40:29] <apetrescu> JA: clear we dont fully understand the problem, no agreement on what .
[06:40:40] --- iljitsch has left
[06:40:43] --- tony1athome@jabber.org has left
[06:40:58] <apetrescu> JA: would like to see on overall problem statement, we as IETF, this BoF needs to figure out whether there's a specific problem that we can address with id/loc separation
[06:41:09] --- venaas has left: Disconnected
[06:41:09] --- dowstreet@jabber.postel.org has left: Logged out
[06:41:20] <apetrescu> JA: we need to get Dino's implementation and coding tryied out out therem, we need to keep contribute the discussion in RRG, I want
[06:41:22] <apetrescu> JA: poll
[06:41:33] <apetrescu> JA: interim meeting, if, then how much people in this room?
[06:42:01] <apetrescu> JA: not consensus on location, need to look at calendar, volunteer to
[06:42:11] <apetrescu> MT: assuming you have to fly, interest of interim meeting in May
[06:42:16] <apetrescu> MT: that was like 30 people.
[06:42:20] --- dward@jabber.org has left
[06:42:23] <apetrescu> JA: given this interest seems we can do it.
[06:42:26] --- vidya has left
[06:42:26] --- marshall has left
[06:42:27] <shep> He said "that was 30 people" but it looked closer to 60 to me.
[06:42:31] --- nov has left
[06:42:35] --- cabo has left
[06:42:38] <apetrescu> JA: more documents, discuss in RAM please, and code.
[06:42:40] --- resnick has left
[06:42:48] <apetrescu> seems to be adjourned I stop here.
[06:42:48] --- shikob has left
[06:42:49] --- Suzanne has left
[06:42:50] --- dudi has left
[06:42:53] --- farinacci@gmail.com has left
[06:42:53] --- dku has left: Computer went to sleep
[06:43:08] --- jyg has left
[06:43:10] --- jclee has left
[06:43:12] --- gih900 has left
[06:43:14] --- rhe has left
[06:43:15] --- pds@jabber.gin.ntt.net has left
[06:43:16] --- shep has left
[06:43:26] --- arifumi has left
[06:43:36] --- saphira@jabber.no has left
[06:43:46] --- mstenber has left
[06:43:54] --- shinta has left
[06:44:38] --- tsavo_work@jabber.org/Meebo has left
[06:45:35] --- jgs@jabber.org has left
[06:45:39] --- r.szabo has left
[06:47:06] --- joelja has left
[06:47:12] --- joelja has joined
[06:48:21] --- elwynd has left
[06:48:37] --- joelja has left: Replaced by new connection
[06:48:50] --- joelja has joined
[06:51:51] --- townsley@jabber.psg.com has left
[06:51:52] --- ldondeti has left: Disconnected.
[06:52:12] --- joelja has left
[06:53:00] --- becarpenter has left
[06:54:28] --- marka has left
[06:54:36] --- marka has joined
[06:57:20] --- becarpenter has joined
[06:59:43] --- apetrescu has left
[07:00:15] --- ltn22@jabber.org has left
[07:04:36] --- jlcjohn has left
[07:15:09] --- jpc has left
[07:18:40] --- jariarkko has joined
[07:20:13] --- elwynd has joined
[07:36:10] --- becarpenter has left
[08:04:22] --- fujiwara has left: Replaced by new connection
[08:17:29] --- stbryant has joined
[08:19:16] --- stbryant has left: Replaced by new connection
[08:31:24] --- pesherb has joined
[08:48:14] --- pesherb has left
[08:53:37] --- pesherb has joined
[08:53:47] --- pesherb has left
[09:00:32] --- pesherb has joined
[09:07:17] <pesherb> do they have a scribe at rtg?
[09:41:41] --- jariarkko has left
[10:00:39] --- elwynd has left
[10:30:13] --- elwynd has joined
[11:16:50] --- pesherb has left
[11:56:20] --- elwynd has left
[12:02:51] --- marka has left: Replaced by new connection
[12:02:52] --- marka has joined
[12:02:59] --- elwynd has joined
[12:05:21] --- elwynd has left
[13:24:21] --- marka has left
[13:47:57] --- marka has joined
[13:59:24] --- marka has left