Times are in EDT, one hour ahead of Chicago.

Conversation with rrg@jabber.ietf.org at 07/27/2007 09:17:49 AM on sbrim@jabber.org/Gaim (jabber)
(09:17:50 AM) sbrim [sbrim@jabber.org/Gaim] entered the room.
(07/27/2007 02:07:52 AM) tony1athome: Testing
(09:17:50 AM) rrg@jabber.ietf.org: The topic has been set to: 
(09:47:07 AM) catx [cat-xeger@im.usdn.net/Adium] entered the room.
(09:49:02 AM) catx left the room.
(09:57:36 AM) tony1athome [tony1athome@jabber.org/Adium] entered the room.
(09:57:45 AM) tony1athome: Good morning...
(09:57:53 AM) sbrim: Hi
(09:58:21 AM) tony1athome left the room.
(09:59:22 AM) kazuya [kazuya@jabber.org/Exodus] entered the room.
(09:59:44 AM) csp [csp@jabber.org/University of Glasgow] entered the room.
(10:00:26 AM) iljitsch [iljitsch@gmail.com/nirrti] entered the room.
(10:05:04 AM) sbrim: are any of you actually in the room?
(10:05:15 AM) Melinda [mlshore@jabber.org/Psi] entered the room.
(10:05:20 AM) nm [nm@jabber.org/Exodus] entered the room.
(10:05:29 AM) arifumi [arifumi@12jabber.net/Exodus] entered the room.
(10:05:39 AM) dowstreet@jabber.postel.org [dowstreet@jabber.postel.org/Adium] entered the room.
(10:05:40 AM) shep [shep@jabber.psg.com/Psi] entered the room.
(10:05:45 AM) iljitsch: ah
(10:05:50 AM) gih900 [gih900@jabber.psg.com/Exodus] entered the room.
(10:05:51 AM) Melinda: Hi, Scott - hope all is well.  I'm in TAM
(10:05:55 AM) ***iljitsch is jabber scribe for part of the day
(10:05:57 AM) cabo [cabo--tzi--org@jabber.org/Adium] entered the room.
(10:05:58 AM) mjo [mjo@jabber.org.au/emacs] entered the room.
(10:05:58 AM) lixia [lixia@jabber.postel.org/Lixia's Computer] entered the room.
(10:06:01 AM) sbrim: thanks
(10:06:12 AM) iljitsch: no scheduled breaks, no cookies but there will be a break at some point
(10:06:15 AM) iljitsch: agenda bashing
(10:06:24 AM) sbrim: slides at http://www.ietf.org/audio//ietf698.m3u
(10:06:32 AM) sbrim: I mean, audio
(10:07:00 AM) iljitsch: agenda proposal: first dino, then elliot, dave, luigi
(10:07:13 AM) jlcjohn [jlc69john@jabber.org/Psi] entered the room.
(10:07:15 AM) iljitsch: change accepted
(10:07:31 AM) iljitsch: tony li: design goals
(10:07:33 AM) iljitsch: we have a draft
(10:07:41 AM) iljitsch: want to go throug the changes
(10:07:56 AM) iljitsch: comments not absorbed yet due to vacation
(10:08:15 AM) iljitsch: 3.1 terminology change: routing plane -> control plane
(10:08:40 AM) iljitsch: also added: strongly desired that control plane scale independently from...
(10:09:05 AM) iljitsch: 3.6: changed "needed" to "required"
(10:09:16 AM) iljitsch: 3.8: new criterium: stability
(10:09:24 AM) iljitsch: rearranged reference
(10:09:29 AM) yone [yone@jabber.org/Exodus] entered the room.
(10:09:38 AM) yoshfuji [yoshfuji@jabber.org/Gaim] entered the room.
(10:10:04 AM) iljitsch: 3.9: clarification: not current level of security as of publication, but level current when solution is deployed
(10:10:39 AM) iljitsch: 3.10: solutions required to be deployable from a technical perspective, not touching other perspectives
(10:11:40 AM) iljitsch: lixia:
(10:11:48 AM) dthaler [dthaler@jabber.org/Exodus] entered the room.
(10:11:53 AM) iljitsch: if you can't hear me, it's no important
(10:11:58 AM) sbrim: I can hear :-)
(10:11:59 AM) iljitsch: (microphone trouble)
(10:12:15 AM) iljitsch: lixia about taxonomy
(10:12:24 AM) sbrim: it's good, as long as they repeat audience questions into the mike
(10:12:31 AM) iljitsch: prepared with Scott Brim(m?)
(10:12:40 AM) sbrim: Brim
(10:12:42 AM) sbrim: as in sbrim :-)
(10:13:03 AM) jgs@jabber.org [jgs@jabber.org/Adium] entered the room.
(10:13:09 AM) dudi [dudisaki@jabber.org/Exodus] entered the room.
(10:13:37 AM) iljitsch: framework didn't fall out of the blue sky
(10:13:48 AM) iljitsch: looked at solutions
(10:14:05 AM) iljitsch: process not finished yet, what I say is not complete
(10:14:13 AM) iljitsch: framework will become better over time
(10:14:32 AM) iljitsch: if you see anything that's missing or is incorrect, let us know
(10:14:49 AM) iljitsch: terminology: GRA: globally routable address space
(10:15:01 AM) iljitsch: (scribe: not GRAS?)
(10:15:13 AM) sbrim: hm, a GRA is just "globally routable address".  I hadn't noticed "space" on that slide.
(10:15:18 AM) iljitsch: problem: too many entries in GRA, too many updates
(10:15:26 AM) iljitsch: solutions...
(10:15:50 AM) washad [washad@jabber.org/Psi] entered the room.
(10:15:52 AM) iljitsch: mike: religion about keeping routing table small, but this comes at a cost
(10:15:55 AM) iljitsch: (dave meyer?)
(10:15:57 AM) sbrim: that's Dave Meyer
(10:16:05 AM) iljitsch: haven't discussed tradeoffs
(10:16:08 AM) iljitsch: lixia: good point
(10:16:24 AM) iljitsch: questions interrupt or at the end?
(10:16:30 AM) marshall [marshall@jabber.isoc.org/Marshall Eubanks s Computer (5)] entered the room.
(10:16:59 AM) iljitsch: proposed solutions:
(10:17:12 AM) marshall: proposed solutions
(10:17:38 AM) iljitsch: a1: only use topologically aggregatable address space = multihoming -> multiple addresses (GSE, shim6, Six/One)
(10:18:00 AM) Tony Li [tony1athome@jabber.org/Adium] entered the room.
(10:18:25 AM) iljitsch: a2: move "edge" prefixes out of global routing system by tunneling
(10:19:24 AM) iljitsch: dino and lisp folks use ETR/ITR terminology, I didn't
(10:19:40 AM) marshall: egress tunnel router
(10:19:46 AM) marshall: ingress tunnel router
(10:19:58 AM) iljitsch: (sorry I always mix up itr / etr)
(10:20:12 AM) marshall: Geoff Huston : Beware of false dichotimies
(10:20:15 AM) iljitsch: geoff: beware of false dichotomies, is there an a3?
(10:20:26 AM) iljitsch: lixia: not complete, but no a3 at this time
(10:20:42 AM) marshall: Geoff : you have the ability to numberthe network, not the edges
(10:20:47 AM) jpc [juampe.cerezo@gmail.com/Adium9BCCD7F4] entered the room.
(10:21:28 AM) sbrim: This is just categorizing things that have actually been submitted here.  There may be more ideas out there, and we're hoping that we can establish dimensions along which we can evaluate new concepts as they are proposed, but we don't have all possible approaches listed.
(10:21:38 AM) marshall: lixia: you can recursively apply a2
(10:21:52 AM) marshall: Geoff : I think that there are more
(10:22:00 AM) marshall: lixia: send a more precise description
(10:22:27 AM) marshall: Q : Do you have an example ?
(10:22:35 AM) sbrim: aaaaaaaaaaa :-)_
(10:22:45 AM) ks [keiichi_shima@jabber.org/Adium] entered the room.
(10:22:45 AM) marshall: Geoff : MPLS moves out of those dichitomies
(10:23:08 AM) marshall: Geoff : I was asked for a quick example, I gave one off of the top of my head
(10:23:33 AM) sbrim: I don't get his point
(10:23:40 AM) marshall: Geoff : The tokens in the routing system might be how to get rid of the packet relative to you, not necessarily relative to the destination
(10:23:49 AM) marshall: [I am not sure what that means]
(10:24:30 AM) sbrim: maybe it means the packet is tagged with my egress, as opposed to my destination's ingress ??  But that's the way we're all doing it already.  ?
(10:24:36 AM) marshall: lixia: For some solutions the mapping happens at the border router
(10:24:57 AM) marshall: lixia: for others, like shim6, it happens inside the host
(10:25:03 AM) marshall: lixia: 3 questions
(10:25:07 AM) gih900: Scott: where is the slide pack that Lixia is using (url?)
(10:25:15 AM) marshall: lixia: Geoff may have more 
(10:25:27 AM) marshall: lixia: Q1 How do you get mapping information
(10:25:31 AM) sbrim: I don't see it on the web.  We were still fixing them this morning.
(10:25:39 AM) marshall: lixia: how do you detect reachability failures
(10:25:42 AM) sbrim: Ask her if she has it up for FTP somewhere
(10:25:55 AM) sbrim: Geoff: please do send mail about what you said.
(10:25:58 AM) gih900: she's talking - I though you may have a copy :-)
(10:26:05 AM) sbrim: I do ... I'll send it
(10:26:06 AM) gih900: I'll send mail
(10:26:17 AM) marshall: lixia: I forgot : in some designs, we assume that CE may be the ETR []
(10:26:34 AM) marshall: lixia: Question 3 : When you detect the failure, how do you handle it
(10:26:49 AM) marshall: lixia: will elaborate more in future slides
(10:27:07 AM) marshall: lixia: also abuse issue and the scalability issue
(10:27:27 AM) marshall: lixia: what is the assumption of the size of the row
(10:27:48 AM) marshall: Question : You don't have how to update mapping info
(10:27:54 AM) marshall: lixia:  this will be included later
(10:28:02 AM) satoru [satoru.matsushima@jabber.jp/Exodus] entered the room.
(10:28:09 AM) marshall: [questioners please state names !]
(10:28:26 AM) marshall: lixia: Question 1 - elaboration
(10:28:52 AM) marshall: lixia: Suppose that our campus has three providers
(10:28:59 AM) marshall: lixia: who holds this information
(10:29:18 AM) marshall: lixia: Q1.1 how to inject the mapping information into the system
(10:29:29 AM) marshall: lixia: Q1.2 who holds this information
(10:29:50 AM) marshall: lixia: The holder and the user are not necessarily the same entity
(10:30:04 AM) marshall: lixia: two kinds of updates
(10:30:18 AM) marshall: lixia: one is changes in mapping information, like dropping a provider
(10:30:41 AM) marshall: lixia: this is separate time granularity from the second, which is topology failures
(10:30:46 AM) marshall: lixia: when a router goes down
(10:30:49 AM) marshall: lixia: etc
(10:31:09 AM) marshall: lixia: How does one get mapping information into the system
(10:31:41 AM) bruce [b@bruce-2007.zerlargal.org/Adium] entered the room.
(10:31:44 AM) marshall: lixia: the second way the mapping happens when the packet is injected
(10:31:49 AM) marshall: [I missed the first one]
(10:32:37 AM) marshall: lixia: How you get this information out - some proposals will mention the specifics - the security question 
(10:32:45 AM) arifumi left the room (Replaced by new connection).
(10:33:01 AM) marshall: lixia: is an important consideration, so that you don't get misdirected to the wrong site
(10:33:17 AM) marshall: lixia: You can push or pull this information
(10:33:33 AM) marshall: lixia: push = flood
(10:33:45 AM) marshall: lixia: security is a critical component
(10:33:55 AM) marshall: lixia: how to detect failures is very important
(10:33:58 AM) sbrim: She distinguishes "flood" as general and "push" as more specific, as to who gets sent the information.
(10:34:25 AM) marshall: lixia: we have a routing system to that inside the local address space, or at least this is the defaukt
(10:34:34 AM) marshall: lixia: do not harm is one of the principles
(10:34:46 AM) gih900: Scott  - an automated flood of ROW to GRA mappings is just a reinvention of BGP - right?
(10:34:58 AM) marshall: lixia: when the mapping happens at a edge router (this is a new issue we do not have today)
(10:34:59 AM) gih900: i.e. its precisely the same as the automated flood of ROW to nexthop
(10:35:26 AM) iljitsch: geoff: not necessarily, IMO. BGP works across multiple hops, a system like this wouldn't necessarily have hops
(10:35:40 AM) marshall: lixia:  today, a failure along one path results in a prefix withdrawl and the data flow will move to other paths
(10:36:04 AM) iljitsch: so it could be like iBGP, not eBGP
(10:36:12 AM) marshall: lixia: if the routing system stops at the border of a cloud
(10:36:28 AM) marshall: then BGP updates will not cover a path update [outside of the cloud]
(10:36:44 AM) marshall: lixia: the ETL [?] prefix is not in the routing system
(10:37:03 AM) arifumi [arifumi@12jabber.net/Exodus] entered the room.
(10:37:05 AM) marshall: lixia: Means for  failure detection
(10:37:17 AM) marshall: lixia:  given that the routing system cannot handle these failures
(10:37:23 AM) marshall: lixia: how can you detect them ?
(10:38:02 AM) marshall: lixia: if you put the mapping information into the source host - shim6 relies on the upper layers to detect the errors
(10:38:28 AM) marshall: lixia:  In A2 a new thing will have to detect these 
(10:38:34 AM) sbrim: Internet omnia in duo partes divisa est
(10:38:42 AM) marshall: lixia: what I have seen relies on ICMP messages or their equivalent
(10:39:19 AM) dudi left the room (Replaced by new connection).
(10:39:39 AM) dudi [dudisaki@jabber.org/Exodus] entered the room.
(10:39:54 AM) marshall: Q : There is another factor - you can rely on symmetric paths
(10:40:14 AM) sbrim: who is it?
(10:40:21 AM) dthaler: Erik Nordmark
(10:40:23 AM) marshall: lixia: how to handle failures
(10:40:24 AM) sbrim: aha
(10:40:31 AM) sbrim: we can't assume symmetric paths
(10:40:37 AM) marshall: lixia: when the host handles failures
(10:40:45 AM) marshall: [Erik was hard for me to hear]
(10:41:01 AM) sbrim: you should try the audio feed :-)
(10:41:10 AM) iljitsch: I think Erik's point was that at the edge, you see both directions but due to asymmetric paths, you generally don't in the middle
(10:41:18 AM) sbrim: aha, got it
(10:41:22 AM) dthaler: Erik's point is that the end host (and in some cases routers very close to them) can see symmetric paths and can do more
(10:41:34 AM) sbrim: thanks all
(10:41:41 AM) dthaler: (iljitsch beat me to it :)
(10:41:46 AM) marshall: lixia: there is no free lunch. If we take the A2 approach the packets have gone into the system. How do you handle inflight packets when a failure is detected
(10:42:00 AM) marshall: lixia: failures are hopefully not permanent
(10:42:10 AM) arifumi left the room (Replaced by new connection).
(10:42:25 AM) marshall: lixia: even for Shim6, hosts try to keep up with the status of the different destinations
(10:42:38 AM) marshall: lixia: for A2, we will see later how this is handled
(10:43:00 AM) marshall: Dino ; In the core of the network, how to handle failures is well known
(10:43:07 AM) marshall: lixia: there are two additional factors
(10:43:24 AM) arifumi [arifumi@12jabber.net/Exodus] entered the room.
(10:43:28 AM) marshall: lixia: one is how to handle packets during lookup delay
(10:43:34 AM) marshall: [on faiure]
(10:43:57 AM) marshall: lixia: two new factors that introduce packet losses
(10:44:12 AM) marshall: Dino : My comment was about the locatability reachability issue
(10:44:36 AM) marshall: Q : Duplicate detection efforts by multiple hosts is not necessarily a problem
(10:44:44 AM) marshall: [please give names !]
(10:44:56 AM) dthaler: Tim Sheppard
(10:45:46 AM) marshall: lixia: There is not a central node - everybody addresses - detects failure and takes corresponding efforts
(10:46:01 AM) marshall: lixia: the mapping stuff introduces new issues that don't exist today/
(10:46:28 AM) marshall: lixia: if you take the "host take care of itself" approach you wish you could share this information
(10:46:56 AM) marshall: lixia: we have two computers that try and reach Google (for example)
(10:47:04 AM) marshall: lixia: first guy tries address X
(10:47:16 AM) marshall: lixia: it doesn't work, he uses address Y
(10:47:34 AM) marshall: Tim : Google certainly announces multiple addresses
(10:47:49 AM) csp left the room.
(10:48:00 AM) marshall: Tim : You seems to be assuming that hosts are only connected through one network
(10:48:26 AM) marshall: Q : You seem to be assuming that you have to do the mapping before you inject packets into the network
(10:48:29 AM) sbrim: I don't see why he thinks that
(10:48:49 AM) dthaler: Kevin Fall
(10:49:01 AM) marshall: Q : If you can encode the destination into the packet you may be able to do this more effeciently
(10:49:39 AM) marshall: Kevin : If we have a world where devices are less and less capable, like mobile devices, putting this into the host makes me uncomfortable
(10:49:53 AM) dthaler: this is Erik again now
(10:50:12 AM) marshall: Erik : If it is only X and Y that is easy. If you have 16 things to chose from that is different
(10:50:20 AM) csp [csp@jabber.org/University of Glasgow] entered the room.
(10:50:24 AM) marshall: lixia: You can see that in some of the proposed solutions
(10:50:39 AM) marshall: Summary of questions
(10:50:47 AM) marshall: q1 : How to get mapping info
(10:51:03 AM) marshall: lixia: Her are evaluation criteria
(10:51:13 AM) marshall: [too many to retype]
(10:51:52 AM) bruce: data delivery performance: delay due to mapping lookup, delay due to suboptimal paths, loss due to lack of mapping info, loss during transient failure, traffic concentration
(10:52:24 AM) marshall: Kevin [?] : Does the routing have the ability to pick shortest paths is an important factor
(10:52:32 AM) dthaler: (yes this is Kevin Fall)
(10:52:52 AM) marshall: lixia: Should we make dynamics separate
(10:52:54 AM) benno [benno@jabber.xs4all.nl/Adium] entered the room.
(10:52:57 AM) marshall: lixia: now it is in two places
(10:52:58 AM) benno left the room.
(10:53:04 AM) sbrim: Kevin does not seem to be talking about the criteria, but how to measure along the dimensions the criteria invoke.  That's fine.  We didn't get there very much.
(10:53:11 AM) benno [benno@jabber.xs4all.nl/Adium] entered the room.
(10:53:35 AM) marshall: lixia: What I hear you saying is that we should have a separate item about this
(10:54:07 AM) sbrim: about dynamicity
(10:54:15 AM) marshall: Erik : I am confused - there is a risk of a solution that solves multi homing but forgets about traffic engineerin g
(10:54:34 AM) marshall: lixia: I don't see that there is a fundamental difference between the two
(10:54:51 AM) marshall: Erik : There are multiple levels at which you might want to do TE
(10:55:09 AM) marshall: lixia: I didn't mention about that
(10:55:23 AM) marshall: Q : There is an area where we need a lot more data
(10:55:25 AM) dthaler: ^ Eliot Lear
(10:55:46 AM) marshall:  Elliot : If you solve multi homing is that good enough ? And if not, why not ?
(10:56:30 AM) marshall: Sandy Murphy : The security of the router system.
(10:56:58 AM) marshall: Sandy : John Scudder at the  last IETF had a functional description of the security of the routing system
(10:57:33 AM) marshall: Sandy : Your slide said security of the mapping info, which is only one part of the security of the routing system 
(10:57:45 AM) sbrim: it shouldn't be a hierarchy.  I learned the term "facet-based categorization" from Melinda.
(10:58:03 AM) marshall: lixia: This is a very important question. We definitely need a document or a framework there
(10:58:53 AM) marshall: Ilijitch : The number of prefixes from the RIR is growing by 7 % / year, while the prefixes in the table is growing by 16% / year
(10:59:43 AM) marshall: Ilijitch : if people have PI space and they want to announce multiple blocks in mulitple locations - there are only 25 As now and 225,000 prefixes
(11:00:11 AM) iljitsch: 25k
(11:00:27 AM) marshall: lixia: We will incorporate these comments into the next draft - the first draft
(11:00:53 AM) sbrim: who's next?
(11:01:05 AM) dthaler: Vogt
(11:01:06 AM) marshall: Christian Vogt
(11:01:12 AM) sbrim: thanks
(11:01:14 AM) yone left the room.
(11:01:52 AM) marshall: Christian : I want to present the Six / One solution, which is a combined edge based host based solution
(11:01:59 AM) marshall: Christian : three stakeholders
(11:02:15 AM) marshall: Christian : Edge networks, providers and hosts
(11:02:34 AM) marshall: Christian : Edge networks want to select from multiple providers
(11:02:54 AM) marshall: Christian : another goal of edge networks is to reduce the cost of network configuration
(11:03:08 AM) marshall: Christian : the goals of the host is also to select a particular provider
(11:03:24 AM) marshall: Christian : it is also a goal of the host to adapt
(11:03:36 AM) marshall: Christian : say if the provider changes, or on RTT measurements
(11:03:43 AM) marshall: Christian : there are 3 types of solutions
(11:03:59 AM) marshall: Christian : current practice is PI space to edge networks, which is globally visible
(11:04:11 AM) marshall: [has a table on his graph]
(11:04:47 AM) marshall: Christian : Each PI address block increases size of address space
(11:05:16 AM) marshall: Christian : Host goals are not met with PI space as the hosts does not see these
(11:05:41 AM) marshall: Christian : Shim6 was developed to solve the routing address space growth
(11:05:44 AM) lixia: Scott: I just uploaded the slides to RRG page http://www3.tools.ietf.org/group/irtf/trac/wiki/RRGagendaChicago (it is the same as the one I sent you last night)
(11:05:59 AM) sbrim: OK thanks
(11:06:07 AM) marshall: Christian : With shim6 the edge network cannot select providers, as these are selected by the hosts
(11:06:25 AM) lixia: with the tail slides (on individual proposals) cutoff
(11:06:38 AM) sbrim: shhhh :-)
(11:06:47 AM) marshall: Christian : Another thing that edge networks may not like is that they don't have PI space
(11:07:06 AM) marshall: Christian : to give the edge networks more capabilites and reduce rehoming costs there
(11:07:53 AM) marshall: Christian : have been recent proposals with PI space and a mapping between PI space in a edge network and provider dependent space in the global network
(11:08:08 AM) marshall: Christian : the goal of Six/One was to meet all of these goals
(11:08:13 AM) marshall: Christian : here is an overview
(11:08:30 AM) marshall: Christian : you can think of six /one as a combination of Shim6 and 8+8
(11:08:49 AM) marshall: \Christian : Erik Nordmark has a draft to combine these
(11:09:01 AM) marshall: Christian : draft-nordmark-shim6-esd
(11:09:18 AM) marshall: Christian : Hosts get dependent address space
(11:09:42 AM) marshall: Christian : within the edge network every link gets a subnet ID
(11:10:00 AM) marshall: Christian : hosts then configure one address per subnet prefix
(11:10:11 AM) bruce left the room (Logged out).
(11:10:27 AM) marshall: Christian : all of these addresses have a common, cryptographically generated, interface identifies
(11:10:40 AM) marshall: Christian : which is the same across the entire address bunch
(11:11:00 AM) marshall: Christian : the host shows a single stable address to each application
(11:11:11 AM) marshall: Christian : with a variable address on the wire
(11:11:40 AM) marshall: Christian : what is different from shim6 is that the edge network is able to rewrite the routing prefix of a host
(11:11:42 AM) marshall: Christian : Why ?
(11:12:06 AM) marshall: Christian : so that the edge network can change providers
(11:12:22 AM) marshall: Christian : hosts need context of each other's address bunches
(11:12:33 AM) marshall: Christian : this is split into two parts
(11:12:55 AM) marshall: Christian : this figure shows how the rewriting works
(11:13:14 AM) marshall: Christian : both the host and the corresponding host run a six/one instance
(11:13:33 AM) kazuya left the room.
(11:13:35 AM) marshall: Christian : when an application sends a packet, say with routing prefix 1000
(11:14:02 AM) marshall: Christian : I forgot - there are two cases - one where the addresses are passed through, and the second where they are rewritten
(11:14:22 AM) marshall: Christian : the host is suggesting the provider
(11:14:57 AM) marshall: Christian : at some point the edge network may decide to rewrite the routing prefix of the packets source address
(11:15:04 AM) marshall: to povider number two
(11:15:25 AM) marshall: Christian : the six one instance on the correspondant host recognizes this change
(11:15:33 AM) marshall: Christian : and adopts it
(11:15:44 AM) marshall: Christian : so that the return packet goes through provider 2
(11:15:55 AM) marshall: Christian : applications don't see the change
(11:16:35 AM) marshall: Christian : when the host sends the next packet its own six/one instance it uses the new routing prefix
(11:16:56 AM) marshall: Erik Nordmark : How do you enforce [symmetric paths]
(11:17:05 AM) Tony Li: That was Dave Oran
(11:17:23 AM) marshall: Christian : You don't need host specific state to do the re-writing
(11:17:48 AM) marshall: Q : How does the edge network detect that the correspondant host can detect this change
(11:17:55 AM) jlcjohn left the room.
(11:18:00 AM) marshall: Christian : I was not talking about discovery of support
(11:18:09 AM) dthaler: Q = Tim Sheppard
(11:18:21 AM) marshall: Christian : I was assuming you can rely on the correspondent host to detect this
(11:18:29 AM) marshall: Christian : I am assuming that at this point
(11:18:46 AM) marshall: Tim : This is a neat idea but I am worried if we can ever get there
(11:18:58 AM) marshall: Tim : I wish we had thought of this years ago
(11:19:11 AM) marshall: Christian : The crucial part is of course to bring this into the hosts
(11:19:24 AM) marshall: Dino : This looks very much like Shim6
(11:19:35 AM) marshall: Christian : The edge network can decide where the packets go
(11:19:52 AM) marshall: Dino : You mean that there are routers in the edge network doing this ?
(11:20:16 AM) marshall: Dino : You have that Six / One vertical bar. Where is the functionality
(11:20:31 AM) marshall: Christian : The veritical bar is within the host
(11:20:49 AM) marshall: Christian : The rewrite happens within a rotuter, presumabably a border router
(11:21:07 AM) marshall: Dino : Now tell me the difference between the this slide and GSE
(11:21:36 AM) shep: my last name is spelled "Shepard" (only one 'p')
(11:21:47 AM) marshall: Christian : In GSE the host doesn't see the provider. The source addresses don't show this. They cannot adopt the provider and don't when it is changed
(11:21:51 AM) jpc left the room.
(11:22:21 AM) marshall: Christian : The cryptographic indentifier can be used to make sure that these packets belong together
(11:22:35 AM) arifumi: the rewriting router has to have state for each connection, right ?
(11:22:41 AM) marshall: Brian Carpenter : I wish that this had come up in the Multi-6 WG
(11:23:00 AM) marshall: Brian : I was waiting on a version of GSE that was plausible
(11:23:13 AM) dudi left the room (Replaced by new connection).
(11:23:19 AM) dudi [dudisaki@jabber.org/Exodus] entered the room.
(11:23:57 AM) marshall: Brian : I believe that this is very promising. I am not proposing that we drop Shim6, as Geoff might hit me [laughter]/
(11:24:11 AM) marshall: Goeff : Shim6 does its own failure detection
(11:24:57 AM) marshall: Christian : Both the host and the edge network can rewrite the addreses. However, the edge network has the final say
(11:25:11 AM) bruce [b@bruce-2007.zerlargal.org/Adium] entered the room.
(11:25:33 AM) marshall: Geoff ; The problem is that the only time you understand true failure is in the host.
(11:25:37 AM) marshall: [I am not sure I got that right]
(11:25:52 AM) marshall: Christian : This is the collision of the goals that we have
(11:26:10 AM) marshall: Christian : The routers only rewrite the source address
(11:26:14 AM) dthaler: his point is that if the edge rewrites without seeing the return path, it can rewrite to an address the host rewrote away from to get around failure of the return path
(11:26:43 AM) marshall: Christian : You can only select the providers  that the edge network directly connects to
(11:26:54 AM) dthaler: so geoff is saying that this breaks shim6 failure avoidance
(11:26:55 AM) gih900: thanks Dave - yes that is my point - the host can see the failure, but the edge router cannot
(11:26:55 AM) marshall: Q : Did you remove anything from Shim 6 ?
(11:27:10 AM) marshall: Christian : No. There is stuff on top of Shim 6
(11:27:29 AM) marshall: Jari : This is cryptographically slightly different
(11:27:34 AM) benno left the room.
(11:28:00 AM) jpc [juampe.cerezo@gmail.com/Adium0318E160] entered the room.
(11:28:13 AM) marshall: Christian : The router in the edge network only needs to rewrite the routing prefix. It doesn't need to keep any host state in the edge network
(11:28:46 AM) dlewis [todesgeliebter@gmail.com/Trillian8FEE372C] entered the room.
(11:28:51 AM) dmm613@gmail.com [dmm613@gmail.com/Adium71809DDE] entered the room.
(11:29:03 AM) marshall: Q : Suppose that there is a 3000 prefix. If the host doesn't know about it, the packet will get dropped on the floor. This is different of 8+8
(11:29:08 AM) dthaler: Q=Erik Nordmark
(11:29:14 AM) marshall: [thanks!]
(11:29:30 AM) marshall: Christian : The next slide shows how context gets established
(11:30:29 AM) marshall: Christian : The Six / One has a local context which shows what providers are available, and an incomplete remote context
(11:30:56 AM) marshall: Christian : That context is given an unique context ID chosen by the host.
(11:31:29 AM) vaf [vaf@jabber.org/Gaim] entered the room.
(11:31:32 AM) marshall: Christian : With the first packet the host sends there is piggy back information to describe the hosts context
(11:32:02 AM) marshall: Christian : with adiditonal information so that the correspondent host can verify that these belong togther
(11:32:27 AM) marshall: Christian : when the packet arrives, the correspondent host has a complete local and remote context
(11:32:53 AM) marshall: Christian : the correspondent host sends back the corresponding information
(11:33:08 AM) marshall: Christian : after that, each side only sends context ID's
(11:33:36 AM) marshall: Christian : One of the goals was to reduce the cost of reconfiguration when the edge network rehomes
(11:34:24 AM) marshall: Christian : the basic idea is to split the router configuration into subnet ID (which doesn't have to change) and one set  of routing prefixes which does have to change
(11:34:48 AM) marshall: Christian : there doesn't have to be any link specific updates
(11:35:03 AM) marshall: Christian : routers only have to rewrite the subnet prefix
(11:35:05 AM) Leslie [leslie-ietf@ecotroph.net/Psi] entered the room.
(11:35:26 AM) marshall: Christian : Six/One only handles changes within one address bunch
(11:35:51 AM) vaf left the room.
(11:35:58 AM) marshall: Christian : Host mobility and host multi-homing and during host network renumbering will cause changes in address bunches
(11:36:11 AM) marshall: Christian : these will require a separate protocol
(11:36:20 AM) eliot.lear [eliot.lear@gmail.com/elear-mac] entered the room.
(11:36:26 AM) farinacci@gmail.com [farinacci@gmail.com/Gaim85011A97] entered the room.
(11:36:43 AM) marshall: Christian : Middle box interoperablity
(11:37:00 AM) marshall: Christian : Devices like firewalls operate on addresses of hosts
(11:37:08 AM) marshall: Christian : this will still work
(11:37:31 AM) marshall: Christian : these middle boxes can indentify hosts by masking the routing prefix
(11:37:38 AM) marshall: Christian : similar to 8+8
(11:38:18 AM) marshall: Christian : Identifying a remote corresponding host - by looking at the local host with which it communicates
(11:38:59 AM) marshall: Christian : the triple of subnet, context and identifier ID can uniquely indentify a host
(11:39:07 AM) marshall: Christian : [Summary slide]
(11:39:12 AM) hantula [hantula@jabber.org/Adium] entered the room.
(11:40:38 AM) marshall: Dino : Have you got any input from operators about the trade off between tunneling and re-writing ?
(11:40:54 AM) marshall: Dino : Did you consider tunneling
(11:42:09 AM) marshall: Q : Back when Mike wrote 8+8 he said that rewriting would be useful for operators
(11:42:16 AM) dthaler: Q=Erik Nordmark
(11:42:30 AM) marshall: Q ; This rewriting is a useful way of doing traffic engineering
(11:43:23 AM) dthaler: this is Suresh Krishnan 
(11:44:40 AM) marshall: [sorry - interrupt]
(11:44:47 AM) dthaler: Suresh asked how it worked with CGAs, and Christian explained HBAs
(11:46:18 AM) marshall: Geoff : I think that there is a tension that Shim 6 does more. When the edge sites are busy rewriting - the host knows about connectivity - the hosts and the edges are trying to do something subtly different
(11:47:44 AM) marshall: Christian : The writing in the edge network can only affect the source address
(11:48:08 AM) marshall: Christian : that does not affect the provider at the correspondant host
(11:48:15 AM) marshall: Christian : the writing is a local think
(11:48:40 AM) marshall: Christian : I assumed that the edge network was aware of which provider has connectivity
(11:49:00 AM) marshall: Christian : the writting can only affect the local routing
(11:50:45 AM) marshall: Q : You have decided to make the signalling from the host - the host was selecting the path - if you chose to override this, the packet will be going out the provider you want, but you cannot ensure that the correspondent host makes that choice
(11:50:55 AM) dthaler: Q=Tim Shepard (with correct spelling this time :)
(11:52:08 AM) kazuya [kazuya@jabber.org/Exodus] entered the room.
(11:52:19 AM) marshall: Tim : In Shim6 the end host is making all of the decisions. I almost think that there is some means of communicating the networks desires for traffic engineering to the end host
(11:52:31 AM) marshall: Christian : Another approach is in terms of transistion
(11:52:52 AM) marshall: Christian : It would be easier to cope with legacy hosts if you do not change addresses during a connection
(11:53:40 AM) marshall: Q : The beauty of rewriitng in the router is that this is a router through which the packet is passing, so it could have dropped the packet anyway
(11:53:47 AM) dthaler: Q=Erik
(11:54:03 AM) marshall: Erik: So presumably it has authoriity to change the packet 
(11:54:58 AM) marshall: Erik : With PI space it is pretty clear who can select the path. With Shim 6 this is moved to the host. This is a mixed approach
(11:55:16 AM) marshall: Christian : In this approach the host can only suggest
(11:56:02 AM) marshall: Thomas Narten : In this case the host and the edge network do not have consistent information. Some times they will make the wrong decision for the other one
(11:57:05 AM) marshall: Geoff : Here is a simple example. Path A and Path B are completely different. The edgte network wants to TE to Path A. The hosts have found that there is a 
(11:57:35 AM) marshall: Geoff : a break in Path A, and want to use Path B. There is no signalling mechanism to share this infromation
(11:57:45 AM) sbrim: right
(11:57:55 AM) marshall: Geoff : Unlike what Brian said, we saw some of these proposals
(11:58:04 AM) marshall: [computer battery break]
(11:58:43 AM) kazuya left the room.
(11:58:54 AM) kazuya [kazuya@jabber.org/Exodus] entered the room.
(11:59:14 AM) marshall: Q : If the network could signal TE - one way of doing that is by dropping it, or rate limiting it
(11:59:27 AM) dthaler: Q=Tim Shepard
(11:59:45 AM) kazuya left the room.
(12:00:02 PM) marshall: Tim : If the host could have a collection of prefixes, there is a real traffic engineering question here. Is that in scope for the RRG ?
(12:00:08 PM) kazuya [kazuya@jabber.org/Exodus] entered the room.
(12:00:46 PM) marshall: Christian : The ability of the edge network - you can give it full control. It might not have the full view, as Geoff has said
(12:01:23 PM) jlcjohn [jlc69john@jabber.org/Psi] entered the room.
(12:01:39 PM) marshall: Q : If the network is going to rewrite something, the network is saying, you can use this one, the end host has the set of possible paths 
(12:01:46 PM) eliot.lear: [this was Dow Street speaking]
(12:01:47 PM) marshall: [I didn't understand that ]
(12:02:32 PM) dthaler: I think Dow was saying instead of rewriting, edge could tell host what to rewrite it to (and drop traffic that isn't rewritten by the host)
(12:02:39 PM) marshall: Dino : I was think of the opposite - if we want session reachability, it might be useful if the hosts could tell the routers which paths to 
(12:03:01 PM) marshall: Dino : That means more mechanisms
(12:03:16 PM) iljitsch: I think those who don't remember multi6 are forced to relive it.  :-)
(12:03:29 PM) marshall: [even I know you, I may not know your voice !]
(12:03:53 PM) marshall: lixia: My stduents couldn't make it here
(12:03:58 PM) marshall: lixia: APT
(12:04:10 PM) marshall: lixia:  Where does APT sit ?
(12:04:14 PM) benno [benno@jabber.xs4all.nl/Adium] entered the room.
(12:04:33 PM) marshall: lixia: Its an older sister of LISP
(12:04:50 PM) marshall: lixia: We didn't know that RRG was the venue for this
(12:05:16 PM) marshall: lixia: APT does two parts
(12:05:28 PM) marshall: lixia: distributes mapping information
(12:05:37 PM) marshall: lixia: then what do you do with it
(12:05:50 PM) dowstreet@jabber.postel.org: to clarify my previous comment - there is not any re-writing in the network.  the host selects addresses for the packet - and this selection impacts the path that is taken.  
(12:06:23 PM) marshall: lixia: Three types of nodes
(12:06:33 PM) marshall: lixia: standard routers, the routers of today
(12:06:45 PM) arifumi left the room (Replaced by new connection).
(12:06:58 PM) marshall: lixia: in organge there are the routers that understand this new information
(12:07:07 PM) marshall: lixia: they hold the mapping information
(12:07:09 PM) dowstreet@jabber.postel.org: however, this host-based selection of addresses is bounded to the set of allowable addresses published by the network. 
(12:07:13 PM) eliot.lear left the room.
(12:07:20 PM) marshall: lixia: the ITRs are the users of this information
(12:07:49 PM) marshall: lixia: We submitted a draft for the IETF deadline
(12:08:01 PM) marshall: lixia: but then detected some issues which have been changed
(12:08:12 PM) marshall: lixia: Mappers - these are  new device
(12:08:21 PM) jpc left the room.
(12:08:24 PM) arifumi [arifumi@12jabber.net/Exodus] entered the room.
(12:08:32 PM) marshall: lixia: these store entire mapping information
(12:08:57 PM) marshall: lixia: What if you have multiple mappers
(12:09:06 PM) marshall: lixia: we propose anycast to reach them
(12:09:12 PM) marshall: lixia: each AS should have one
(12:09:17 PM) marshall: lixia: at least
(12:09:29 PM) marshall: Dino : Are you required to use anycast ?
(12:09:37 PM) marshall: lixia: if you have multiple mappers, yes
(12:10:05 PM) marshall: lixia: Mappers tell the ITRs what mapping entries to use
(12:10:38 PM) marshall: lixia: The mappers do control, TE 
(12:10:42 PM) Melinda left the room.
(12:10:55 PM) marshall: lixia: In return the ITRs are as simple as possible
(12:11:14 PM) marshall: lixia: The goal for the tunnel routers os minimal changes and stay simple
(12:11:20 PM) marshall: lixia: the brains are in the mappers
(12:11:45 PM) marshall: lixia: Each ITR has one entry for each routable prefix
(12:12:07 PM) marshall: lixia: No mapping entry, tunnel packet to the mapper
(12:12:28 PM) marshall: lixia: the mapper forwards the packets, abnd responds with a mapping entry back to the ITR
(12:12:50 PM) batfli [batfli@jabber.org/Adium] entered the room.
(12:12:52 PM) marshall: lixia: this is influenced by the goal of making the ITR simple
(12:13:01 PM) marshall: lixia: I want feedback on this goal
(12:13:20 PM) marshall: lixia: We hope that there are no changes to other existing routers
(12:13:31 PM) marshall: lixia: Although such changes might be optional;
(12:13:39 PM) marshall: lixia: examples
(12:13:59 PM) marshall: lixia: edge prefixes are numbers
(12:14:12 PM) marshall: lixia: GRA addresses are letters
(12:14:38 PM) dthaler: (in the slide, not literally :)
(12:17:00 PM) bruce: (though the idea of reducing the routing table to 26 prefixes is strangely appealing)
(12:18:10 PM) iljitsch: make it binary and reduce to 2 prefixes....
(12:18:17 PM) dthaler: (yeah but half of them are already taken by dns root servers :)
(12:18:20 PM) marshall: [sorry, interrupt]
(12:18:49 PM) marshall: lixia: [Stepping through situation 1]
(12:19:24 PM) marshall: lixia: If there is a failure, the mapper learns about it from the BGP stuff
(12:19:54 PM) marshall: lixia: When the mapper sends the new mapping information to the ITR, it sets a new TTL for this
(12:20:06 PM) marshall: [the ttl is a mapping ttl, not a hop count]
(12:20:25 PM) marshall: Q : Does the mapper return all information ?
(12:20:39 PM) Tony Li: Q = Eliot Lear
(12:20:42 PM) marshall: lixia: We assume that the ITR is as simple as possible
(12:20:50 PM) marshall: lixia: So we only send one
(12:21:02 PM) marshall: Elliot : We need to look at this later
(12:21:26 PM) marshall: lixia: If you notice a failure, you just forward packet to the mapper
(12:21:51 PM) marshall: lixia: As I said before, for preferred path, you put a longer TTL
(12:21:54 PM) marshall: lixia: Situation 2
(12:22:06 PM) marshall: lixia: This is a new failure mode
(12:22:48 PM) washad left the room.
(12:23:01 PM) marshall: lixia: "Michael" has no routable prefix and so then his link fails this does not go into the global routing table
(12:23:11 PM) marshall: so the ITR does know this
(12:23:33 PM) marshall: lixia: How to do the data forwarding
(12:23:36 PM) farinacci@gmail.com: Robert asked the load-splitting question in the ITR
(12:23:59 PM) marshall: lixia: Michael's ETR forwards the packet to its default mapper
(12:24:26 PM) marshall: lixia: Michael's ETR Mapper tries to find an alternate GRA tunnel address
(12:24:49 PM) marshall: lixia: The dat handling 
(12:25:00 PM) marshall: lixia: data handling goal is to minimize packet losses
(12:25:24 PM) marshall: lixia: 2 options to inform sender
(12:25:32 PM) marshall: lixia: the first is easier
(12:25:55 PM) marshall: lixia: send an ICMP destination unreachable message to the ITR, which forwards it to its mapper
(12:26:36 PM) marshall: lixia: the second assumes a well known mapping address. The ETR domain mapper sends a message to the ITR's mapper
(12:27:05 PM) marshall: lixia: The source mapper needs to keep information about currently failed things
(12:27:58 PM) iljitsch left the room.
(12:28:57 PM) csp left the room.
(12:30:58 PM) kazuya left the room (Replaced by new connection).
(12:30:58 PM) marshall left the room.
(12:30:58 PM) gih900 left the room.
(12:30:58 PM) dlewis left the room.
(12:31:00 PM) gih900 [gih900@jabber.psg.com/Exodus] entered the room.
(12:31:03 PM) dudi left the room (Replaced by new connection).
(12:31:09 PM) dthaler left the room (Replaced by new connection).
(12:31:12 PM) kazuya [kazuya@jabber.org/Exodus] entered the room.
(12:31:27 PM) Tony Li left the room (Replaced by new connection).
(12:31:31 PM) satoru left the room.
(12:31:41 PM) satoru [satoru.matsushima@jabber.jp/Exodus] entered the room.
(12:31:46 PM) marshall [marshall@jabber.isoc.org/Marshall Eubanks s Computer (5)] entered the room.
(12:31:47 PM) marshall: test
(12:31:55 PM) arifumi left the room (Replaced by new connection).
(12:32:29 PM) arifumi [arifumi@12jabber.net/Exodus] entered the room.
(12:32:35 PM) marshall: [sorry - Jari and I both lost Internet connection for about 3 minutes]
(12:32:41 PM) dudi [dudisaki@jabber.org/Exodus] entered the room.
(12:33:12 PM) sbrim: Audio seems to be gone.  Please type a lot :-)
(12:33:33 PM) marshall: Dave Thaler : My question is whether the new ETR learns the new destination or has to send packets to ETR 2 as if he was a mapper
(12:33:49 PM) dthaler [dthaler@jabber.org/Exodus] entered the room.
(12:33:50 PM) hantula: I'm losing audio due to drilling in the wall beside me
(12:33:58 PM) marshall: lixia: This is the question of the brains of the ITRs
(12:34:03 PM) bensons [bensons@jabber.postel.org/Psi] entered the room.
(12:34:44 PM) marshall: lixia: There is the possibility that if ETR 1 knows all of the mapping information for its conencted to it can directly forward packets to ETR 2
(12:34:47 PM) dthaler: My question was whether ETR2 (who can't send packets to destination and has to forward to his default mapper) learns the new mapping (to ETR1 in the example) or whether all traffic continues to go to default mapper
(12:34:57 PM) gih900 left the room.
(12:35:00 PM) marshall: lixia: Distributed mappings
(12:35:10 PM) sbrim: what does that mean?
(12:35:26 PM) marshall: lixia: between ASes
(12:35:28 PM) dthaler: since in situation 3, lots of sources could be sending to the destination and have the same problem, so if he doesn't learn the mapping, lots of traffic ends up going via the default mapper
(12:35:40 PM) marshall: lixia: Quick and dirty solution is to add to BGP
(12:35:55 PM) marshall: lixia: So we propose a new BGP transitive attribute
(12:35:59 PM) benno left the room.
(12:36:06 PM) dthaler: and if it does learn the mapping, then it works just like the case where it's an ITR
(12:36:18 PM) marshall: lixia: the mapping entry is the edge prefix to GRA address mapping
(12:36:21 PM) Leslie: scott -- is the audio still out?
(12:36:45 PM) marshall: lixia: An edge  network sends a singed mapping to al providers, together with its key
(12:36:49 PM) sbrim: So ... this pushes "important" mappings to the mappers, mappers pull "less important" mappings from somewhere, and ITRs pull from the mappers.
(12:36:59 PM) sbrim: Leslie: I'm getting 404 not found at UoO
(12:37:19 PM) marshall: a provider network floods thier customers mappings to other provider networks by BGP
(12:37:45 PM) marshall: Q : We are securing BGP at some point.
(12:37:51 PM) marshall: Can we secure these mappings
(12:37:52 PM) dthaler: Q=Erik
(12:38:32 PM) marshall: Erik : Presume that secure BGP says, I am allowed to speak on behave of this prefix
(12:38:49 PM) marshall: Erik : Here, I think we need another mechanism
(12:39:02 PM) marshall: Dino : Are these mappings advertised in line ?
(12:39:13 PM) marshall: lixia: It doesn't use another top[ology
(12:39:25 PM) marshall: Dino : So, you will have to modify all BGP routers
(12:39:41 PM) marshall: lixia: This is a detail that I don;'t remember now
(12:40:08 PM) marshall: Dino : If you don't change the NLRI then youwill have a name space collision
(12:40:13 PM) marshall: lixia: No
(12:40:18 PM) bruce left the room.
(12:40:19 PM) marshall: Dino : They will
(12:40:35 PM) marshall: Dino : The path attributes are associated with a NLRI
(12:40:58 PM) marshall: lixia: Did I say this was quick and dirty ?
(12:41:32 PM) marshall: Q : At some point you stop advertising customer routers. What is the trigger ?
(12:41:46 PM) marshall: Q : I think it will be much cleaner to define a new SAFI
(12:42:18 PM) marshall: John : I would like to join the people who are encouraging you to abandon this particular use of BGP
(12:42:45 PM) marshall: John : People may filter BGP  - this is an unreliable way of transmitting this information
(12:43:56 PM) marshall: Erik : I have   a higher level question. The end result that the mapping information for every end site would be in the RIB of every router of every tier 1 ISP.
(12:44:03 PM) dthaler: that was Dave Oran
(12:44:27 PM) marshall: lixia: This was another detail that I didn't want to discuss [laughter]
(12:45:12 PM) marshall: Joel Halpirin : You have said that you have to distribute the whole table - do you have to do this or not ?
(12:45:15 PM) dthaler: Halpern
(12:45:16 PM) marshall: lixia: Why not ?
(12:45:35 PM) sbrim: audio is back (thanks much!)
(12:45:40 PM) marshall: lixia: We let everybody inject their own piece into the system
(12:45:54 PM) marshall: Dino : Packets go into the default mapper
(12:46:39 PM) marshall: Dino : The ITR doesn't know what to do so it sends it to a default mapper
(12:47:20 PM) dmm613@gmail.com: another issue: the data plane of the default mapper needs to be well, huge
(12:47:28 PM) marshall: Dino : If you use anycast, you can't pick which one to send to, so they all have to contain the complete mapper
(12:47:36 PM) sbrim: right
(12:47:43 PM) sbrim: otherwise how do you know which to talk to?
(12:47:53 PM) farinacci@gmail.com: right scott
(12:48:01 PM) sbrim: or does a packet chain from one to the other, wandering through the lonely night until it finds a place to call home?
(12:48:09 PM) dthaler: well you could have multiple anycast addresses for disjoint address space ranges
(12:48:16 PM) sbrim: <nod>
(12:48:19 PM) dmm613@gmail.com: but then there's a new routing protocol to route map packets
(12:48:20 PM) nm left the room.
(12:48:22 PM) dthaler: as long as the default mapper and ITRs agree
(12:48:24 PM) john.zhao [lionnaduo@jabber.cn/Psi] entered the room.
(12:48:31 PM) marshall: lixia: In defense of pigybacking on BGP
(12:48:34 PM) dthaler: right (but could be static config)
(12:48:35 PM) jgs@jabber.org: sure, but the aggregate of those default mappers still add up to one omniscient default mapper
(12:48:41 PM) dthaler: right
(12:48:42 PM) jgs@jabber.org: it's just a distributed device at that point
(12:48:44 PM) iljitsch [iljitsch@gmail.com/nirrti] entered the room.
(12:48:54 PM) marshall: lixia: Mapping updates are far less problematic than BGP routing updates
(12:48:57 PM) dmm613@gmail.com: jgs: exactly
(12:49:03 PM) sbrim: as long as there's a clear algorithm to select one you're ok -- like 5 anycast addresses
(12:49:12 PM) marshall: lixia: APT is not married to BGP
(12:49:25 PM) dmm613@gmail.com: and what about any damage done by the new attribute (path explosion, convergence, ....)
(12:49:38 PM) marshall: lixia: If you have a better solution we will be happy to consider
(12:49:40 PM) jgs@jabber.org: sure, you can easily figure out how to distribute it -- but that's not responsive to joel's comment
(12:50:10 PM) marshall: lixia: Mapping information is only accepted from configiured BGP peers
(12:50:25 PM) dthaler: correct, APT can't work with CONS as currently defined
(12:50:35 PM) marshall: lixia: Mappers talk to ITRs in the same AS
(12:50:43 PM) marshall: lixia: So, security is local
(12:50:59 PM) marshall: lixia: mapping information does not cross boundaries
(12:51:21 PM) marshall: lixia: border link failure packets can only be sent by GRA packets
(12:51:42 PM) marshall: lixia: You could do something about secure commiunication between mappers
(12:52:02 PM) marshall: lixia: Our current goal is to say that address  will not change
(12:52:04 PM) nm [nm@jabber.org/Exodus] entered the room.
(12:52:33 PM) marshall: lixia: edge prefixes may not have mappings to start with
(12:52:45 PM) sbrim: we seem to be on schedule
(12:53:00 PM) marshall: lixia: We take the soft state religion
(12:53:21 PM) marshall: lixia: refresh on a regular basis - all infroamtion has a ttl attached to it
(12:53:58 PM) marshall: lixia: Security issue - how can mappers find other mappers kets
(12:54:08 PM) marshall: lixia: Could send through BGP annioucnement
(12:55:28 PM) marshall: lixia: Keys can be sent through multiple paths
(12:55:35 PM) bensons left the room.
(12:55:43 PM) marshall: lixia: so key spoofing can be detected
(12:55:59 PM) marshall: lixia: by comparing results along different paths
(12:56:45 PM) marshall: lixia: priority is assigned by the owner of the prefix
(12:57:12 PM) marshall: lixia: Once the traffic flows inside the routable space, the ISPs do what they are already doing
(12:57:45 PM) marshall: lixia: Security - publicize all keys
(12:58:34 PM) marshall: lixia: the number of ASes in the routable space is 2 - 3 orders of magnitude than the edge space
(12:58:43 PM) marshall: [this network may drop in 15 seconds]
(12:59:46 PM) marshall: lixia: We need more data
(13:00:21 PM) marshall: ? from UCN : We are collecting netflow data. If you have software, I can run it on our traces
(13:00:52 PM) dthaler: I think it's Luigi Iannone
(13:00:57 PM) marshall: lixia: We could use that. We don't care about the traces, just the distribution
(13:01:03 PM) farinacci@gmail.com: yes, it was Luigi
(13:01:13 PM) farinacci@gmail.com: from UCL Belgium
(13:02:01 PM) farinacci@gmail.com left the room.
(13:02:03 PM) cabo left the room.
(13:02:05 PM) dthaler: lunchtime!
(13:02:06 PM) dmm613@gmail.com left the room.
(13:02:10 PM) dudi left the room.
(13:02:11 PM) john.zhao left the room.
(13:02:12 PM) Leslie left the room (Logged out).
(13:02:13 PM) hantula left the room.
(13:02:13 PM) shep left the room.
(13:02:15 PM) kazuya left the room.
(13:02:19 PM) marshall: [Mention of  a proposal from Cornel U that lixia thinks might be valueable 
(13:02:21 PM) marshall left the room.
(13:02:24 PM) yoshfuji left the room.
(13:02:26 PM) arifumi left the room.
(13:02:43 PM) mjo left the room.
(13:02:49 PM) satoru left the room.
(13:03:41 PM) iljitsch left the room.
(13:04:13 PM) lixia left the room.
(13:05:05 PM) ks left the room.
(13:06:07 PM) batfli left the room.
(13:14:06 PM) dowstreet@jabber.postel.org left the room (Logged out).
(13:19:44 PM) jlcjohn left the room.
(13:19:56 PM) nm left the room.
(13:21:48 PM) dthaler left the room.
(13:21:52 PM) jgs@jabber.org left the room.
(13:46:39 PM) jlcjohn [jlc69john@jabber.org/Psi] entered the room.
(13:54:38 PM) nm [nm@jabber.org/Exodus] entered the room.
(13:55:07 PM) nm left the room.
(13:55:21 PM) dlewis [todesgeliebter@gmail.com/TrillianD38106D2] entered the room.
(13:56:40 PM) arifumi [arifumi@12jabber.net/Exodus] entered the room.
(14:15:22 PM) dthaler [dthaler@jabber.org/Exodus] entered the room.
(14:15:44 PM) marshall [marshall@jabber.isoc.org/Marshall Eubanks s Computer (5)] entered the room.
(14:15:56 PM) lixia [lixia@jabber.postel.org/Lixia's Computer] entered the room.
(14:16:06 PM) marshall: test
(14:16:25 PM) sbrim: :blinks
(14:16:25 PM) marshall: we're back!!!!
(14:16:35 PM) iljitsch [iljitsch@gmail.com/nirrti] entered the room.
(14:16:38 PM) marshall: Jim Griffioen
(14:16:47 PM) marshall: Separating Routing and Forwarding
(14:16:57 PM) marshall: Postmodern Internet 
(14:17:39 PM) marshall: Jim : Tony asked me to come and talk about our NSF project
(14:17:45 PM) marshall: This is a view of the future
(14:17:53 PM) mjo [mjo@jabber.org.au/emacs] entered the room.
(14:17:59 PM) marshall: Jim : What are we trying to do here ?
(14:18:12 PM) marshall: Jim : Now we are looking at much higher level issues
(14:18:18 PM) marshall: Jim : with lots of stakeholders
(14:18:25 PM) marshall: Jim : with lots of different requirements
(14:18:53 PM) marshall: Jim : We are saying, what if we take a clean slate approach
(14:19:04 PM) marshall: Jim : we are not interested in backwards compatibility
(14:19:13 PM) marshall: Jim : this is early in the process
(14:19:18 PM) nm [nm@jabber.org/Exodus] entered the room.
(14:19:21 PM) marshall: Jim : with lots of open issues
(14:19:26 PM) marshall: Jim : what we are doing
(14:19:32 PM) sbrim: Audio not working
(14:19:34 PM) satoru [satoru.matsushima@jabber.jp/Exodus] entered the room.
(14:19:43 PM) marshall: Jim : parts of what we are doing you have seen before
(14:19:51 PM) marshall: Jim : what are the problems now
(14:20:03 PM) marshall: Jim : the hourglass approach is the right way to do it
(14:20:20 PM) marshall: Jim :  but routing, forwarding and addressing are entangled
(14:20:36 PM) marshall: Jim : trust issues were largely ignored in the early design
(14:20:47 PM) marshall: Jim :  we would like to separate policy from mechanism
(14:20:53 PM) dmm613@gmail.com [dmm613@gmail.com/AdiumB252E569] entered the room.
(14:20:57 PM) marshall: Jim : the service is opaque
(14:20:58 PM) satoru left the room.
(14:21:13 PM) marshall: Jim : some of our work is motivatd by a paper by Dave Clark
(14:21:30 PM) marshall: Jim : tussles between players should be played out on top of the mechanism
(14:21:51 PM) marshall: this leads to kludges, which are now ossified kludges
(14:21:55 PM) marshall: Jim : building blocks
(14:22:16 PM) marshall: Jim : want to implement policy outside of mechanisms
(14:22:32 PM) marshall: Jim : deep packet inspection should never be necessary on the forwarding path
(14:22:54 PM) marshall: Jim : isolate forwarding from any endpoint addresses
(14:23:20 PM) marshall: Jim : avoid hierarchical or topology based indentifiers
(14:23:41 PM) marshall: Jim : we also want to separate customer and provider relatonships from topology
(14:24:01 PM) marshall: Jim : Assumptions
(14:24:19 PM) marshall: Jim : network infrastructure is deployed to make money
(14:24:57 PM) marshall: Elliot Lear : About allowing users greater control over the path taken by packets
(14:25:38 PM) dthaler: Eliot (spelled with one L) asked why, Jim responded saying applications trying to build overlays today to get greater contol
(14:25:46 PM) marshall: Jim : Application developers are building overlay networks to not take the routing offered by the probividers
(14:26:10 PM) Leslie [leslie-ietf@ecotroph.net/Psi] entered the room.
(14:26:36 PM) marshall: Joel Halperin : What is a rough order of magnitude about header versus data bits
(14:26:49 PM) dthaler: Halpern
(14:27:05 PM) marshall: Jim : Once you send the first packets through, you can often reduce the state in the remaining packets
(14:27:51 PM) marshall: Jim : we are assuming that hardware speeds continue to increase, so we can do significant computing, including cryptographic computing, on a per packet basis
(14:28:09 PM) marshall: Jim : 5 components in building blocks
(14:28:35 PM) marshall: Jim : forwarding directive. Where is this packet heading, and a partial path to get there
(14:28:36 PM) satoru [satoru.matsushima@jabber.jp/Exodus] entered the room.
(14:28:48 PM) batfli [batfli@jabber.org/Adium] entered the room.
(14:28:50 PM) marshall: Jim : the idea is that the source has some control over where the packet is going
(14:29:00 PM) marshall: Jim : motivation directive
(14:29:12 PM) marshall: Jim : why should this packet be forwarded
(14:29:16 PM) jgs@jabber.org [jgs@jabber.org/Adium] entered the room.
(14:29:25 PM) marshall: Jim : we are sttill trying to figure this out
(14:29:35 PM) marshall: Jim : also default motivations, say within a domain
(14:29:44 PM) marshall: Jim : next is the accountability field
(14:30:08 PM) marshall: Jim : we would like to put in an unforgeabile record of who handled the packet
(14:30:19 PM) sbrim: "within a domain" would be a scope, not a motivation
(14:30:26 PM) sbrim: Oh.  Never mind.
(14:30:38 PM) marshall: Jim : another BB is the knobs field - how this packet should be treated.
(14:30:55 PM) marshall: Jim : in the opposite direction we have a dials field to pass information back
(14:31:31 PM) marshall: Jim : I would like to talk here about our routing infrastructure
(14:31:38 PM) marshall: to forward packets between realms
(14:31:59 PM) marshall: Jim : our goal is not to provide an address space, just to do forwarding
(14:32:01 PM) marshall: Jim : terms
(14:32:07 PM) marshall: Jim : endpoint is a destination
(14:32:17 PM) marshall: Jim : forwarding node is inside the network
(14:32:31 PM) marshall: Jim : a realm is a coillection of nodes and channels
(14:32:44 PM) marshall: Jim : a channel is a means of transporting packets
(14:32:56 PM) marshall: Jim : and an end channel is the last hop
(14:33:01 PM) marshall: Jim : every channel is named
(14:33:07 PM) marshall: Jim : nodes are anonymous
(14:33:19 PM) marshall: Jim : every  channel has a unique channel ID
(14:33:32 PM) marshall: based on a secret held by the two nodes at each end
(14:33:47 PM) marshall: Jim : naming channels allow for abstracting
(14:34:12 PM) marshall: Jim : If you name nodes
(14:34:26 PM) marshall: Jim : abstracting them requires heirarchical structure
(14:34:51 PM) marshall: Jim : nodes and realms behave the same way
(14:35:08 PM) marshall: Jim : what does forwarding do
(14:35:22 PM) marshall: Jim : forwarding nodes look at forwarding directives
(14:35:31 PM) marshall: Jim :upon a new packet
(14:35:55 PM) marshall: Jim : verify it passed through channel
(14:36:08 PM) marshall: Jim : if next link is directly attached
(14:36:15 PM) marshall: Jim : send it
(14:36:21 PM) marshall: Jim : if no next channel
(14:36:27 PM) marshall: Jim : it is a path fault
(14:36:51 PM) marshall: Jim : the fauliting node sends the packet to a predetermined Path Fault Handler
(14:37:16 PM) marshall: Jim : the PFH carry out routing policy 
(14:37:22 PM) marshall: Jim : but may not route
(14:37:28 PM) marshall: Jim : what about path selection ?
(14:37:44 PM) sbrim: does the PFH return a next_hop?
(14:37:49 PM) marshall: Jim : PoMo separates path selection from topology discovery
(14:38:06 PM) marshall: Jim : three components of path selection
(14:38:17 PM) marshall: Jim : first - selected by the source
(14:38:40 PM) marshall: Jim : assume it knows the internal topology of the realm it belongs to
(14:38:52 PM) ks [keiichi_shima@jabber.org/Adium] entered the room.
(14:38:54 PM) marshall: second - the destination
(14:39:11 PM) marshall: it also needs to  knows the internal topology of the realm it belongs
(14:39:29 PM) marshall: Jim : third are the providers
(14:39:51 PM) marshall: Jim : it is the providers responsibility to get the packet across its realm
(14:40:03 PM) marshall: Jim : let me explain locators
(14:40:20 PM) marshall: Jim : the path into the destinations realm is the locator
(14:41:20 PM) marshall: Jim : a locator defines ingress points and paths to a destination node (an EID).
(14:42:24 PM) marshall: Jim : We don't define specifications, but they are mapped to a node
(14:42:53 PM) marshall: Jim : the transit providers provide translations from partial paths to full paths
(14:43:07 PM) marshall: Jim : how does the source discover topology ?
(14:43:21 PM) marshall: Jim : within a realm it is simple - link state advertisements
(14:43:41 PM) marshall: Jim : the realm only advertises egress links
(14:44:14 PM) marshall: Jim : we introduce a channel level at a node - there is one associated with the nodes at each end of a channel
(14:44:47 PM) marshall: Jim : the channel level represents the maximum level of all realms containing 
(14:44:55 PM) marshall: Jim : the node
(14:45:29 PM) marshall: Jim : whose boundary is crossed by the channel
(14:45:57 PM) marshall: Jim : given channel levels a boarder node is able to generate an advertisements after it
(14:46:07 PM) sbrim: border
(14:46:16 PM) marshall: learns the entire topology of the realm it must advertise
(14:47:14 PM) marshall: Jim : topology servers broadcast within their realm - they have to know about all interior and border channels of every realm that contains it
(14:47:32 PM) marshall: it floods its existence and topology
(14:47:52 PM) marshall: Jim : there is a separate set of route servers, where the policy is located
(14:48:20 PM) marshall: Jim :  paths are useless unless there is a business relationship
(14:48:40 PM) marshall: Jim : they distribute this information to the sender and all path fault handlers
(14:49:02 PM) marshall: Jim : in summary we wanted a thin forwarding mechanism
(14:49:13 PM) marshall: Jim : forwarding nodes are dumb
(14:49:25 PM) marshall: Jim : multiple level of abstraction
(14:49:45 PM) marshall: Questions
(14:49:47 PM) marshall: ?
(14:50:36 PM) marshall: Peter Lothberg : So, when the forwarding element needs to learn something they ask the policy server, and they cache it. If I have a long lived flow and the policy changes, how do they learn about it
(14:51:00 PM) marshall: Jim : We have relatively short timers...
(14:51:12 PM) jpc [juampe.cerezo@gmail.com/Adium25E89BAB] entered the room.
(14:51:31 PM) marshall: Christian : Only the hosts have real knowledge of end to end reachability
(14:52:06 PM) marshall: Jim : We wanted to allow the tussles between services and hosts to play out
(14:52:26 PM) marshall: Jim : You could get that capability
(14:52:56 PM) marshall: Christian : This would be an add on to get information to the hosts
(14:53:22 PM) marshall: Jim : Currently the hosts query the route servers anyway, this could be added on.
(14:53:56 PM) marshall: Ilijitch ; Will all of this information, there is not much information in these packets
(14:54:12 PM) marshall: Jim : We are not designing for today's equipment
(14:54:49 PM) marshall: Ilijitch : Do you have a ballpark figure for the size of the headers
(14:55:02 PM) marshall: Jim : Currently we are using CIDs of 160 bytes
(14:55:05 PM) jpc left the room.
(14:55:47 PM) marshall: Ilijitch : You can make many packets large, but with VOIP the data are small and they need to get through
(14:56:04 PM) marshall: Jim : Yes, but these are long lived flows
(14:56:44 PM) marshall: Sue harris : You made some interesting points. Have you gone to see if the statistics you used were validated
(14:56:58 PM) marshall: Jim : Which paper ? The one I posted had no studies on it
(14:57:48 PM) marshall: This is research in early stages. We have not looked at all of those packet flows and how this plays out with them
(14:58:14 PM) marshall: Jim : the question too is how do you write your applications in the future. You may have to rewrite a lot of them
(14:59:03 PM) marshall: Sue : You should look back on past research on flow lengths, at least how it seems to me, and you should look at past papers
(14:59:21 PM) marshall: Jim : If you have specific papers you suggest please send it to me
(14:59:49 PM) marshall: Kevin : I can order N^2 for a graph with N nodes. Why is it better to label channels than nodes
(15:00:00 PM) null0 [roland.dobbins@gmail.com/Adium896FAB50] entered the room.
(15:00:19 PM) marshall: Jim : As you add abstraction to the flat name space, you don't have to change the names of nodes
(15:00:58 PM) marshall: Kevin : Have you quantified relatively stable ?
(15:01:01 PM) marshall: Jim : No
(15:01:23 PM) marshall: Christian : Can we re-use route information for multiple flows ?
(15:01:39 PM) marshall: Jim : This is an area we are still working on
(15:02:12 PM) marshall: Christian : Since this is cached on a per flow basis you are introducing a connection based approach
(15:02:32 PM) marshall: Jim : We used a fixed lifetime on how long you store the flow]
(15:02:54 PM) marshall: Nurd before LISP
(15:02:56 PM) oak [oak@jabber.uninett.no/Fangban] entered the room.
(15:03:12 PM) marshall: Different Jim now
(15:03:43 PM) jgs@jabber.org: Eliot "Jim" Lear?
(15:03:57 PM) marshall: sorry - Eliot
(15:04:22 PM) marshall: Eliot : Draft-lear-lisp-nerd-01
(15:04:34 PM) marshall: Eliot : A not so novel mapping database
(15:04:47 PM) marshall: Eliot : for use by lisp
(15:05:21 PM) marshall: Eliot : all of these mapping databases do not  transmit operational databases
(15:05:24 PM) marshall: data
(15:05:40 PM) marshall: so if a link goes down, you do not change the DB
(15:05:52 PM) marshall: Eliot : principles and assumptions
(15:06:06 PM) marshall: Eliot : relatively static provisiioning data
(15:06:13 PM) marshall: Eliot : the rate is low
(15:06:30 PM) marshall: Eliot : assume that in flight packet loss or delay is bad
(15:06:49 PM) marshall: Eliot : the data does not change hop to hop
(15:07:01 PM) jlcjohn left the room.
(15:07:06 PM) marshall: Eliot : scale to 10^7 to 10^8 mappings
(15:07:20 PM) marshall: Eliot : Brian Carpenter's estimate for 2050
(15:08:18 PM) marshall: Eliot : BGP is not a good candidate, as it is a mechanism for transmitting data that changes hop by hop
(15:08:42 PM) marshall: Eliot : A small number of database authorities
(15:08:49 PM) marshall: Eliot : they sign the databases
(15:09:09 PM) marshall: Eliot : the way they get the mappings is not described in the draft
(15:09:27 PM) marshall: Eliot : but I envision something like a DNS registrar
(15:09:36 PM) marshall: Eliot : the data does not change often
(15:09:51 PM) marshall: Eliot : how to verify the end user is out of scope
(15:10:14 PM) marshall: Eliot : LISP entries look like mapping data
(15:10:29 PM) marshall: Eliot : you collect them and then sign them
(15:10:57 PM) marshall: Eliot : When an ITR comes up it requests an entire copy of the DB and then caches it
(15:11:29 PM) marshall: Eliot : ITRs then request updates periodically
(15:11:47 PM) marshall: Eliot : it may be possible to use a P2P network to send that
(15:12:06 PM) marshall: Eliot : ITRs can retreive information from each other (other ITRs)
(15:12:13 PM) sbrim: remember the ancient days, there was something that would trickle out jpg files via multicast?
(15:12:20 PM) sbrim: it barely used any bandwidth
(15:12:34 PM) marshall: Eliot : because the information is signed at the source it doesn't matter how you get them

Conversation with rrg@jabber.ietf.org at 07/27/2007 15:15:21 PM on sbrim@jabber.org/Gaim (jabber)
(15:15:21 PM) sbrim [sbrim@jabber.org/Gaim] entered the room.

(15:14:29 PM) marshall: Eliot : there is overlap between LIST-CONS and NERD at the authority
(15:14:40 PM) marshall: Eliot : this is based on IPv4 right now
(15:14:49 PM) marshall: Eliot : 16 butes for the first RLOC
(15:15:08 PM) marshall: Eliot : 8 bytes for subsequent RLOCs
(15:15:33 PM) marshall: for 10^7 EIDs in 2050 that is 400 MBytes of data
(15:15:43 PM) marshall: (with 4 RLOCs each)
(15:15:21 PM) rrg@jabber.ietf.org: The topic has been set to: 
(15:15:40 PM) marshall: if you assume 720 Mbytes of data and a 0.1% change per day, that is 
(15:15:42 PM) marshall: [tiny]
(15:15:59 PM) marshall: Eliot : This the best possible use of PKIs 
(15:16:10 PM) marshall: Eliot : operators should have a cow about it
(15:16:23 PM) marshall: Eliot : Do we need a pull model ? No
(15:16:33 PM) marshall: Eliot : How many sources are there many ?
(15:16:55 PM) marshall: Eliot : NERD falls apart if there are too many sources
(15:17:02 PM) marshall: Eliot : Who can be these sources ?
(15:17:10 PM) marshall: Eliot : order the number of RIRs
(15:17:22 PM) marshall: Eliot : can we mix and match with other things ?
(15:17:31 PM) batfli left the room.
(15:17:42 PM) marshall: Eliot : Yes. You could for example mix and match NERD and ListCons
(15:18:08 PM) marshall: Dino : This is not that much data - it can be stored in non volitile memory
(15:18:26 PM) marshall: Mark Handley : We have been using P2P to do something very similar
(15:18:47 PM) dthaler left the room.
(15:19:01 PM) marshall: Mark : We think that there would be no problem with this data.
(15:19:17 PM) marshall: Mark :The general idea of signing this is the right idea
(15:19:45 PM) marshall: Eliot : I didn't use P2P here because I coulldn't describe it in a few sentances
(15:20:18 PM) marshall: Q : I would like to get consensus that handling this is one database is the way to do this.
(15:20:38 PM) marshall: Eliot : Before we dp that I would like to get more data and more analysis
(15:21:11 PM) marshall: John Scudder : You said that this would not be updated frequently
(15:21:32 PM) marshall: Eliot : The whole thing fails apart if this becomes an operational state database
(15:22:48 PM) marshall: Eliot : You can update to the Nerd DB as often as you want, but they control how often updates are propagated down. They are control the signing
(15:23:26 PM) marshall: Ilijitch : There are people who multihome. You need to know which of these connections are up
(15:23:50 PM) marshall: Eliot : This is a general problem with LISP, and I will let Dino handle that.
(15:23:57 PM) marshall: Eliot : I have to go - thanks !
(15:24:23 PM) bensons [bensons@jabber.postel.org/Psi] entered the room.
(15:24:24 PM) jlcjohn [jlc69john@jabber.org/Psi] entered the room.
(15:24:43 PM) marshall: Dino : I am going to give two presentations in 45 minutes 
(15:24:57 PM) bensons left the room.
(15:25:06 PM) marshall: Dino : First is LISP draft changes - 01 to 02
(15:25:21 PM) marshall: Dino : Most of the technical description will be in Dave's talk
(15:25:35 PM) marshall: Dino : first LISP draft was in January 2007
(15:25:56 PM) marshall: Dino : LISP includes multiple variants
(15:26:10 PM) marshall: Dino : back in January we didn't understand how the DB mapping would work
(15:26:26 PM) marshall: Dino : we originally did IP in IP encapsulation
(15:26:47 PM) marshall: Dino : We described TE ITRs
(15:27:03 PM) marshall: Dino : and a data-triggered mapping mechanism
(15:28:17 PM) marshall: Dino : We want to fix the routing table size problem, but this doesn't provide features to the end uses. What we really want to provide ingress TE to end users
(15:28:38 PM) marshall: Dino : Dave Meyer is now co-author
(15:28:53 PM) marshall: Dino : LISP is now AFI agnostic
(15:29:16 PM) marshall: Dino : IP4 and IPv6 - a single solution - IPv4 has a problem as well
(15:29:35 PM) marshall: Dino : Security was mostly moved into the control section
(15:29:45 PM) marshall: Dino : we added a multicast section
(15:29:58 PM) marshall: Dino : We added UDP encapsulation
(15:30:40 PM) marshall: Dino : people don't like tunneling - there are huge flows (as smaller flows are aggreged 
(15:30:45 PM) marshall: aggregated)
(15:31:33 PM) marshall: Dino : We decided to hash on the inner header to produce a source port the LAG router can hash on 
(15:31:49 PM) marshall: Dino : this also made it possible to carry a NONCE for ETR anti-spoofer
(15:32:20 PM) marshall: Dino : we are taking a very strong stance to NOT put locatior reachability into the database
(15:32:52 PM) marshall: Dino : In LISP, the outer headers have locators the inner headers have EIDs
(15:33:17 PM) marshall: Dino : check sums are turned off on the inner header- sorry Brian - because they are stupid
(15:33:25 PM) marshall: Dino : we added a nonce
(15:33:40 PM) marshall: Dino : IPv6 looks a lot like IPv4  
(15:34:13 PM) marshall: Dino : NO locator reachability in the mapping services
(15:34:25 PM) marshall: Dino : you cannot depend on ICMP unreachables
(15:34:27 PM) yoshfuji [yoshfuji@jabber.org/Gaim] entered the room.
(15:34:31 PM) marshall: Dino : they are commonly turned off
(15:34:49 PM) marshall: Dino : if they come to use, you use them, but don't depend on them'
(15:35:47 PM) marshall: Dino : ITRs know when their partner ITRs go down
(15:35:57 PM) marshall: Dino : green are EIDs and red are locators
(15:36:17 PM) marshall: Dino : let's say that we have 4 locators
(15:36:23 PM) marshall: Dino : 2 are high priority
(15:36:52 PM) dlewis: slide (12) 
(15:37:08 PM) marshall: Dino : as long as they are up, me the ETR are telling you the ITR to load split
(15:38:18 PM) john.zhao [lionnaduo@jabber.cn/Psi] entered the room.
(15:38:18 PM) marshall: Dino : each ITR advertises implicitly which ones are up in a loc-reach-bits bitfield
(15:38:26 PM) marshall: (one bit per locator)
(15:38:32 PM) marshall: you can't get any faster than that
(15:39:16 PM) marshall: If one of the high priority locators goes down, all traffic is sent to the other
(15:39:42 PM) marshall: if both high priority locators go down, then it is ok to use the lower priority ones
(15:40:36 PM) marshall: Q : I thought that locators are routable. If they are, everyone knows their state
(15:40:46 PM) marshall: Dino : Not all of the boxes run BGP
(15:40:50 PM) marshall: Q : Why not
(15:40:56 PM) marshall: Dino : We want to be flexible
(15:41:35 PM) marshall: Jari : You can survive reachability problems if you are receiving ICMP
(15:41:51 PM) marshall: Dino :  You cannot know if they are being aggregating
(15:42:12 PM) marshall: Jari : If packets are dropped on the floor in between you don't know it
(15:42:44 PM) marshall: Dino : I am making the assumption that transit ISPs are transiting. That is a strong assumtion I am making
(15:43:24 PM) marshall: Iljitsch : What if I am a multihomed customer  ? Everyone who is multihomed has to run an ETR box ?
(15:43:47 PM) marshall: Dino : If you deploy the ITRs at PE and not at the site.
(15:44:03 PM) marshall: Dino : if there are not running eBGP you would have to read another protocol
(15:44:18 PM) marshall: Dino : if you deploy LISP you can remove BGP
(15:45:32 PM) marshall: Dino : If you have one CE box going to two ISPs, deploy one. If you have two going to two, you need two
(15:46:13 PM) marshall: Dino : Juniper and Cisco have conditional advertisements. If a link goes down they withdraw the advertisements
(15:46:26 PM) marshall: Christian : Do these go to ?
(15:46:58 PM) marshall: Dino : The ITR describes the reachability at the source site
(15:47:01 PM) lixia: reachability-flag is an opportunity scheme, not that it will get all the ITRs status to all interested parties.  e.g. site A talks to site B, B may learn the status of all A's ITRs.  But site C will not know at time time C starts sending to A.
(15:47:12 PM) marshall: Christrian : Where does the information come from ?
(15:47:45 PM) marshall: Dino :  from the internal routing protocol - there are many exisitng mechanisms.
(15:48:34 PM) marshall: Mark Handley : I am confused. You are sending these bits from your ITR to someone's ETR for their ITR to use. Is there a synchronization problem
(15:48:44 PM) marshall: Dino : Most people want to use both paths
(15:49:03 PM) marshall: Mark : Is the assumption is that the ETR and the ITR are the same box ?
(15:49:10 PM) marshall: Dino : It works much better if they are
(15:49:28 PM) marshall: Dino : Lisp 02 was sent out but didn't quite make the deadline
(15:49:44 PM) marshall: Dino : fixed bugs in packet format
(15:50:09 PM) marshall: Dino : LISP implementation report
(15:50:28 PM) marshall: CISCO has an impklementation
(15:50:39 PM) marshall: started at IETF Prague on DC-OS
(15:50:49 PM) Leslie left the room.
(15:50:56 PM) marshall: Dino : hope we don't have to spin silicon
(15:51:07 PM) marshall: Dino : supports both ITR and ETR
(15:51:41 PM) marshall: Dino : support for multiple EID prefixes per site and static cache mappings
(15:51:59 PM) marshall: Dino : supports priority and weight configuration
(15:52:23 PM) marshall: Dino : put some forwarding options in
(15:53:05 PM) marshall: Dino : you can forward if there is a cache miss - that means that it forwards it natively
(15:53:41 PM) marshall: Dino : you may want to glean mapping in the ETR
(15:53:53 PM) marshall: Dino : this may be useful for mobility
(15:54:14 PM) marshall: Dino : content providers have told me that they want it to work like ARP
(15:54:28 PM) marshall: Dino : with the mapping provided in the first packet
(15:55:48 PM) marshall: Dino : we support sending probes in a separate VRF to support LISP 1.5
(15:56:13 PM) marshall: Dino : LISP 1.0 will probablynever  be deployed
(15:56:41 PM) marshall: Dino : Started unit testing in May 2007
(15:57:01 PM) marshall: Dino : 02 draft unit testing started in June 2007
(15:57:50 PM) marshall: [shows unit test topology]
(15:58:09 PM) marshall: In early July gave Titaniums to Dave Meyer and Vince Fuller
(15:59:01 PM) marshall: Dave's site is behind no firewall
(16:00:17 PM) marshall: Dino : What did we learn
(16:00:40 PM) marshall: Dino : using firewalls gives you another layer of addressing
(16:00:52 PM) marshall: \Dino : firewalls mess around with UDP headers
(16:01:09 PM) marshall: Dino : the ETR didn't care
(16:01:24 PM) marshall: Dino : ITR should encap all packets
(16:01:48 PM) marshall: s/should/should not/
(16:02:05 PM) marshall: Dino : don't encapsulate if there is no mapping
(16:02:12 PM) marshall: (i.e., sent natively)
(16:02:55 PM) marshall: Dino : packet through a LISP ETR is simpler than to a LISP ETR
(16:03:51 PM) dmm613@gmail.com left the room.
(16:04:37 PM) marshall: Dino : future testing 
(16:04:46 PM) marshall: Dino : ipv6 and v4  concurrently
(16:04:54 PM) marshall: Dino : mix pi and pa addressing
(16:05:02 PM) marshall: Dino : testing with BGP
(16:05:16 PM) marshall: Dino : Lisp 1.5 testing with BGP
(16:05:53 PM) marshall: Dino : any interested implementors
(16:05:56 PM) marshall: ?
(16:06:07 PM) marshall: Dino : let us know 
(16:06:15 PM) marshall: Dino : interested in pilot testing
(16:06:24 PM) marshall: Dino : at first on data plane
(16:06:33 PM) marshall: Dino : no production at present
(16:06:42 PM) marshall: Dino : questions ?
(16:08:35 PM) marshall: Suram [?] from NIST : if you get a packet  addressed to your EID ?
(16:08:48 PM) marshall: Dino : If you can forward it natively you do
(16:09:21 PM) marshall: Christian : You need support on both sides if you want to get PI addresses out of the routing table
(16:10:21 PM) marshall: Dino : I f a site is non LISP and it has PI it is injecting into the routing table.
(16:11:29 PM) marshall: Christian :As of now you need an over net transisition. You could learn from anycast - it moves the mapping deeper into the core. 
(16:11:32 PM) lixia: this is how I interpret Christian's comment: a (non-LISP) PI site injects its prefix, some part of the net is LISPized, and other part is not. So the question is whether the LISPized part can have a smaller table.
(16:11:54 PM) marshall: Christian : They could set up a business relationship to do this
(16:12:06 PM) marshall: Dino : I am not sure if this would work operationally
(16:12:22 PM) marshall: Christian : It is a transistion mechanism
(16:14:32 PM) marshall: Christian : There is a disincentive with being an early adopter, because other people who haven't deployed lisp can't reach you
(16:14:38 PM) nm left the room (Replaced by new connection).
(16:14:38 PM) nm [nm@jabber.org/Exodus] entered the room.
(16:14:38 PM) nm left the room.
(16:14:46 PM) marshall: Dino : What if Google deplyed LISP
(16:16:19 PM) yoshfuji left the room (Replaced by new connection).
(16:16:21 PM) marshall: Brian Carpenter :You problem is a legacy site that knows nothing about anything. Your problem is to get that to an ITR - any  ITR
(16:17:03 PM) marshall: Brian : You have to figure out how incentivised the ISPs are to put out ITRs where customers can reach them
(16:17:16 PM) marshall: Dino : Do you have a business case for this
(16:17:18 PM) lixia: one candidate answer to whether EID can be PI or PA: one can avoid this confusing question by using different terminology: (1) we are talking about IP addresses; (2) the only question is whether an address is routable in a given scope.
(16:17:20 PM) marshall: Dino : no
(16:17:28 PM) marshall:   
(16:17:40 PM) marshall: sorry : Brian : No
(16:17:52 PM) sbrim: brian carpenter?
(16:17:57 PM) marshall: [i have to take a bio break - Dave Meyer is next]
(16:17:58 PM) marshall: yes
(16:18:02 PM) marshall: Brian Carpenter
(16:18:03 PM) sbrim: Brian is wrong :-)
(16:18:23 PM) sbrim: but he's an academic as of next month so he's allowed
(16:18:41 PM) jgs@jabber.org: why is brian wrong?  
(16:19:35 PM) sbrim: Within a site, IP routing is going to continue to route subnets etc. which include the things we are calling EIDs.
(16:19:42 PM) sbrim: Currently called IP addresses.
(16:19:46 PM) sbrim: They are in fact locators.
(16:20:09 PM) sbrim: What the various map-and-wrap approaches are doing is reducing the scope within which they are routable
(16:20:14 PM) sbrim: So Lixia is exactly correct
(16:20:21 PM) sbrim: and if Brian says "no" to her, then he's wrong
(16:21:05 PM) jgs@jabber.org: I thought you were referring to his comment at the mic.
(16:21:11 PM) jgs@jabber.org: which made sense to me
(16:21:19 PM) sbrim: I don't have audio anymore
(16:21:22 PM) sbrim: and I'm not in the room
(16:21:28 PM) arifumi: so, the result is "google rules" ;)
(16:21:32 PM) sbrim: All I saw was above: "brian: no"
(16:21:57 PM) jgs@jabber.org: ah.  that was two different conversations being interleaved
(16:22:19 PM) sbrim: Now I see
(16:22:34 PM) jgs@jabber.org: brian's "no" was to dino's request for a business case
(16:22:45 PM) arifumi: (sorry for interuption.)
(16:23:29 PM) sbrim: imho the business case is that the Internet growth rate can be increased dramatically if we can deal with the "rate*state" routing info problem, and the bigger the Internet is the more money the big ISPs make.
(16:25:38 PM) marshall: Dave Meyer
(16:25:41 PM) marshall: Lisp Cons
(16:25:53 PM) marshall: Dave : Cast of thousands
(16:26:16 PM) marshall: Problem statement
(16:26:46 PM) marshall: Dave : just for context
(16:26:56 PM) marshall: Dave : in IPv6 we can split locator and ID
(16:27:09 PM) marshall: Dave : in v4 it is more complicated
(16:27:19 PM) marshall: Dave : Noel calls it a jackup model
(16:27:37 PM) marshall: Dave : you have to jack up the network layer to put more stuff in there
(16:28:56 PM) jo [jo--netlab--tkk--fi@jabber.org/Psi] entered the room.
(16:29:00 PM) marshall: [interrupt]
(16:29:17 PM) marshall: Dave : Sca;ability is a big issue
(16:29:29 PM) marshall: Dave :this is a rate * state problem 
(16:29:34 PM) marshall: [really d state / dt]
(16:29:43 PM) chvogt [chvogt@jabber.org/Home] entered the room.
(16:29:54 PM) marshall: Dave : State will be big, so rate must be small
(16:29:59 PM) nm [nm@jabber.org/Exodus] entered the room.
(16:30:10 PM) marshall: Dave : Lisp cons is a hybrid
(16:30:14 PM) marshall: Dave : push at the top
(16:30:32 PM) marshall: Dave : mappings get pulled at the lowest level when needed
(16:30:41 PM) marshall: Dave : is NOT a DHT
(16:31:10 PM) marshall: Dave : we can get good EID-prefix aggregation if it is based on allocation not topology
(16:31:39 PM) marshall: Dave : Map requests routed through the logical hierarchy
(16:31:49 PM) marshall: Dave : Content Access Routers or CARs
(16:32:02 PM) marshall: Dave : two types - Querying and replying
(16:32:30 PM) marshall: Dave : the mappings live in the replying cars at the bottom of the hierarchy
(16:32:40 PM) john.zhao left the room (¡‹—{:gÛ�eQaw w¶r
`).
(16:32:44 PM) marshall: Dave : there is no place where the entire database is assembled
(16:32:59 PM) marshall: Dave : at the very bottom is ITRs and ETRs
(16:33:18 PM) marshall: level 0 has qCARs and rCars
(16:33:32 PM) marshall: Dave : above them are CDRs in meshes of meshes
(16:34:55 PM) marshall: Dave : ETRs tell CARs which aggregate and push them up to a level of CDRs
(16:36:02 PM) marshall: Dave : if there is a map request, and it isn't cached, it goes up until it finds the map, which then is pushed down to the original qCAR and then to the ITR
(16:36:25 PM) marshall: Dave : CDRs can have siblings, parents and children
(16:37:41 PM) marshall: Dave : we have tried hybrid models
(16:37:57 PM) marshall: Dave : I have tried to merge NERD and CONS to lower latency
(16:38:04 PM) sbrim: Um ... requests don't travel to ITRs.  They travel to replying-CARs which then reply (via the tree) back to the querying-CAR which tells the ITR.
(16:38:45 PM) marshall: Dave : in this case, there is no mesh, but you still pull and push to / from the top level
(16:38:58 PM) marshall: Dave : CARs are default mappers
(16:39:21 PM) marshall: in this case
(16:39:42 PM) marshall: Dave : Is LISP 1.5 suffiecient ?
(16:39:53 PM) marshall: Dave : This is Vince's Idea
(16:39:59 PM) sbrim: CARs are default mappers for control only -- they don't forward packets
(16:40:20 PM) marshall: [but they do forward mappings, don't they ?]
(16:40:37 PM) marshall: Dave : Use BGP on an alternative name space
(16:41:14 PM) marshall: Dave : You run normal BGP on PI space
(16:41:24 PM) marshall: Dave : and BGP on EID prefixes
(16:41:46 PM) marshall: swtich to Dino
(16:42:03 PM) marshall: Dino : Host sends data packet
(16:42:30 PM) marshall: Dino : it's sent on an alternate typology
(16:42:48 PM) nm left the room.
(16:43:15 PM) marshall: Dino : Moving it out of expensive memory for PI BGP to cheaper memory, and maybe even different devices 
(16:44:05 PM) marshall: Dino : This eventually does to the destination ETR, which sends back the mapping
(16:44:24 PM) marshall: Dino : And the next packet uses it
(16:44:49 PM) hantula [hantula@jabber.org/Adium] entered the room.
(16:44:57 PM) marshall: Joel : This seems to imply (1.5) that those who allocate EIDs also pick up a packet forwarding responsibility
(16:45:14 PM) marshall: Joel : We lose some flexibility
(16:46:03 PM) marshall: Vince Fuller : Yes, and no. You use this overlay network to forward query. In that sense this separate typopology is just a way of implementing hte database
(16:46:19 PM) marshall: if you use it for forwarding data then you are correct
(16:46:37 PM) marshall: Dino : We have this trade off that people have told us, you cannot drop a single packet
(16:47:39 PM) marshall: Dino : You can stretch is out, but not drop it. Others have said, you can drop, but we care about latency


(16:48:03 PM) marshall: [Question about how this like DNS]Vince : People are absolutely 
(16:48:22 PM) marshall: Vince : People are absolutely
terrified about overlaying anything on the DNS
(16:49:41 PM) john.zhao [lionnaduo@jabber.cn/Psi] entered the room.
(16:49:46 PM) marshall: Darryl Lewis : There is a difference. When a qCAR makes a recursive lookup, it follows the topology in both directions. There are some interesting security implemtnations about this
(16:50:21 PM) marshall: Mark : It seems there are two route questions  : Can the ITR hold the entire mapping database, and will they have to ? 
(16:50:38 PM) marshall: Mark : It seem that they will, and that pushes me towards NERD and a push model
(16:50:42 PM) lixia: To Kevin's question: in CONS, all data flows along configured links to neighbors only, for security consideration.
(16:51:04 PM) marshall: next is Luigi 
(16:51:09 PM) lixia: in DNS, any resolver can send to any server directly
(16:51:43 PM) null0: That's true theoretically, not necessarily in practice.
(16:51:59 PM) null0: (BCP is to ensure that isn't the case)
(16:52:02 PM) sbrim: right, it gets complicated
(16:52:06 PM) marshall: Luigi : Thanks for remaining for the last presentation !
(16:52:16 PM) marshall: Luigi : IT networking lab in Belgium
(16:52:27 PM) marshall: Luigi : starting to talk with Dino to impement LISp
(16:52:55 PM) marshall: Luigi : We asked ourselves about the costs for making lookups and caches
(16:53:14 PM) nm [nm@jabber.org/Exodus] entered the room.
(16:53:23 PM) marshall: Luigi : We started making traces using netflow on our border router, conectect to Belnet with a 1 Gbps link
(16:53:31 PM) nm left the room.
(16:53:31 PM) marshall: Luigi : ~ 10,000 users per day
(16:53:54 PM) marshall: Luigi : basic assumption is a /BGP granularity for the mapping
(16:54:08 PM) marshall: assign one locator to each BGP prefix
(16:54:20 PM) marshall: Luigi : How many prefixes per day ?