[01:56:51] --- rune has become available
[01:57:32] --- iljitsch has become available
[01:59:26] --- torus has become available
[02:00:07] --- nm has become available
[02:00:29] --- WH has become available
[02:00:31] --- tskj has become available
[02:02:00] --- peetu has become available
[02:03:32] --- ggm has become available
[02:03:44] --- gih has left
[02:04:11] --- arifumi@jabber.org has become available
[02:04:12] <ggm> Marcelo on HBAs
[02:04:27] <ggm> include prefix info in addrs themselves. as hash.
[02:04:52] <ggm> how does this apply to multihoming?
[02:05:23] --- yushun has become available
[02:05:29] <ggm> send info, including set, prefix, hash to other end.
[02:05:56] <ggm> under failure, the host in multi-homed site can use alternate prefix and hostA can verify its securely bound, becuse its in the HBA. since it generated ULID
[02:06:00] --- brabson has become available
[02:06:02] <ggm> compatibility with CGAs
[02:06:35] <ggm> HBA's and CGAs both using iid bits. may need compatibility. SeND uses CGAs. so if you want to use SenDA and HBA, need it to be compat.
[02:07:02] <ggm> CGAs can support dynamic sets. if can use both together get optimizations of HBA, and dynamicicism from CGA. so define HBA as CGA extension
[02:07:07] <ggm> so get 3 addresses.
[02:07:19] <ggm> CGA only, CBA/HBA, and HBA only
[02:07:35] <iljitsch> 3 types of addresses, not 3 at the same time
[02:07:42] --- kurtis has become available
[02:08:01] <ggm> depending on which, may or may not get dynamic behaviour
[02:08:09] <ggm> slide of extension in standard ASCII art form
[02:10:27] --- shamus has become available
[02:10:50] --- nov has become available
[02:11:00] <iljitsch> my slides: http://www.xs4all.nl/~iljitsch/shim6-reach-detect-00.pdf
[02:11:06] --- andrewdmcgregor@jabber.psg.com has become available
[02:11:14] <iljitsch> (i'm up next)
[02:11:32] --- jeroen has become available
[02:11:36] --- rbless has become available
[02:11:37] --- faw has become available
[02:12:08] <rbless> dave thaler: what about using temporary adresses, e.g. privacy extensions RFC 3041
[02:12:10] <ggm> slide on production. changes to
[02:12:11] --- mo7sen has become available
[02:12:14] <ggm> <sorry. phonecall came in>
[02:12:38] <ggm> marcelo responding, limits of HBA change to set
[02:12:57] <ggm> Francis. IPR?
[02:13:01] <ggm> Geoff no known IPR issue
[02:13:02] <rbless> Francis Dupont: What is the IPR status of HBA?
[02:13:09] --- iljitsch has left
[02:13:20] <ggm> Iljitch next on 'triggers'
[02:13:30] <ggm> s/ch/sch/g
[02:13:31] --- FDupont has become available
[02:14:33] --- dthaler has become available
[02:14:35] --- dthaler has left: Disconnected
[02:14:41] --- dthaler has become available
[02:14:42] --- dthaler has left
[02:14:46] <ggm> Failure & Reachability detection.
[02:14:58] --- ltn22 has become available
[02:15:01] <ggm> main thing mh is about, detecting failures and route around.
[02:15:25] <ggm> management out of scope, much other stuff has to go on.
[02:15:38] <ggm> terminoloogy, an address pair is a Unidirectional path between 2 hosts
[02:15:38] --- nm has left: Disconnected
[02:15:43] <ggm> simple approach.
[02:15:54] <ggm> ping, or other src/dest test. pick best RTT
[02:16:04] <ggm> won't find unidirectional reachability. and doesn't scale
[02:16:20] <ggm> (some MH may be on pairs of unidirectional links)
[02:16:41] <ggm> cute cats-cradle animation of n**n combinatorial explosion.
[02:16:46] <ggm> complexity++
[02:17:03] <ggm> don't want to be more complex, but have to. need to find unidirectional connectivity.
[02:17:19] <ggm> can't just send answers using same addrs. has to implement some kind of semi-reliable comms.
[02:17:37] --- bonninjm@jabber.org has become available
[02:17:41] <ggm> lower O(2n**2) cost, but now may not find best link
[02:18:21] <ggm> this is hard work. looking at lightweight mechanisms (protocol)
[02:19:00] <ggm> on list talked about CUD and FBD. two ways to explore reachability with known locater sets.
[02:19:24] <ggm> CUD very like neighbour reachability. (NUD) need upper-layer protos to gauge progress.
[02:19:31] <ggm> if ULPs don't report progress, start heavyweight work
[02:19:39] <ggm> then if this fails, full on work
[02:19:54] <ggm> FBD, observations that most protos are bi-directional.
[02:20:18] <ggm> make rule: need bidi comms, then virtual 'keepalive' of start to go one-way do reachability
[02:20:48] <ggm> tradeoffs.
[02:21:16] <ggm> CUD needs positive upper layer feedback to be efficient. f-bidi needs no ULP, but can use neg ULP feedback. FBD only adds packes in the idle dir. (keepalives)
[02:22:59] <ggm> more tradeoffs.
[02:23:21] <ggm> CUD only detects failures in either dir. FBD only incoming. other end has to detect our failures.
[02:23:24] <ggm> Granularity.
[02:23:51] <ggm> simplest thing to say is, 'have 2 hosts, a, b, all comms choose locater pair, all comms over that pair, do less work, but have to funnel'
[02:24:04] <ggm> on the other hand, there is locater-to-locater. locater combinations. lots of states.
[02:24:15] <ggm> probably want to be in the middle. sweetspot may be ULID to ULID
[02:24:22] <ggm> Heuristics/Optimizations
[02:24:28] <ggm> (skipped, discuss)
[02:24:30] <ggm> NATS.
[02:24:46] <ggm> may have to deal with re-use of addrs.
[02:25:28] <ggm> want payload AND reachability to share fate. but unlikely (will not share same ports, will have differential ACL logic)
[02:26:06] <ggm> may have fate-share with negotiation proto. sit in same proto/portnums. one needs to be encaps in other. probably reachability encaps in other proto
[02:26:21] <ggm> Q: do we want to be sneaky and do firewall passthrough dispite admin?
[02:26:38] <ggm> Security.
[02:26:50] <ggm> attacks on packets and state. need nonce, auth data, lightweight!
[02:26:58] <ggm> auth happens lots.
[02:27:00] <ggm> avoid overhead
[02:27:06] <ggm> TODO
[02:27:15] <ggm> draft integration with Jari. -need text
[02:27:48] <ggm> Geoff: clarifying Qs please.
[02:28:36] <ggm> John need to clarify, not here (ML) how to go forward. arch Qs on how tightly to do failure/reachability, repeat info, handle in 'transport' or something lightweight. -maybe say 'look reachable' and transport has to verify.
[02:29:22] <ggm> Geoff: what you saw here is opportunistic answer. does need to be vertical signalling,. if Upper layers can give info, shim6 can use, do less. if its not available shim6 has to be able to do its own. exploit rich info if there. if not seen or not enough, use <mechanism> to do full tests
[02:29:40] <ggm> John. thinking differently. shim6 offer, 'we think work' but tx layer has additional info to know what to use. not force to shim
[02:29:53] <ggm> Geoff. clean arch answer. tx uses ULID not locaters, tx doesn't know mappings.
[02:30:17] <ggm> <unknown> Q can reach one address, other two on same i/f then can reach too?
[02:30:33] <ggm> Iljitsch huge number of heuristics,
[02:30:50] <ggm> lots of stuff to do there. doesn't have to be inproto, not e2e. can decide locally.
[02:31:02] <ggm> Q if you can assume. thats the q. a group can be reached if one can be reached.
[02:31:30] <ggm> Geoff this is site mh not host mh. number of site exit routers feeding equiv prefixes. host has no a0priori knowledge which is best. in shim6 conetxt, answer is no.
[02:31:40] <ggm> Q dealing with set of addrs. some may be site, some may be host
[02:31:56] <ggm> Geoff the room context is site. charter around site. can't apply additional host MH info. this is site MH
[02:32:04] <ggm> Q Hassan
[02:32:07] <ggm> Spencer
[02:32:41] <ggm> think its important about how often we see totally unidirectional. do on list, put about unidir apps. no feedback, would be helpful.
[02:32:49] <ggm> Ilj-tunnels good example
[02:33:02] <ggm> Jason. scope of failure detect. just addr a can't reach b, or degredation of service
[02:33:10] <ggm> eg 30% packetloss, is that failed or not?
[02:33:15] <ggm> Il: good Q, no answer here
[02:33:46] <ggm> TonyH similar thoughts. assume all links equal in RTT thing. short t1, long OC48, depends on app which I prefer. pipe capacity can be issue.
[02:34:02] <ggm> need to add to list. detecting inequal link capacity. app may need. hard to do from edge.
[02:34:20] <ggm> Il: have opportunity to use different ULID, harder to do in router.
[02:34:32] <ggm> TH need this on list of things to think about. may overlook and pick wrong at site border.
[02:34:35] <ggm> Geoff thks
[02:34:48] <ggm> Chairs will do report on Jableys applicability. have read(!) its short. placeholders right now.
[02:34:57] <ggm> document will not bepushed forward until we get proto elems in place.
[02:35:10] <ggm> AO general wg comments, before move to additional items
[02:35:46] <ggm> 5 major areas of direction. arch doc takes time, seeking assistance as other items become more mature. chair is conflicted, want help
[02:35:56] <ggm> next major bit is Eriks work on proto. (lead author)
[02:36:04] <ggm> crypto locater, marcelo and Jari lead
[02:36:08] <ggm> triggers with iljitsch
[02:36:13] <ggm> applicability with Jabley.
[02:36:58] <ggm> talked about more generic issue, given choice with multiple locaters, are you at IP level, where its unreliable datagrams, all path same, or when given choice do some locater pairs infer diffeernt path characteristics, do you want to make choice richer can do more with more choice. large bit of design work, underpin particularly triggers.
[02:37:15] <ggm> again, have some time, talk general approach, anything else to say? now is the time.
[02:37:43] <ggm> Kurtis: administrivia. have thoughts, ideas, moving forward, PLEASE go to ML. or give text. please don't write new drafts
[02:37:53] <ggm> Christian H. previous discussion re-inforced point from tuesday.
[02:38:04] <ggm> heard Q what happens if link has 20% loss, is broken or not?
[02:38:34] <ggm> decision made by tx proto in TCP/SCTP, or by app in UDP. so I really think we have to do analysis of the trade-off there. want to push into IP layer, or want expose info decision to
[02:38:53] <ggm> tx proto to do their job. if I have one direction, can we break down solution into smaller components, to expose info to tx proto, Upper layers?
[02:39:08] <ggm> Kurtis. different types of app may handle differently. multidimensional matrix
[02:39:31] <ggm> Christian. one app, 25% loss is fine (maybe online game) others not at all with 1%. more push down layer, more its one size fits all.
[02:40:08] <ggm> Geoff. Hear what saying. Iljitsch saying unidir info push. you're asking rather than simply 'im ok, I'm not ok' but more rich, 'this is char of locater pairs, what do you wsant to do'
[02:40:21] --- bonninjm@jabber.org has left: Logged out
[02:40:42] <ggm> Chrisitian do away with translation layer, show locaters to tx layers. interaction between tx and Ip. interaction will be 'tell me locaters to use, what are chars, what can I do?' different interaction to single ID, let ip layer make decision
[02:40:56] <ggm> Iljisch (sorry about spellling!)
[02:41:30] <ggm> to answer Q. get basics going for shim6, should explore, not other way round, wont get off ground if scope keeps changing. but need to explore savings by lifting wall between shim and transports. but not now.
[02:42:06] <ggm> Hassan. to add to Christian. not just tx. need for set of params, policies, for apps and users. some static, some dynamic. enable IP layer to execute choices
[02:42:19] <ggm> Christian. not what I said.
[02:43:10] <ggm> have two ways of taking problem. one way is rich api betweeen upper layers and IP, upper layer can push rich policy and IP makes deciison. other is IP is simple, provide info, let upper layers can choose which they use. thats not the same thing
[02:43:29] <ggm> Hassan. what you've clarified is pushing up or down. what I am saying is in addition to that choice, there are other dimensions, multiple factors
[02:43:32] <ggm> Christian, yes, that is true
[02:43:41] <ggm> Pekka Nickander.
[02:44:38] <ggm> first, think, personally, Q well founded. but also think most of that is impl issue. most of that doesn't change proto space. have to keep in mind, encourage to run code, see options, do experiments, do simulations. do need to keep in mind. may be issues affecting proto designers.
[02:45:00] <ggm> second point, where do we want to have the base state. locaters, belong together. from arch pov, I believe IP layer is right place. the host in this caseis MH. would be better
[02:45:37] <ggm> when dealing with site Mh to do in router, but its in host. tx layer state is even worse arch. this is valid discussion. need to focus on what doing, see if there are proto level IP layer consideratoons. not many, some. running code.
[02:45:44] <ggm> Spencer.
[02:46:01] <ggm> had this addressing workshop
[02:46:29] <ggm> sounded ugly then, not better now. all proto layers trying to solve same problem simultaneously. layer interactions.what if they disagree? one switches before other. need focus
[02:46:52] <ggm> JOhn Loughney. sympathetic to what christian raised. related to what i said earlier. think that agree with pekka. need running code.
[02:47:37] <ggm> wondering, have people talking policy, how to decide which pair is correct. falls down to what addr select mech, locater select mech is. might be useful to work through the locater select process and addr select process, not policies but guidelines may achieve things.
[02:47:51] <ggm> Geoff. 2 presentations, in last few minutes.
[02:47:59] --- becarpenter has become available
[02:48:01] <ggm> Marcelo on shim6/multi6 interaction.
[02:48:50] <ggm> exploratory work
[02:48:59] <ggm> layering issues.
[02:49:11] <ggm> multiple home addrs. many i/f, many mh hosts.
[02:49:43] <ggm> app scenario, mobile node, multiple home nets, roaming, home nets MH. has 3 COAs and 3 HOAs.
[02:49:51] --- bonninjm@jabber.org has become available
[02:50:34] <ggm> force comms through home link. establish shim layer session. ULid will be the addrs corresponding to the home agent.
[02:50:36] <becarpenter> so, to be blunt, that previous discussion was a rerun of things we talked about *before* focussing on the shim6 architecture. IMHO that architecture navigates between those issues because, in the end, it doesn't change the semantics of an address as viewed by the ULP, and doesn't modify the semantics of an address as viewed by routing, because it recognizes that those two views are different.
[02:50:48] <ggm> shim context will have ULids & locater set for home.
[02:51:00] <ggm> considering corresponding node will see this
[02:51:31] --- mlb has become available
[02:52:21] <ggm> iff failure, in access link with home address prefix association. comms will stop. home addr unreachable. option is shim to detect, traffic not flowing, above the mobile-IP to use different locater, alternate home addr as locater. the ULid has alt locater, different path. use as another Care-Of address. strange, shim based route optimization. now directly to CoA.
[02:52:25] <ggm> (thats BT mode)
[02:52:42] <ggm> if useing RO mode. will be two types of traffic, both home and 'optimal'
[02:53:26] --- mstjohns has become available
[02:54:05] <ggm> even in RO mode, shim will detect failiures, result is same.
[02:54:14] <ggm> Questions., reasona ble to expose care-of adds to shim?
[02:54:20] <ggm> careof more temporary
[02:54:26] <ggm> maybe need to let shim know.
[02:54:35] <ggm> how to use shim between home agent, mobile node.
[02:54:43] <ggm> exploit faildet, path explore.
[02:54:46] <ggm> mobile IP over shim
[02:54:54] <ggm> Geoff: spencer has Q. then other presentation
[02:55:11] <ggm> Spenser. comment. all layers going into this for themsleves. hoped was bounded set, now realize its not (laughter)
[02:55:52] <ggm> Hassan. comment on Q. makes sense to expose 2 sets of classes to shim. similar to whats done in API. dunno if WG cares, mobile6 destroys benefits of MH if it binds to Careof and it fails. looks no path.
[02:56:03] --- mstjohns has left
[02:56:20] <ggm> Marcelo work on how integrates, not breaking anything, if get benefits, then great
[02:56:39] <ggm> John Loughney, what do we envision in arch, relationship, mobile and shim, which on top
[02:56:46] <ggm> Geoff charter is 'don't break' thats as far as it goes.
[02:56:57] <ggm> John so interesting to talk which way it isup
[02:57:05] <ggm> Geoff: AD we don't know. leave alone. rathole
[02:57:32] <ggm> You Tae-Wan. ETRI. l3shim state mgt using vertial layered comms
[02:57:53] --- WH has left: Disconnected
[02:57:55] --- nm has become available
[02:58:13] <ggm> Geoff looking for work to present in Vancouver on API work, hands in air..[collects names]
[02:58:17] <ggm> Tae-Wan
[02:58:45] <kurtis> names where for API where "Pekka Nikander, Iljitsch, John and Christian"
[02:59:15] <ggm> MH layer needs to inform ULPs about slow start needs, switching to new address on hi-bw app
[03:00:26] --- iljitsch has become available
[03:00:36] <ggm> looking at several events in comms life which are vertical layer communications. bootstrap, connect, shim context estab, etc
[03:01:11] <ggm> diagram showing IP-L3shim-TCP/UL interactions.
[03:02:03] <ggm> more complex diagram showing state transitions start-idle-active-valid-probe-change
[03:02:24] --- mlb has left
[03:02:57] --- gih has become available
[03:03:04] --- nov has left
[03:04:20] <ggm> complex discussion of state transitions. I think you have to read the slides folks, I can't summarize this. he is discussing minutia of the state transition and communication modalities in vertical layering comms.
[03:05:01] <ggm> next steps.
[03:05:20] <ggm> split 2 parts. l3shim state mgt. detail this, make pseudo code to help impl.
[03:05:41] <ggm> other is vertical layer signalling. needed, signalling API not clear yet. if shim6 grp have consensus, maybe modify
[03:06:25] <ggm> Geoff now over time. how this area of activity, looking at API issues, like to ask pekka and christian and john to have look at, see how feeds into API. will take to ML. thankyou
[03:06:26] <ggm> <end?
[03:06:29] <ggm> end!>
[03:06:36] --- bonninjm@jabber.org has left: Logged out
[03:06:38] --- torus has left
[03:06:42] <iljitsch> ggm: I think Hassan is actually Hesham Soliman
[03:07:01] --- kurtis has left
[03:07:05] --- shamus has left
[03:07:09] --- brabson has left
[03:07:09] <ggm> sorry. my bad. and Ilitch/iljitsch confusion also apologies
[03:07:23] --- andrewdmcgregor@jabber.psg.com has left: Logged out
[03:07:27] --- gih has left
[03:07:31] --- rune has left
[03:07:39] --- peetu has left
[03:07:40] --- tskj has left
[03:07:53] --- faw has left
[03:08:03] --- nm has left
[03:11:04] --- becarpenter has left: Replaced by new connection
[03:11:04] --- becarpenter has become available
[03:11:04] --- becarpenter has left
[03:12:33] --- jeroen has left: Replaced by new connection
[03:15:31] --- iljitsch has left
[03:19:52] --- nov has become available
[03:22:58] --- ggm has left
[03:23:58] --- yushun has left
[03:24:30] --- FDupont has left: Disconnected
[03:27:56] --- mo7sen has left: Disconnected
[03:28:34] --- arifumi@jabber.org has left: Disconnected
[03:34:14] --- ltn22 has left
[03:47:24] --- yushun has become available
[03:48:44] --- rbless has left
[03:56:15] --- nov has left: Replaced by new connection
[03:59:43] --- gih has become available
[04:13:26] --- yushun has left
[04:15:38] --- ltn22@jabber.org has become available
[04:15:50] --- ltn22@jabber.org has left
[05:06:20] --- gih has left
[05:26:50] --- gih has become available
[05:31:01] --- gih has left
[07:06:30] --- gih has become available
[07:11:21] --- gih has left
[07:17:50] --- gih has become available
[07:53:07] --- gih has left: Replaced by new connection
[09:20:07] --- takamiya has become available
[09:21:20] --- takamiya has left