[04:55:41] --- sureshk has joined
[04:55:46] --- sureshk has left
[13:45:31] --- tsavo_work@jabber.org/Meebo has joined
[13:52:10] --- sureshk has joined
[13:54:00] --- psavola has joined
[13:54:16] --- jariarkko has joined
[13:55:02] <jariarkko> By the way, I am in another WG meeting of mine (this may explain why I want to some of my groups to merge)
[13:55:21] <jariarkko> Please find a jabber scribe, I'm monitoring.
[13:56:58] <tsavo_work@jabber.org/Meebo> (can't help on that, I'm listening on remote audio)
[13:58:30] <sureshk> i will scribe jari
[13:58:34] <jariarkko> tnx
[13:58:55] <sureshk> satya is talking abt router operation
[13:59:17] <sureshk> routers listen to RAs from other routers
[13:59:28] <sureshk> and create a learned prefix list
[13:59:37] --- narten has joined
[13:59:37] <sureshk> so that they can eventually send a complete RA
[14:00:20] <sureshk> the routers MUST advertise
[14:00:25] <sureshk> the smallest prefix on the link
[14:00:34] <sureshk> so that there is always a common prefix
[14:01:15] <sureshk> fast ra is a mechanism for determining the order in which routers would respond to an RS
[14:01:28] <sureshk> this part of the document has not changed at all
[14:01:39] <sureshk> the steps of dna
[14:02:06] <sureshk> 1) When link up received set all addrs to optimistic
[14:02:21] <sureshk> I will summarize briefly
[14:02:28] <sureshk> the slide lists all the steps
[14:02:49] <sureshk> the host acquires an RA
[14:03:16] <sureshk> after this the host needs to determine if there has been a link change
[14:03:28] <jariarkko> (i'm looking at the slides. noneed to repeat slides. say what slide we are on, plus discussion.)
[14:03:44] <sureshk> slide 7
[14:04:02] <sureshk> slide 8
[14:04:17] <sureshk> the bottom line is
[14:04:50] <sureshk> if there are no overlapping prefixes between the received RA and the DNAHostPrefixList
[14:05:07] <sureshk> the host can determine that there has been a link change
[14:05:25] <sureshk> open issues
[14:05:28] <sureshk> slide 9
[14:06:11] <sureshk> discussing flash renumbering
[14:06:51] <sureshk> erik would like a recommendation to admins to not do immediate reassignment of prefixes
[14:06:57] <sureshk> sathya agrees
[14:07:12] <sureshk> discussing router config variables
[14:08:25] <sureshk> sathya explains the vars
[14:09:04] <sureshk> you can find the definitions in section 5.1.2 of the protocol draft
[14:09:56] <sureshk> Erik would like these to be protocol constants
[14:10:25] <sureshk> he wants to know if routers need to make these configurable knobs
[14:11:33] <sureshk> thomas thinks they should be protocol constants if they do not need to be tweaked
[14:12:18] <sureshk> he thinks they are too complicated to tweak
[14:13:47] <sureshk> thomas does not want to force implementers to implement a knob that may never be changed
[14:16:17] <sureshk> thomas thinks that dna is an extension for nd
[14:16:28] <sureshk> so he thinks ip over foo may override these constants
[14:17:43] <sureshk> he wants these to be defined on a per link basis
[14:19:52] <sureshk> thomas is worried about the complexity
[14:19:58] <sureshk> of the protocol
[14:21:25] <sureshk> he wants to include the list of routers that the host heard from when it sends an RS
[14:22:04] <sureshk> to make creating the complete prefix list easy
[14:22:16] <sureshk> jin thinks completera can do this efficiently
[14:22:52] <sureshk> erik thinks in an upgraded router scenario
[14:23:06] <sureshk> the only reason the host does not get a completeRA is that
[14:23:18] <sureshk> the prefixes do not fit into a completeRA
[14:25:33] <jariarkko> Agree with Thomas' worry about complexity.
[14:25:54] <sureshk> sathya and jin arguing about completeRA vs complete prefix list
[14:25:59] <sureshk> which is more reliable
[14:26:38] <sureshk> thomas has been convinced (albeit partially) by Erik
[14:26:51] <sureshk> that the complexity may be necessary
[14:27:19] <sureshk> back to slide 8
[14:27:30] <sureshk> people are discussing the order of steps
[14:27:39] <sureshk> jin believes that the steps can be reordered
[14:28:15] <sureshk> sathya believes that the steps are in order of confidence
[14:28:39] <sureshk> he believes step 3 may be removed without much of a penalty
[14:29:56] <sureshk> jin was unconvinced
[14:30:19] <sureshk> but he looks convinced
[14:32:40] <sureshk> thomas is concerned about using learned prefixes for determining the smallest prefix
[14:33:16] --- psavola has left
[14:33:40] <sureshk> he thinks of a hostile router advertising prefixes
[14:34:28] <sureshk> he does not like the idea of a trusted router learning stuff from an untrusted router
[14:34:34] <sureshk> and passing it around
[14:34:53] <sureshk> erik thinks the host would get the polluted data anyway
[14:35:33] <sureshk> and he mentions that hosts do not autoconfigure addresses from these prefixes
[14:35:42] <sureshk> and the effects usually timeout
[14:35:49] <sureshk> 90 mins, i believe
[14:36:03] <sureshk> thomas needs more time to think about this
[14:36:12] <sureshk> sathya wants to update the SecCons
[14:36:18] <sureshk> since it has not been changed
[14:37:53] <sureshk> pekka wants routers to always advertise all the prefixes they have
[14:37:57] <sureshk> i.e. MUST
[14:38:09] <sureshk> thomas wants to keep it a SHOULD
[14:38:26] <sureshk> pekka thinks that would simplify the algorithm
[14:38:55] <sureshk> erik wants to know how dna can be done if the prefixes cannot fit into an RA
[14:39:16] <sureshk> pekka does not see this in real life
[14:39:23] <sureshk> only in attacks and in interop tests
[14:39:30] <sureshk> that the number of prefixes will be high
[14:40:41] <sureshk> erik does not believe that making this a MUST
[14:42:16] <sureshk> he thinks that routers MUST NOT do a dna ra
[14:42:37] <sureshk> if the prefixes do not fit into a single RA
[14:43:13] <sureshk> he has a stronger view now that the router MUST NOT do dna at all
[14:43:29] <sureshk> if the prefixes do not fit into an RA
[14:44:21] <sureshk> jin disagrees with erik
[14:45:15] <sureshk> he thinks in case of RS with landmark it is still useful to send dna RA
[14:47:03] <sureshk> pekka with his implementer hat on
[14:47:12] <sureshk> would not spread prefixes across multiple ras
[14:47:24] <sureshk> but he thinks some other implementations that may do so
[14:47:51] <sureshk> erik thinks that some networks like 6lowpan where it does not make sense
[14:48:08] <sureshk> since the power consumption is proportional to the number of bits received
[14:48:28] <sureshk> but he thinks there might be some issues related to link layer fragmentation which may make this useful
[14:52:05] --- tsavo_work@jabber.org/Meebo has left: Logged out
[14:52:16] <sureshk> end of meeting
[14:52:20] --- narten has left
[14:52:25] --- sureshk has left
[15:24:10] --- jariarkko has left