[10:59:38] --- leslie-ietf has joined [11:51:39] --- dthaler has joined [11:56:13] --- iljitsch has joined [11:59:10] --- leslie-ietf has left [11:59:51] --- rhe has joined [12:02:37] --- touch has joined [12:02:58] --- touch has left [12:04:01] I'm jabber scribe [12:04:05] someone is taking minutes [12:04:11] --- gih900 has joined [12:04:12] --- touch has joined [12:04:17] --- touch has left [12:05:01] tony li: our charter is to make one proposal or recommendation, so we want to start converging into that direction but the floor is still open to new proposals [12:05:06] --- rvdp has joined [12:05:15] --- shikob has joined [12:05:45] dave meyer: are we going to develop objective criteria to sort this out? [12:06:02] tli: we have a document on design goals and one on taxonomy [12:06:25] --- jgs@jabber.org has joined [12:06:37] dm: maybe we have to develop a methodology for this [12:06:59] --- touch has joined [12:07:10] tli: presenters of proposals will hold those proposals up to goals and there will be criticial discussion [12:07:25] --- presnick has joined [12:07:32] --- benno@jabber.secret-wg.org has joined [12:07:42] --- dcrocker has joined [12:07:46] someone at the mike: lixia and I talked about this but... [12:07:57] tli: mailinglist is open [12:08:39] (these jabber notes aren't going to be very good, I can hardly hear the people at the mike and nobody is saying their name) [12:08:54] there will be a list of proposals [12:09:08] tli: everything is still on the table, not taking them off the table just yet [12:09:13] also look at the wiki [12:09:21] --- leslie-ietf has joined [12:10:23] slide says: [12:10:31] start driving towards convergence march 08 [12:10:39] attain rough consensus via debate etc [12:10:43] conclude by march 09 [12:11:13] jari arkko: still questions about whether things can work in practice [12:11:40] geoff juston: we've been here before with multi6 [12:11:58] we tried to take proposals and create a more general architecture from that [12:12:07] then classify proposals in terms of that architecture [12:12:17] --- presnick has left [12:12:19] --- washad has joined [12:12:29] don't think wiki summery is going to cut it here, things are deep and complex [12:12:41] need to evaluate in a consistent architectural framework [12:13:00] tli: agenda bashing [12:13:20] agenda for friday has much LISP [12:14:00] simon schuetz, node identtity internetworkng architecture [12:14:03] up now [12:14:19] --- resnick has joined [12:14:52] niia is not: [12:14:59] not purelay a routing architecture [12:15:03] not ITR-ETR based [12:15:08] not transparent for end-hosts [12:15:13] not incremental update to bgp [12:15:19] it is not unifiying the network layer [12:15:21] it is: [12:15:25] new internetworking arc h [12:15:29] id/loc split approach [12:15:41] framework for netw routing approaches [12:15:57] accepting the existence of different networking technologies: v4, v6, even 3G [12:16:17] everything is a "node" [12:16:23] with a hip-like crypto identifier [12:16:32] nodes are interconnected and have locators [12:16:50] nodes are grouped in locator domains [12:17:15] NID routers bridge bettween LDs [12:17:55] node identities are ~ public key [12:18:15] node identity forwarding tag (NIFT) is fixed length has of NID [12:18:36] one or small number of core LDs [12:18:47] other LDs hang off of the core [12:19:07] registration based default routing mechanism [12:19:14] open to other routing schemes [12:19:32] joel helpern: how central to your proposal is the core/hanging off idea? [12:19:50] nervous with having a center [12:20:14] simon: is relatively static [12:20:25] effects of LD concept: [12:20:34] don't have to unify on one networking technlogoy [12:20:43] locators don't have to have meaning outside locator domain [12:20:56] hides LD internal structure from outse LD [12:21:14] mobility can be localized [12:22:00] (please look at "default routing overview" slide) [12:22:35] nodes register their NID/NIFT [12:22:57] to all NRs (don't know what those are) in the path towards the core [12:23:22] --- pellepolis@gmail.com has joined [12:23:33] first-hop NID router takes care of the rest [12:23:44] so node only registers there [12:24:52] again, see slides [12:27:46] --- benno@jabber.secret-wg.org has left [12:28:08] --- benno has joined [12:28:24] (explanation of packet flows going on) [12:28:32] forwarding options: [12:28:41] no per-session or per-comm-pair state [12:28:53] NID header must be present in each packet, follwoing IP header [12:29:13] cointains dstNIFT dstHint, srcNIFT, srfHint [12:29:20] possibly more, can get large [12:29:58] I think he's saying the header can later be suppressed but it says "must be present in every packet" on the slide.... [12:30:11] oh wait, the above was stateless approach [12:30:21] in stateful approach you install state and then... [12:30:37] anonymous on the mike: [12:30:49] how does network mobility work? [12:30:56] simon: no answer at this time [12:30:59] Eric Fleischman on the mic, FWIW. [12:31:11] other routing approaches are possible [12:32:58] global naming system: [12:33:11] in niia source node must lookup dest NIFT, dest hint [12:33:22] (sorry slides are going a bit fast now) [12:33:28] node mobility: [12:33:36] mobi expected at edges [12:33:39] --- badra has joined [12:33:49] intra-LD mobi can be handled inside LD [12:34:00] inter-LD requires re-registration of node [12:34:21] NR within the core LD can serve as "home agent" [12:34:53] --- badra has left [12:35:01] network mobility: [12:35:12] requires NR(s) of the moving network reregister [12:35:20] also update node registrationinformation [12:35:30] easy with recursive registration scheme or in batch mode [12:37:26] open design issues: [12:37:38] niia is not a routing protocol as such [12:37:52] routing hint lookup ssystem, depends on the nature of the routing hint [12:37:54] (...) [12:38:01] prototype [12:38:13] based on HIP implementation [12:40:36] see the draft and two other references in the slides [12:40:56] question that I didn't understand [12:41:34] another question that I didn't follow [12:42:01] simon is done [12:42:04] If you're referring to my question it was to establish that this proposal is (at least) a proposal for a new internetwork later [12:42:06] layer [12:42:19] next up: sheng jiang, hierarchical routing architecture [12:43:01] jgs: yes, seems that way with IP on top to be backward compatible [12:43:18] LDs sound a lot like OSPF areas [12:43:28] sheng jiang: [12:44:01] refers to issues coming out of routing/addressing workshop [12:44:37] hourglass diagram with IP layer veering off into identifier and locator parts [12:45:14] there are other approaches like shim6, HIP, LISP, ENCAPS, HLP [12:45:22] iljitsch: I'd say that with with IP - optionally - underneath, not on top. Maybe it depends on which way up you hold your diagram... [12:45:26] HRA is id/loc split solution [12:45:52] multiple LD domains (I think, LD is singular on the slide) [12:46:31] jgs: hm yes in the packet underneath but I'd say conceptually on top [12:46:52] sj: reuse of addresses in different LDs [12:47:05] --- tom5760@gmail.com has joined [12:47:15] hierarchical host identifier tag: combo of management domain ID and has of host identifier = public key [12:47:23] hiearchcical mapping system [12:47:30] HIT as the lookup key [12:48:06] 2-level hierarchical routing [12:48:10] inter-ld and intra-ld [12:48:22] locator domain border routers exchange LD reachability info [12:48:34] LDBRs only store LD-ID based routing info [12:48:41] internal routers do prefix-based routing [12:49:41] see slide for packet flow overview [12:52:14] --- benno has left [12:54:56] flat host identifier taqg [12:55:01] has scalability issues [12:55:20] hierarchical host identifier tag [12:55:33] combinationo f management domain id and hash of HI [12:55:37] easier manangement [12:55:51] --- benno has joined [12:55:51] allows for highly efficient lookup system [12:56:31] again missed a question at the mike [12:56:51] sj: we have duplication detection mechanisms in ipv6 [12:57:25] each locator domain is relatively small, no way to deploy a global duplication detection mechanism, but within an LD it's possible [12:57:58] hierarchical mapping system [12:58:08] --- nm has joined [12:58:18] each management domain which may cover multiple LDs has at least one local mapping server [12:58:34] --- nm has left [12:58:53] --- arifumi has joined [12:58:57] lookup requests for non-local MDIDs are forwarded to remote locator domain and come from the mapping server there [12:59:32] --- arifumi has left [13:01:43] --- washad has left: Computer went to sleep [13:01:48] routing table size in all routers will be greatly reduced [13:01:59] --- arifumi has joined [13:02:01] stability improved, reusable locator space [13:02:15] supports communication between heterogenous networks [13:02:26] management of global HIT space becomes practical [13:03:03] opne issues: ld managment, merge and split [13:03:08] routing policy [13:03:12] incremental deployment [13:04:13] question about end system identifiers: [13:04:25] if I move I need to change that identifier? [13:04:30] how do people find me? [13:04:43] answer: no, you change your registration in the mapping system [13:05:25] q: there can be billions of entries [13:05:35] a: you have a home mapping server [13:05:42] --- jgs@jabber.org has left: Replaced by new connection [13:05:47] q: so standard mobility [13:06:01] another questioner: [13:06:11] can't understand it [13:06:22] audio is way too low and I'm sitting next to the door to the kitchen [13:06:56] answer: when you move you don't change your identity, only your locator [13:07:06] q: my name is still based on my own country [13:07:15] a: when you move you keep your citizenship [13:07:23] another questioner: [13:08:08] you're basically replacing the network layer [13:08:38] up next: [13:08:47] christian vogt, the path to six/one [13:09:13] we've known for a long time that there's something wrong with interdomain routing scalability [13:09:18] why is change so hard? [13:09:26] because we need a good transition path [13:09:58] on the mailinglist we've seen that there is a transition path for 6/1 and in this talk I'll talk more about that [13:11:13] address bunch: routing prefix + crypto interface id (= ipv6) [13:11:23] routers may rewrite soruce address [13:11:34] host recognizes and adapts [13:12:33] see slide for diagram [13:15:55] --- sftcd has joined [13:16:33] routers don't rewrite addresses before session establishment to preserve backward compatibility [13:18:27] transition path: [13:18:28] --- havard.eidnes has joined [13:18:36] small routing table, less frequent table updates [13:18:45] packet flow redirection ability [13:18:49] reduced renumbering costs [13:18:57] hosts cna influence path selection [13:19:00] --- jpc has joined [13:19:08] light-weight ipv6 crypto [13:19:13] cross-layer optimization [13:19:23] deployment flexibility and backward compatbility [13:19:43] --- nm has joined [13:20:36] --- nm has left [13:21:07] new transition tools [13:21:17] proxiies run 6/1 on behalf of host [13:21:36] translators (???) [13:26:31] --- pellepolis@gmail.com has left [13:26:38] (explanation of proxy operation details, plz see slides) [13:31:55] proxies are used to interface legacy host with 6/1 [13:32:42] translators are used to communicate with remote legacy hosts (6/1 agnostic at the other end) [13:33:07] proxy and translators can ben combined for v4 support [13:34:25] six/one proxy can redirect/map/translate addresses to bridge ipv6 to ipv6 [13:34:32] sorry ipv6 to ipv4 [13:34:39] and vice versa [13:35:38] v4 gateways interconnect v6 edge networks via v4 internet [13:36:18] v4 gateway operation explained in detail... (see slides) [13:37:02] --- havard.eidnes has left [13:37:32] conclusions: three techniques to improve transition path [13:37:34] --- jgs@jabber.org has joined [13:37:55] --- rhe has left [13:38:08] higher deploymnet flexibiliyt, benefits legacy hosts, backward compatibility with v4 [13:38:16] --- jgs@jabber.org has left [13:38:42] --- jgs@jabber.org has joined [13:38:44] flexible, arbitrary composition, depending on need [13:38:58] reusabel for v4 to v6 transtions [13:39:04] many people at the mik [13:40:03] cv: allow the host to be v6 gateway (allows transition to v6 ) [13:40:33] cv: need transition to complete v6 address space [13:40:56] question: need for solution with less work, don't see thsi in this solution [13:41:18] cv: it is an automatic solution [13:41:23] jari at mike [13:41:35] avoid host changes by using proxy [13:42:11] cv : it does require changes , but not in neighbor discover [13:42:23] need for dhcp [13:42:48] --- sftcd has left: Computer went to sleep [13:42:57] I was at the mic first; asked why proxies/translators/gateways would work here when they haven't for v6 for the many years now. The answer appears to be that this solution provides more options to the end host; IMO, that's a step in the opposite direction of what's needed. (repeated here for the archive) [13:42:58] another comment by jari [13:44:07] is the pain bad enough for these solutions? [13:44:19] (pain in the routing infrastructure) [13:45:15] jari: comment, liked 6/1 in its original proposal, but now tries to do all other things others also do [13:45:48] cv: back to earlier question, dhcp, [13:46:02] other solution with preconfig [13:46:14] missed name at the mic [13:46:20] dow street [13:47:06] --- trond has joined [13:47:27] dow street: question the length/range of influence of a host on the routing ? [13:48:09] cv: the edge network needs the ability to do traffic engineering. [13:48:55] when edge network does not need traffic engineering, the host is in charge to routing [13:49:06] derryl? at mic [13:50:17] question: are you concerned about the amount of state a proxy has? some domains are large ... [13:50:23] cv: don't think so [13:50:37] similar to ingress router [13:51:42] does failure of proxy impact on session? [13:51:47] cv: yes, it does [13:51:59] (same for ingress tr) [13:53:31] one more comment by cv [13:53:49] transition path is long if we go as derryl pointed out. [13:54:17] we should do transition net sequential, but at the same time [13:54:38] derryl say, that the time frames could last for ever [13:55:48] next speaker, petri jokela, integrated six/on HIP implementation [13:56:17] there is a six/one implementation, now combining this with HIP [13:56:23] functions quite similar [13:56:52] intergrating six/one into hip to maximize reuse [13:56:54] --- rhe has joined [13:57:11] diffrerent, no traffic eningeering in HIP [13:57:27] HIP basics: associated settup [13:57:59] hist identity associated with one or more IP addresses [13:58:23] applications see only HI, IP address for routing [13:59:08] SA created during 4-way handshake, currently ESP [13:59:22] (SA security association) [13:59:50] comparing functionality six/one-hip [13:59:59] --- arifumi has left [14:00:15] in six/one six req. identified [14:00:17] --- arifumi has joined [14:00:26] ip address conf, exists in hip [14:00:35] ip address selection, does not [14:00:47] florw rediriection, does not [14:00:57] address ownership, exists in hip [14:01:05] ip address mapping, exists [14:01:13] context establishment, exists [14:01:21] IP configuration [14:01:58] HIP: SPI based on interface (small modification to HIP) [14:02:11] IP address selection [14:02:21] --- touch has left [14:02:40] flow redirection [14:03:07] HIP basically end-host protocol: not hip related, a new function in the router [14:03:15] end host related: [14:03:32] Address ownership [14:03:47] HIP : host identities, reachability exists [14:03:57] IP address mapping [14:04:15] HIP: host identities on upper layers [14:04:30] HIP: IP-> host identity conversion already done [14:04:42] Context establishment [14:04:59] HIP: Base exchange -> HIP association [14:05:12] (authentication of hosts, ip address exchange) [14:05:28] summary: six/one implementation [14:05:44] basedd on current HIP for BSD http://hip4inter.net [14:05:52] implementation started [14:06:04] required modifications are small [14:06:23] onl major is address rewriting in the network [14:06:45] question christian vogt [14:06:56] one lsides mentioned cga [14:07:31] cga is public key authentication,but not necessary in six/one (is clarification by cv) [14:08:00] next speaker fred templing, boeing [14:08:21] simple protocol for robust tunnel endpoint mtu determination [14:08:52] mtu determination problem, explanation by figure [14:08:56] see slides [14:09:33] different mtu allong the path to destination [14:10:06] tunnel mtu issues, ipv4 path mtu discovery has limitations for tunnels [14:10:34] e.g. packets too big, results in undiagnosable black hole [14:10:52] unmitigated IPv4 fragmentation is harmful [14:11:53] challenge: tne cannot blindly send big packets into the tunnel with dont fragment = 0 [14:12:05] set of goals on slide [14:12:36] robust, maximize deliviery ration, manage fragmentation, avoid in-the-netwokr fragmentation [14:12:43] ... [14:12:52] Solution: SPRITE-MTU [14:13:07] UDP echo service for MTU discovery [14:13:10] --- tom5760@gmail.com has left [14:13:22] softstate management to track tunnel parameters [14:13:30] explicit congestion notification [14:13:43] imporoves operating conditions, [14:13:59] relevant elements of normative specifications [14:14:07] rfc2003 [14:14:18] and just must the other (see slide) [14:14:48] configuration knob for fragmentable outer packets [14:15:41] avoid tfe receive buffer overrun, and avoid/minimize fragmentation on the TNE->TFE path [14:16:06] setting the configuation knob [14:16:25] setting DF: DF=1 in all packets large than threshold, [14:16:43] set DF=1 even if TNE fragments packets beofre sending [14:16:52] may set DF=0 to incread pdr [14:17:12] send big packets into tunnle [14:17:24] --- rvdp has left [14:17:34] set DF=1, but also send PTB back to source [14:17:51] what if it might be fragmenting? [14:18:07] if probe size is smaller, relax pacing [14:18:35] soft state management protocol [14:18:56] TNE creates soft state send to TFE [14:19:06] TFE send reply [14:19:25] TNE sends sprite using TFE's currint sprite address [14:20:02] sprite-mtu checksum sums every 10th byte of hte packet using the Fletcher-16 algorithm [14:20:11] --- dcrocker has left [14:20:24] explicit congestion notification [14:20:48] TNE sets ECT(0) or ECT(1) codepoints in its sprites [14:21:19] --- peetu has joined [14:21:30] Futures, IEEE 802.3as frame expansion proposes large than 1500 MTUs for 802.3 links [14:21:45] larger, EMTU_Rs for tunnel endpoints [14:21:56] gigabit ethernet 9kb jumboframes [14:22:00] todo: [14:22:20] some encapsulation dangerous with any level of outer fragmentation [14:22:28] (e.g., Teredo) [14:22:48] solution (UDP fragmentation for teredo) [14:23:24] other thing to do: use ICMP echo request/reply as fallback if TFE does not implemnet sprite-mtu [14:23:45] iljitsch at mic [14:24:33] what kind of MTU will send hosts to each other over the tunnel with different MTUs in between [14:24:47] at end points is MTU 1500 [14:25:12] in the tunnel no large than MTU 1500 minus encapsulation overhead [14:26:04] what happens with 1500 byte packet, and tunnel header must be added, what happens? [14:26:34] than packet size is to large, and should be set smaller [14:26:53] --- resnick has left: Lost connection [14:27:29] next question by iljitsch [14:27:57] if we go to an ITR solution, is it acceptable to create these blackholes? [14:28:22] or do we require people to run ITR use jumbo frames. [14:28:48] answer, if you run ITR, it is suggested you used 2k MTUs [14:29:03] tony li: any other topics for discussion? [14:29:08] --- peetu has left [14:29:12] --- shikob has left [14:29:25] tony li: ok, it closed, see you all friday morning [14:29:39] --- benno has left [14:29:45] --- arifumi has left [14:31:57] --- gih900 has left [14:34:41] --- iljitsch has left [14:45:37] --- trond has left [14:45:48] --- jgs@jabber.org has left [14:46:00] --- leslie-ietf has left [15:04:43] --- jpc has left [15:11:39] --- dthaler has left [16:06:00] --- dthaler has joined [16:24:04] --- gih900 has joined [17:00:56] --- benno has joined [17:01:47] --- benno has left [18:03:08] --- gih900 has left [18:15:53] --- dthaler has left: Replaced by new connection [18:16:39] --- gih900 has joined [18:30:29] --- gih900 has left [23:07:20] --- Tony Li has joined [23:12:12] --- Tony Li has left [11:55:57] --- iljitsch has joined [12:00:42] --- arifumi has joined [12:01:15] --- Doug Hantula has joined [12:01:20] /subject RRG friday morning, all LISP all the time [12:02:44] --- mohsen has joined [12:02:59] --- Joe Touch has joined [12:03:04] --- trond has joined [12:04:09] --- eliot.lear has joined [12:04:17] hello [12:04:23] i'll be your jabber scribe [12:04:24] hi [12:04:26] hi eliot [12:04:29] thx! [12:04:31] thank you [12:04:38] if you have a question you would like voiced, please preface it with MIC: [12:04:51] there is limited time, and so tony and lixia will probably limit questions [12:05:02] I'll do backup if Elliot goes to the mic. [12:05:09] thanks, joe! [12:05:11] --- bhoeneis has joined [12:05:11] thx Joe [12:05:26] tony has brought the meeting to order [12:05:33] the LISP "extravaganza" is about to begin [12:05:35] dino is up front [12:06:11] I hear Dino [12:06:26] --- rhe has joined [12:06:36] this is a delta update from the Chicago RRG [12:06:57] presentation agenda bashing! [12:07:19] we're dropping NERD, EMACS, and CONS presos [12:07:28] this should leave more time for discussions [12:07:46] who got the URL of Dino's presentation (Tutorial) of yesterday? [12:08:14] added mobility section to the text [12:08:25] any mobile-ip & mipv6 can run on top of LISP [12:09:03] hundreds of reviewers at this point [12:09:08] building a negative mapping entry [12:09:26] this means that the destination prefix is not LISP capable [12:09:48] inter-router links are at 4470, so don't worry about MTUs [12:10:01] --- mtjabber has joined [12:10:18] new udp port number 4341 [12:10:24] this removes a data check [12:10:44] simplified data plane [12:10:53] reduced the nonce 48 to 32 bits [12:11:13] packet format now up on screen [12:11:25] locator reachability bits are now 32 bits [12:11:35] format of control plane packets haven't changed [12:11:48] inside header built by host. outside header built by ITR [12:12:01] --- xiaohunhun has joined [12:12:15] clarified use of UDP checksums [12:13:16] not checksumming [12:13:33] Lars: you could use UDP light which is there just for this purpose [12:13:45] tim shepherd: required in ipv6 because ipv6 has no checksum [12:14:06] dino: we have much bigger fish to fry [12:14:21] lars: ok, but we need to work this out- violating rfcs isn't a nice thing to do [12:14:31] R-bit added to map-reply [12:14:47] "i want to use ones that are local v. ones that are in the header" [12:14:58] now moving on to database designs [12:15:44] if you build a network based solution, the main problem is that the packet comes to a box, and if you don't have the mapping state, you can drop and "arp", you can queue the data until you get a reply (not scalable), or you can send the data and make the data part of the request [12:15:50] everyone is split on this issue [12:15:57] --- nm has joined [12:15:58] many say dropping packets is not bad [12:16:04] others say "every packet is precious" [12:16:40] --- lars.eggert@googlemail.com has joined [12:16:44] where do you put the mapping, where do you find it? do you push? or do you pull it only on demand? use secondary storage? [12:16:51] how do you prevent dos attacks? [12:17:12] keith moore: who controls it? how does it get paid for? how do you keep it out of the control of unsavory governments? [12:17:23] dmm: can we leave policy until later? [12:17:28] dino: agree [12:17:45] keith: these things interact. i don't want to drill down into policy now, but you should be thinking about it now [12:17:53] dmm: (repeats same question) [12:18:02] keith: let's not repeat ourselves [12:18:13] chair: rathole [12:18:41] --- shikob has joined [12:18:51] we're not talking about a bunch of mappings, just due to time constraints [12:19:07] the new one is LISP-ALT and it fits with 1.5, and we'll talk about it today [12:19:30] we added LISP-EMACS - multicast-based. [12:19:52] we are going to backburner some proposals... [12:20:07] all have some of the same assumptions [12:20:23] subscription-based mapping [12:20:40] locator reachability kept out of the databases [12:20:47] don't depend on any other security design or infrastructure [12:22:08] cons and nerd are control-plane based [12:22:17] data plane- 1.0, ALT, EMACS [12:22:32] --- benno has joined [12:22:35] ALT & EMACS use alternate topologies [12:23:02] prototyped mobility design [12:23:35] jari: [12:23:38] were there host changes? [12:23:41] dino: no [12:23:46] just lisp itr and etr changes [12:24:31] this doesn't require host routes - but does require more state in the ETR [12:24:46] we're putting the design on the shelf now, because there are a lot of unresolved issues [12:24:57] --- nm has left: Replaced by new connection [12:24:58] --- nm has joined [12:24:58] (like security) [12:25:07] we'll talk about interworking later [12:25:25] in a lisp site, we want to be able to detect a non-lisp site [12:25:32] what addresses do we use for each? [12:25:36] darrell will go into details [12:25:40]