[01:21:28] mawatari joins the room [06:53:35] mawatari leaves the room [07:47:21] Lori joins the room [10:00:49] Melinda joins the room [10:32:36] Terry joins the room [10:47:03] florin.coras joins the room [11:01:02] gigix73 joins the room [11:04:17] Antony joins the room [11:04:52] wmhaddad joins the room [11:05:24] Antony leaves the room [11:05:31] Antony joins the room [11:06:00] jpc joins the room [11:08:06] spadgett joins the room [11:11:13] there's no official jabber scribe for this so I'll try and post a few notes [11:11:22] thx [11:12:25] they're doing a number of updates, they had 80 proposed changes. about 30 were things they decided not to make changes on, the other 50 they're looking at making changes [11:12:52] are there any of the slides online so we can look at them while listening to the audio...? [11:13:03] they want more discussion on: lisp & urpf anonymous tunneling; map-cache validation; etr failure restoration; PIvsPA; re-encapsulating tunnels underspecified [11:13:26] comment from room- if you are a reviewer, you should provide suggested text [11:14:15] http://tools.ietf.org/wg/lisp/agenda?item=agenda78.txt [11:14:17] slides are linked off from here - http://tools.ietf.org/wg/lisp/agenda?item=agenda78.html [11:14:25] current doc being discussed slides - http://tools.ietf.org/agenda/78/slides/lisp-7.ppt [11:14:33] thx [11:14:48] wilmer joins the room [11:18:18] essentially, it was recommended that you follow the mailing list for these items and respond to the list if you want to comment on it. no other comments/questions on that preso [11:21:20] map-server discussion - draft says that anycast cannot be used since there needs to be a security association, an anycast relationship would likely break this [11:21:58] ms spec - bgp security - if cidr recommendations are applicable you could use that [11:22:41] no comments/questions from room [11:26:04] lisp multicast - changes since last ietf - discussion of receiver sites joining the same source site via 2 RLOCs; s/mPTR/smPETR/ to be more consistent; adding clarifications regarding homogenous multicast encap; indroduced conecept of mPITRs to help reduce (S-EID,G) to the edges which helps things scale better [11:27:07] presenter is looking to have a working implementation of lisp multicast in the fall [11:27:17] presenter=Farinacci [11:28:15] no changes to LIG [11:29:57] map versioning - there was discussion on 2 different ways to do versioning; draft picked one [11:30:16] 12 bits for source map version and 12 bits for the destination map version [11:31:02] change from last draft -- map version 0 is now "special" -- there is no map-version associated with record, and do not send traffic to this eid-prefix using versioning [11:33:10] question from floor - how is staleness detected [11:33:50] answer - notion of ordering in the version (always incrementing) so if you get a higher version you know the old one is stale [11:34:14] going to move forward with wg document process [11:36:22] security - spoofing and non-spoofing attackers (non-spoofing can spoof lisp fields, just not sources) [11:36:42] data-plane attacks can also target control plane [11:38:52] eliot.lear joins the room [11:39:27] in short, there's a ton of different ways to attack/dos lisp ... read the draft to get a full list, I can't type that fast :) [11:41:58] sandy from the security area will start helping out with this as well to try and identify additional attack vectors and areas of risk [11:42:39] question from floor - should "hijacking" be listed in the "why" section (in addition to "eavesdropping") [11:43:03] comment- it may be fine to just document some of these rather than fix them, depending on risk [11:45:07] lcaf - afi 16387 assigned by iana for lisp lcaf [11:45:17] rababy joins the room [11:45:38] wilmer leaves the room [11:47:08] Antony leaves the room [11:47:14] Antony joins the room [11:48:45] lcaf - type 4 "Application Data type" allows protocol/srcdst port/tos/flow label to be stored [11:49:12] comment from room - document needs to spell out which use cases are in the charter; use cases that aren't in the charter need to come out of the doc [11:50:48] comment from room - (1) don't worry about the charter, these are generic capabilities that can be used in various ways; (2) questions about why this is needed, some/most of this can be done already, do we need this extra complexity [11:52:06] answer for (2) this isn't really that complex, just requires more parsing code; encapsulation is not complex [11:52:35] presenter - we need more comments from operators as to what is required [11:53:16] eliot.lear leaves the room [11:59:03] nordmark joins the room [11:59:13] managing holes in maps - discussion of problem statement; see slides for details - http://www.antd.nist.gov/~ksriram/EEMDP_Slides_July2010.pdf [12:01:29] basically, the simple(?) way for managing holes in the maps would result in about 9.37x maps than if you were to just notify on the exceptions [12:06:19] "case 4" in slides ("prioritized subset of maps for exception - more-specifics are communicated") is a new case that wasn't in the anahiem meeting [12:11:07] general concerns from floor with that case - may result in a large # of queries if you don't get the holes back and you are not falling into the holes with the mapping requests [12:12:35] Melinda leaves the room [12:17:39] comment from floor - concerned about the complexity of the first 3 cases; 4th case is controversial [12:18:17] comment from floor - no one can know how many exceptions there are. once you delegate an eid prefix you don't know what the delegations are doing with it [12:18:29] comment - if you delegate it downstream then you're no longer answering for it [12:20:17] lisp mobile node - http://tools.ietf.org/html/draft-klein-lisp-mn-nat-traversal-00 -- lsip mobile nodes not reachable behind NATs, this suggests a nat traversal router [12:22:49] problem statement clarification - problem is with traffic being sent to the mobile node, eg if it was a telephone [12:29:50] comment from dino - don't like carrying private ip addresses in the payload, there might should be a way of figuring out the public IP address [12:30:13] answer - private ip address isn't being used except for comparison [12:33:24] Antony leaves the room [12:33:49] question - what happens if a lisp mobile node moves into a lisp site behind a nat? answer, that was not yet considered [12:34:52] comment - this combines the control & data plane, it may be preferred to keep them separate [12:36:08] question - how do you know the person sending you the request is authorized to register [12:36:44] comment - you can use existing mechanisms for authentication/authorization [12:37:31] [end of lisp wg] [12:38:30] gigix73 leaves the room [12:38:38] rababy leaves the room: Computer went to sleep [12:38:52] jpc leaves the room [12:38:53] florin.coras leaves the room [12:40:22] Terry leaves the room [12:41:13] Lori leaves the room [12:42:10] wmhaddad leaves the room: Logged out [12:48:34] spadgett leaves the room [12:48:59] spadgett joins the room [12:49:22] CAOZHEN158F69E8 joins the room [12:49:26] CAOZHEN158F69E8 leaves the room [12:49:35] Zhen Tsao joins the room [12:55:41] nordmark leaves the room [13:00:59] Zhen Tsao leaves the room [13:14:56] spadgett leaves the room [13:26:19] wmhaddad joins the room [14:21:36] wmhaddad leaves the room