[05:02:55] --- iljitsch has become available
[08:29:18] --- kazuya has become available
[08:29:19] --- iljitsch has left: Lost connection
[08:45:08] --- iljitsch has become available
[08:47:16] --- bew has become available
[08:52:17] --- mike has become available
[08:55:49] <iljitsch> hey guys, is there any audio this morning?
[08:57:39] --- trond has become available
[08:59:31] <iljitsch> ah yes this is better (though it could stand to be a bit louder)
[08:59:55] --- shep has become available
[08:59:55] --- jolo has become available
[08:59:57] --- hp has become available
[09:00:07] --- nm has become available
[09:00:39] --- arifumi has become available
[09:01:09] --- RalphDroms has become available
[09:01:14] <jolo> CHAIRS: Brian Carpenter <brc@zurich.ibm.com> Kurtis Lindqvist <kurtis@kurtis.pp.se> AGENDA: 1. Administrivia, Chairs (5 mins) - Agenda - Scribes 1. Introduction, Charis (5 mins) 2. shim6 solutions architecture overview, Geoff Huston draft-huston-l3shim-arch-00.txt (15 mins) 3. review proposed charter, Chairs (25 mins) 3.1 General goals and scope 3.2 Specific deliverables and milestones 4. AOB, chairs (10 mins) - Next steps DESCRIPTION: The multi6 WG was tasked with investigating solutions to the site multihoming problem that will allow the global routing system to scale. The outcome of the multi6 WG is a specific network layer shim architecture for addressing and address handling of sites and nodes. This includes switching to different locator addresses when connectivity changes, but without the changes of address being visible to upper layers, which see a fixed Upper Layer Identifier address (ULID). The proposed shim6 WG is to complete this work with the required protocol developments and complete the architecture and security analysis of the required protocols. Interim mailing list for pre-discussion: shim6@psg.com Join by sending "subscribe shim6" to majordomo@psg.com
[09:01:24] --- bless has become available
[09:01:25] --- sureshk has become available
[09:01:34] <jolo> Overview - discussion with the ADs decided that this should be done in the Internet area.
[09:01:40] --- bless has left
[09:01:43] <jolo> Two choices, move multi6 or start a new one.
[09:02:19] <jolo> Multi6 ended with 3 open drafts and they are input to shim6. This bof needs to decide what to do.
[09:02:51] <jolo> Brian has been fired as chair as Multi6. He has other pots on the stove.
[09:03:00] <jolo> Geoff is up
[09:03:39] --- sleinen has become available
[09:03:53] <jolo> ID / LOC split basic approach
[09:04:28] <jolo> Slide shows a pictoral representation of the approach.
[09:04:34] <iljitsch> Are geoff's slides available?
[09:04:42] <jolo> SHIM6 is a clasic id/locator split
[09:05:18] <jolo> The upper layer talks to a name which may be different than what gets out on the routing system.
[09:05:47] --- prkj has become available
[09:06:22] <jolo> The "who" who you are talking to may be different where you are in the stack.
[09:06:36] <jolo> Many places do to this, OSI session layer, transport layer, IP layer.
[09:07:13] <jolo> The Multi6 design team deliberately put it below IP, below IP endpoint sublayer (AH / ESP / frag/reassembly / destination options).
[09:07:24] <jolo> This layer has no session knowledge
[09:07:29] --- yushun has become available
[09:08:14] <jolo> What is a UID? Upper layer IDentity, based upon a selection of address.
[09:08:31] <jolo> You have as many prefixes as you have upstream providers.
[09:09:30] <jolo> Probably the address you will use, the address should be usable.
[09:09:50] <jolo> It is not an unstructured address space.
[09:11:00] <jolo> Eric - says that there are trade-offs with this.
[09:11:33] <jolo> Some solutions might have better reachability; others might have better load spreading, etc.
[09:12:25] --- falk has become available
[09:12:31] --- bew has left: Replaced by new connection
[09:12:32] --- bew has become available
[09:12:32] --- bew has left
[09:12:45] <jolo> The id is semi-permanent
[09:12:47] <falk> Q: is shim6 strictly a superset of HIP?
[09:13:37] --- admcd has become available
[09:13:52] <jolo> I asked it.
[09:14:06] <jolo> HIP uses ephemeral keys to create locators.
[09:14:29] <jolo> shim6 uses prefixes based upon upstream prefixes.
[09:14:36] <falk> John: thanks. I should have said I meant my question fo the jabber list
[09:14:51] <jolo> OK, I did start a discussion anyhow :)
[09:15:09] <falk> indeed
[09:15:29] <jolo> Pekka Nikander said that there is on-going work in HIP. I missed the draft name, though.
[09:15:38] <jolo> Turning on SHIP6 .
[09:16:00] <jolo> - the initial SHIM6 state for a UID pair is the null map
[09:16:11] --- bew has become available
[09:16:13] <jolo> - subsequent negotation to determine shim6 capability
[09:16:17] <admcd> I think the draft pekka mentioned was: draft-henderson-hip-generalize-00.txt
[09:16:31] <jolo> Maintaining state.
[09:16:40] <jolo> - location failure triggers needs more work.
[09:16:48] --- gorryf has become available
[09:17:02] <jolo> - maybe keepalives within the stack, not on the wire.
[09:17:25] <jolo> Rehoming may involve exhaustive pare exploration - more work needed.
[09:17:39] <jolo> Signal upper level protocol of path state change - more work needed
[09:19:57] <jolo> Removing state
[09:20:05] <jolo> No explicit upper level protocol trigger
[09:20:08] --- Bob has become available
[09:20:22] <jolo> - use state timeout to remove stale shim mapping
[09:20:38] <jolo> The are aof vertical signalin g in the host protcol stack requires further consideration
[09:20:49] <jolo> Open issues:
[09:21:25] <jolo> - integration on HBAs & CGAs, in particular dynamic vs. static locator set management
[09:21:58] <jolo> - shim6 capability negoatiation and locator set exchange
[09:22:15] <jolo> - explicit packet signals for triggering shim mapping on the incoming packets
[09:22:27] <jolo> - interaction with site exit routers
[09:22:30] <jolo> - ULID selection
[09:22:34] <jolo> - DNS interaction
[09:22:44] <jolo> - adds and wdls from locator pool
[09:22:53] <jolo> - per-transport locator failure triggers.
[09:23:10] <jolo> an aside - integration of HBA with overall architecture needs more work.
[09:23:45] <jolo> No definative text on how to tell an incoming shim packet ves a non-shim packet
[09:27:30] <sureshk> john wants to work more on source address selection
[09:27:46] <falk> are these slides online?
[09:27:50] <sureshk> geoff has not given it much thought yet
[09:28:25] --- narten has become available
[09:28:31] <jolo> Michael Tuexen asked a question about API
[09:28:52] <jolo> Geoff mentioned this is a programming issue, and further study is needed.
[09:29:03] <jolo> Michael asked about SCTP interactions
[09:29:30] <jolo> Geoff - for shim6, its just packets, but may require more work on SCTP.
[09:29:53] <jolo> Andrew - how do we see the process of provitioning address space to the user
[09:30:25] <jolo> ans: it is undefined how you take multiple prefixes from different external sources and distributed.
[09:30:37] <jolo> It is for future consideration
[09:31:00] <jolo> Victoria - 6 on the name implies IPv6, does it imply just IPv6?
[09:31:12] <jolo> ans: this bof is chartered just for IPv6.
[09:31:33] <jolo> This group will look into IPv6 use.
[09:31:54] <jolo> Victoria: host will negotiate if they use ids; will it be an option not to use an ID if it has it?
[09:32:49] <jolo> ans:communication between shim6 & non-shim6 will work; there must be some negotiation between these hosts.
[09:33:19] <jolo> Eric - question on per-transport vs per-ulid pair SHIM state.
[09:34:15] --- bew has left: Replaced by new connection
[09:34:15] --- bew has become available
[09:34:15] --- bew has left
[09:34:15] <jolo> ans: IESG had comment about the pre-transport locator failure triggers. It came from Allison. Timing associated between what is a failure may vary based upon transport used. This should be considered.
[09:34:31] --- bew has become available
[09:34:40] <jolo> Eric - says that if we focus on the most demanding transport, everything is OK.
[09:35:15] <jolo> Pekka Savola - DCCP can support different transport profile ... it might make sense to discuss DNS assumptions, including reverse DNS.
[09:35:52] --- allison has become available
[09:36:12] <jolo> Brian - on the last bullet. He had a discussion with Randy Steward (of SCTP-fame). The interaction of shim6 and congestion control needs more thought.
[09:36:54] <jolo> SCTP experience mentioned that interaction is more subtle than what is currently document.
[09:37:13] --- tomh has become available
[09:37:34] <jolo> Aaron Falk - I haven't read the draft, but ... (he explains his understanding) ... in the context of being multihoming, what happens when the DNS address becomes unavailable?
[09:38:08] <jolo> ans: mention that this is a possibility, but moves on. The topic of unreachability needs more work.
[09:38:21] <iljitsch> null mapping for "erik"
[09:38:22] --- allison has left: Logged out
[09:38:44] <jolo> Erik - the documentation assumes all address are in the DNS
[09:38:57] --- becarpenter has become available
[09:38:59] <jolo> Erik - some work is needed there.
[09:39:15] <jolo> Aaron - how much does this change existing apps?
[09:40:02] <jolo> erik - some apps already do this, its depending upon APIs. If your application doesn't do the DNS, then this can be hidden from the apps. The open issue is how speed this up.
[09:40:09] <jolo> Allison walked in!
[09:40:36] <jolo> about the review of the multi6 architecture document.
[09:41:02] <jolo> Are there other dimentions to the sensitivity to multiple transports?
[09:41:49] <jolo> Allison - some SCTP services are partially reliable (for some length of time, for example) which the application layer is sensitive.
[09:42:11] <jolo> Allison: That's a reliablity issue, not congestion control, sorry, its Friday
[09:42:26] --- lixia has become available
[09:42:58] <jolo> a: there are different congestion control mechanisms, each has different properties and different responses.
[09:44:13] <jolo> a: different bustyness, sending, etc. All of them have different dynamics, so that you can't simplify this to the lowest (or highest) common denominator.
[09:44:35] <jolo> Michael: different behavior per-packet in SCTP, which you can't see on the wire.
[09:45:19] <jolo> Michael: have some experience in SCTP, so you might want to review this. multiple locator support may be dependent on the transport layer.
[09:46:12] <jolo> allision - congestion control layer may need to be bound to the path. If the locator and the path are tied, then congestion is tied to the locator.
[09:46:52] <jolo> Erik: there is work needed to be done on how to run SCTP on top of shim6, for example.
[09:47:27] <iljitsch> can someone interject this into the discussion: I've heard a lot of "this needs more work". In the past, IPv6 stuff that looked good on paper didn't do so well in practice. shouldn't we do some experimenting in a number of these "needs work" areas?
[09:47:56] <jolo> Agenda interupt: charter discussion
[09:48:31] <jolo> Review of the charter
[09:48:59] --- Bill has become available
[09:49:26] <Bill> geez, I forgot my binoculars
[09:50:23] --- ks has become available
[09:51:48] --- jolo has left: Replaced by new connection
[09:51:48] --- jolo has become available
[09:51:48] --- jolo has left
[09:53:56] --- mjo has become available
[09:54:20] --- yushun has left
[09:56:50] --- tomh has left: Replaced by new connection.
[09:57:03] <iljitsch> ping
[09:57:08] <sleinen> pong
[09:57:13] <sureshk> john is out of jabber
[09:57:21] --- Margaret has become available
[09:57:30] --- admcd has left
[09:57:31] --- brett_pentland has become available
[09:57:38] <sureshk> michael: wants to make sure that dccp and sctp are not broken by shim6
[09:57:51] <iljitsch> yes, I heard, I thought the whole thing went south (happened many times this week)
[09:58:00] <becarpenter> debating charter wording re transport protocols
[09:58:06] <sureshk> kurt: thinks it may not be in the scope of the BOF/WG
[09:58:10] --- brett_pentland has left
[09:58:15] <becarpenter> "make sure you don't break any transports"
[09:58:32] <sureshk> kurt: does not intend to break ANY transport protocol
[09:58:43] --- tomh has become available
[09:58:56] <iljitsch> she still has to USE the mic, though...
[09:59:03] --- leymann has become available
[09:59:20] --- brett_pentland has become available
[09:59:24] <sureshk> Pekka N: thinks there are deeper issues involved in the id/loc split
[09:59:28] <becarpenter> even when saying she doesnt want to use it yet?
[09:59:47] <sureshk> explicitly exclude things like multipath congestion control
[09:59:49] --- brett_pentland has left
[10:00:15] <iljitsch> hm yes a conundrum...
[10:00:18] --- prkj has left
[10:00:29] --- jolo has become available
[10:00:36] <sureshk> kurt: multi6 goals RFC3582 explicitly requires not breaking anything
[10:00:44] <sureshk> do not need to be reminded by everyone
[10:01:09] <sureshk> Avri: wants to know why mobility is excluded?
[10:01:10] <sureshk> as they share common problems
[10:01:18] <jolo> john: suggest documenting address interaction of shim6 with congestion control. Split discussion of congestion control, qos and TE ans: OK michael: don't break sctp behavior. ans: we can't break any transport protocol. Pekka Nikander: as this is a id/loc problem, we should only look at not breaking things. studying interaction of congestion control and multihoming is a research topic, maybe we should handle it in a research group. Kurtis: Do no harm is part of the consideration Avi: exclusion of multihoming & mobility. there are relationships between these.
[10:01:36] --- brett has become available
[10:01:55] <jolo> Avi: thinks that this is important, but not taking into account mobility is a risk
[10:01:56] <sureshk> Avri: We are trying to do a major change here, without taking mobility into consideration
[10:02:07] <lixia> I fully agree with Avri
[10:02:21] <sureshk> John, TAG :-)
[10:02:25] <jolo> suresh, can you jabber and I'll document?
[10:02:33] <sureshk> OK
[10:02:36] <iljitsch> yuck, if the mobility people would have gotten it right first time around we wouldn't be here in the first place!!
[10:03:19] <sureshk> Kurt: Thinks the definition of site determines whether there are common issues between multihoming and mobility
[10:03:20] <jolo> well, you know that some people would like to solve mobility again, and trying to find a place to do it in ...
[10:03:38] <sureshk> Kurt: thinks any solution here will not break mobility
[10:03:59] <sureshk> Brian: thinks the soln. will NOT BREAK mip
[10:04:27] <sureshk> but agrees with Avri that we might have a missed opportunity here
[10:04:59] <iljitsch> Question: compatible == everything can run over it, or == it knows when to disengage?
[10:05:03] <becarpenter> of course, we haven't committed to not break NAT; only half :-)
[10:05:07] <sureshk> MW: Wants to state that there are no special efforts taken to enhance mobility, but they might be considered later
[10:05:16] <sureshk> Avri: disagrees
[10:05:32] <sureshk> with MW and it might be too late to do something LATER
[10:05:40] <sureshk> once shim6 is deployed
[10:05:50] <lixia> not so much of "missed opportunity", but to at least avoid creating more fractures
[10:05:55] <sureshk> thinks not enough study has been done about the commonalities
[10:06:27] <sureshk> Avri: thinks the wording for exclusion is too strng
[10:06:56] <sureshk> Erik: there are different areas between mh and mobility
[10:07:09] <sureshk> which might be common
[10:07:21] <sureshk> one thing is dynamic locator sets which are interesting
[10:07:38] <sureshk> someone must write drafts about interactions with sctp,mip etc
[10:07:51] --- brett has left
[10:08:28] <sureshk> Kurt: is not sure whether it is in scope of this WG or the OTHER WG (mip/sctp etc)
[10:08:47] <sureshk> Erik: Thinks clean separation of boundaries is good
[10:09:01] <sureshk> Pekka S: supports the mobility wording in the charter
[10:09:34] <sureshk> thinks restricting initial scope is good.
[10:09:47] <sureshk> doesn't want to be still doing a requirements document in 2 yrs
[10:10:04] <sureshk> MW: Thinks highly scoped WGs perform better
[10:10:36] <sureshk> wants to solve engineering problems first
[10:10:50] <sureshk> when the consumers are asking for it
[10:12:01] <sureshk> Pekka N: mobility means different things to different people
[10:12:33] <sureshk> (talking about HIP experience)
[10:13:02] <sureshk> dynamic set of locators come with a bunch of security issues to solve
[10:13:24] --- Margaret has left
[10:13:41] <sureshk> Kurt: wants Pekka N to send text
[10:13:59] <sureshk> Avri: multi6 spent a lot of years on analysis
[10:14:23] <sureshk> wants a team to explore mobility
[10:14:30] <sureshk> (she is willing to send text)
[10:14:43] <sureshk> wants an explicit milestone
[10:14:53] --- falk has left
[10:14:54] <sureshk> Kurt: needs more time to discuss
[10:15:01] --- falk has become available
[10:15:22] <sureshk> Pekka S: dynamic locators can mean different things depending on the rate of change
[10:15:30] <sureshk> maybe should define how dynamic
[10:15:57] <sureshk> Scott Bradner: is worried about leaving security until the end
[10:16:00] <sureshk> (few people clapping)
[10:16:51] <sureshk> Brian Carpenter: thinks it might be possible to use the ultimate shim6 solution as a mobility solution
[10:17:47] <sureshk> Kurt: does not want to step on the other WGs toes
[10:17:47] --- ks has left: Lost connection
[10:17:47] --- sleinen has left: Lost connection
[10:17:47] --- nm has left: Lost connection
[10:17:47] --- trond has left: Lost connection
[10:17:47] --- jolo has left: Lost connection
[10:17:47] --- bew has left: Lost connection
[10:17:47] --- hp has left: Lost connection
[10:17:47] --- gorryf has left: Lost connection
[10:17:47] --- arifumi has left: Lost connection
[10:17:47] --- Bob has left: Lost connection
[10:17:47] --- mike has left: Lost connection
[10:17:47] --- mjo has left: Lost connection
[10:17:47] --- becarpenter has left: Lost connection
[10:18:35] <sureshk> Thomas Narten: Wants to know who is responsible for interop and interaction with mip WGs
[10:18:52] <sureshk> thinks there is too much work to do here already
[10:19:12] <sureshk> wants to make sure there is adequate review before making irrevocable decisions
[10:19:25] <iljitsch> sureshk: you're not being very accurate here
[10:20:06] <sureshk> It is my perception of what Thomas said
[10:20:41] <iljitsch> no he said that it was A LOT already and moibility on top of it would be too much
[10:21:02] <sureshk> John: wants to go further down the solution path before considering other things
[10:21:05] <iljitsch> scott didn't say something about security itself, but compared "mobility at the end" with "security at the end"
[10:21:18] <sureshk> MW: agrees with John
[10:22:19] <sureshk> MW: is not sure how people from all areas are aware of what is going on here
[10:22:33] <sureshk> and thinks it is a common problem at the IETF
[10:22:58] --- avri has become available
[10:24:21] <avri> i just don't understand how we can change the center of the hourglass without taking eveything into account.
[10:28:48] --- iljitsch has left: Lost connection
[10:28:48] --- sureshk has left: Lost connection
[10:29:21] --- sureshk has become available
[10:29:21] --- ks has become available
[10:29:35] --- iljitsch has become available
[10:29:45] <sureshk> sorry, I got kicked out from the jabber room
[10:29:53] <iljitsch> agree, we sure don't want to solve the double jump problem in shim6.
[10:30:22] <iljitsch> (the jabber sucks this meeting)
[10:30:27] <ks> me
[10:30:58] <iljitsch> hummmm
[10:31:04] <sureshk> tim shepard: thinks there will be multiple alternatives in this solution space (like shim6, hip) etc
[10:31:15] <sureshk> and hopes that shim6 will be a strong contender
[10:31:33] <sureshk> voice at the back is suggesting Brian's question may not be fair
[10:31:55] <sureshk> Scott: thinks the questions were orthogonal
[10:32:17] --- nm has become available
[10:32:21] <sureshk> Brian: (rewording)
[10:32:35] <sureshk> Asks if it is a good idea to form a WG
[10:32:44] <sureshk> lot of hums for and none against
[10:33:13] <sureshk> MW: How many people on ML
[10:33:16] <sureshk> lot of hands
[10:33:26] <sureshk> MW: How many read the drafts
[10:33:33] --- falk has left
[10:33:34] <sureshk> lot of hands
[10:33:36] <iljitsch> i would (within limits)
[10:33:40] --- falk has become available
[10:33:45] <sureshk> How many have employer support
[10:33:53] <sureshk> A bit fewer hands
[10:34:00] --- narten has left
[10:34:04] <sureshk> MW: three part question
[10:34:12] <sureshk> 1) Is the BOF ready to become WG
[10:34:19] --- RalphDroms has left
[10:34:30] <avri> where is the mailing list? i missed that.
[10:34:31] <sureshk> Are we ready to make the decision?
[10:34:46] <sureshk> (lot of hands)
[10:34:54] <sureshk> No?
[10:34:54] <iljitsch> avri: see the bof schedule on the meeting page
[10:35:00] <sureshk> 2 hands
[10:35:06] <sureshk> How many people want a WG?
[10:35:09] <sureshk> lot of hands
[10:35:17] <sureshk> against?
[10:35:20] <sureshk> (no hands)
[10:35:23] <avri> thanks
[10:35:26] <sureshk> Kurt: BOF is over
[10:35:28] <iljitsch> would be helpful to summerize the result yes/no
[10:35:36] --- nm has left
[10:35:39] <iljitsch> for the audio
[10:35:40] --- jclee has become available
[10:35:42] <sureshk> Yes: people have enough info to decide
[10:35:47] --- leymann has left
[10:35:49] <sureshk> Yes: people want to form WG
[10:35:56] --- jclee has left
[10:36:03] <sureshk> I gotta go folks.
[10:36:26] <sureshk> Iljitsch: Sorry for misinterpreting a couple of things
[10:36:26] --- ks has left: Logged out
[10:36:26] --- sureshk has left
[10:36:34] <iljitsch> don't worry about it
[10:38:36] <iljitsch> if you want to add new locators along the way you need heavier security. for some things this is a deal breaker, for some things it's no problem at all (ie already running ssl or ipsec)
[10:40:05] --- kazuya has left
[10:41:06] --- trond has become available
[10:42:53] --- wej has become available
[10:45:20] --- Bill has left
[10:45:48] --- allison has become available
[10:46:20] --- Bill has become available
[10:46:30] --- jclee has become available
[10:47:33] --- jclee has left
[10:50:00] --- ks has become available
[10:51:38] --- shep has left
[10:52:21] --- lixia has left
[10:55:58] --- avri has left
[11:02:03] --- falk has left
[11:10:38] --- sakumajj has become available
[11:13:18] --- sakumajj has left
[11:19:58] --- ks has left: Logged out
[11:22:11] --- Bill has left
[11:24:23] --- allison has left: Logged out
[12:21:38] --- falk has become available
[12:27:22] --- falk has left
[12:27:59] --- wej has left: Logged out
[13:00:21] --- avri has become available
[13:00:50] --- trond has left: Lost connection
[13:14:58] --- avri has left
[13:44:04] --- becarpenter has become available
[13:44:49] --- becarpenter has left
[16:25:21] --- tomh has left: Lost connection
[16:35:48] --- iljitsch has left: Disconnected
[22:52:09] --- ks has become available
[22:54:05] --- ks has left