[13:56:56] --- kakima has joined
[13:57:01] --- kakima has left
[13:58:39] --- apetrescu has joined
[13:59:01] <apetrescu> Thomas Clausen presents
[13:59:13] <apetrescu> slide: Autoconf WG Session-ii 69th IETF, Chicago
[13:59:24] --- dthaler has joined
[13:59:42] <apetrescu> TC: minutes for _this_ meeting are at the end of the meeting minutes
[13:59:58] <apetrescu> Shrubranshu (?) is co-chair, presents.
[14:00:02] <apetrescu> slide: agenda
[14:01:44] --- TJ has joined
[14:02:30] <apetrescu> Ian Chakeres going to present
[14:03:17] <apetrescu> slide: MANET Architecture Status Update
[14:03:34] <apetrescu> slide:Changes Since IETF 66 MANETARCH-01=>04
[14:03:49] --- shubranshu has joined
[14:05:26] <apetrescu> slide: MANETARCH-05 Rwo Weeks
[14:06:28] --- kakima has joined
[14:07:37] <apetrescu> TC: questions? to this document in general?
[14:08:00] <apetrescu> TC: absent any major issue, we'll issue a LC soon after this metg, maybe LC in that 1-2 week timeframe.
[14:08:07] <apetrescu> TC: think about the security section in this document.
[14:08:18] --- kakima has left
[14:08:35] <apetrescu> TC: characteristics of an interface is this document, but might be worth elevate from existing documents, about the security section document.
[14:08:43] <apetrescu> TC: not expect to write a long thesis on this.
[14:08:52] <apetrescu> TC: because not everybody has same sec reqs.
[14:08:52] --- kakima has joined
[14:09:02] <apetrescu> TC: any comments on this outline of the process?
[14:09:14] <apetrescu> IC: if you haven't read the doc, please do so when next rev comes out.
[14:09:19] <apetrescu> TC: this is the last chance.
[14:09:22] <apetrescu> TC: thanks Ian.
[14:09:41] <apetrescu> TC: next presentation is problem statement, wg id updated.
[14:10:02] <apetrescu> TC: has been in the works for a while, made progerss, but solicits feedback on this, is this smth that can help us?
[14:10:26] <apetrescu> Emmanuel BAccelli (spelling?) presents
[14:10:34] <apetrescu> slide: Autoconf Problem Statement
[14:10:40] <apetrescu> slide: Update of the document
[14:11:25] <apetrescu> slide: Scenarios
[14:12:47] <apetrescu> TC: we need careful in this terminology, because we can have well a standalone manet, a manet node has a network attached to it. Standalone vs connected manet terminology should be careful about.
[14:12:58] <apetrescu> TC: in the arch doc most manet routers have a net attached to it.
[14:13:11] <apetrescu> TC: here we want to say something that has a topologically correct address.
[14:13:14] <apetrescu> Joe MAcker is JM
[14:13:34] <apetrescu> JM: are you discussin the case where the network might transit through this types of profiles, disconnected temporarily?
[14:13:38] <apetrescu> EB: yes
[14:13:46] <apetrescu> JM: not necessarily orthogonal to each other, right?
[14:13:49] <apetrescu> EB: yes,...
[14:13:56] <apetrescu> slide: Goals
[14:14:42] <apetrescu> slide: Motivation
[14:14:51] --- fp has joined
[14:15:49] <apetrescu> slide: Issues and Considerations
[14:17:05] <apetrescu> TC: not as tall but pretend I'm Charlie, but he'd ask this: manet border router we need to be more specific...
[14:17:35] <apetrescu> TC: one has to do with a manet node..., the other was about CP talked at some point: if you have two manet routers... different, different entities...
[14:17:51] <apetrescu> TC: needs to coordinate with each other. Thiank about that in the problem statement.
[14:17:58] <apetrescu> EB: it's mentioned there no?
[14:18:01] <apetrescu> TC: no
[14:18:06] <apetrescu> Teco Boot TC
[14:18:07] <apetrescu> TB
[14:18:20] <apetrescu> TB: topology-correct addresses are mentioned but not found in draft
[14:18:28] --- jpc has joined
[14:18:43] <apetrescu> EB: I've mentioned, but we have to be very careful not mixing with routing and auto-configuraiton, whatever has to do with autoconf is in this document, but .
[14:19:01] <apetrescu> TC:topologically-correct address means what? With respect to whom?
[14:19:14] <apetrescu> TC: to Joe or to a border router (corectness topologically is)
[14:19:22] <apetrescu> Fred Templi is FT,
[14:19:41] <apetrescu> FT: instead of 'topologically-correct prefix' maybe we want to talk about a prefix that is aggregated on a mobile router.
[14:20:14] <apetrescu> JM: rereading draft, confusing to me looks as solving standalone separately from connected to backhaul Internet link and manets and it would be good to add text that deployments may have both.
[14:20:26] <apetrescu> JM: in the introduction it presnets both but
[14:20:31] <apetrescu> JM: a couple of sentences
[14:20:49] <apetrescu> EB: yes, already talking dynamically topoology, transition one of these scenarios into another...
[14:20:54] <apetrescu> JM: needs to be clear
[14:20:58] <apetrescu> EB: we'll clarify this.
[14:21:02] <apetrescu> slide: Comments on -00
[14:21:20] --- jpc has left
[14:22:08] <apetrescu> EB: qs?
[14:22:26] <apetrescu> TC: there are people outside sitting, but there are places here at front, please migrate to room
[14:22:43] <apetrescu> TC: we'll have hopefully a rapid turnaround, WG please provide reviews in the weeks to come
[14:22:52] <apetrescu> TC: would be nice if we could converge to something before next iet.
[14:22:54] <apetrescu> ietf
[14:23:03] <apetrescu> TC: start next ietf make progress on other.
[14:23:09] <apetrescu> TC: try to accelerate the process.
[14:23:25] <apetrescu> TC: pleased to see there was interaction, but please accelerate tis process quite substantially
[14:23:41] <apetrescu> S; Fred, please come.
[14:23:47] <apetrescu> Fred Templin is FT going to present
[14:24:08] --- igarashi has joined
[14:24:59] <apetrescu> slide: MANET Autoconfiguration
[14:25:08] <apetrescu> slide: Goals
[14:25:28] <apetrescu> slide: Challenges
[14:25:49] <apetrescu> slide: Types of addresses/prefixes
[14:26:21] <apetrescu> slide: Challenges
[14:27:37] <apetrescu> slide: Two basic solutions
[14:28:10] <apetrescu> slide: Virtual Ethernet (VET)
[14:28:52] <apetrescu> slide: MANET with Virtual Ethernet (VET)
[14:29:13] <apetrescu> slide: MANET Router (MNR)
[14:30:21] <apetrescu> slide: MANET Autoconfiguration Procedure
[14:30:28] --- Thomas.Heide.Clausen has joined
[14:30:38] --- bkhabs@jabber.org has joined
[14:31:43] <apetrescu> slide: Autoconfiguration Procedure (2)
[14:32:02] --- keyajima has joined
[14:33:14] <apetrescu> slide: Operation with Multiple MNBRs
[14:34:14] <apetrescu> slide: MLA DAD Considerations
[14:34:32] <apetrescu> slide: Other DADConsiderations
[14:35:06] <apetrescu> slide: Drafts
[14:35:27] <apetrescu> slide:Co-Authors
[14:35:28] <apetrescu> slide: BAckups
[14:35:32] <apetrescu> Greg Daley is GD
[14:35:44] <apetrescu> GD: with respect to dhcp pd, was that for subnets or for loopback addresses?
[14:35:55] --- TJ has left
[14:35:57] <apetrescu> FT: if you get dhcp pd you can apply to any ingress interfaces
[14:36:07] <apetrescu> FT: vmware you can delegate downstream
[14:36:13] <apetrescu> GD: of course you'd need that for VET
[14:36:17] <apetrescu> FT: only for ...
[14:36:32] <apetrescu> Suresh Krishnan i sSK
[14:36:48] <apetrescu> SK: VET is a interface w/o unique id, how do you ?
[14:37:03] <apetrescu> SK: if as MANET interface then you need to make sure it's unique when iface goes up down
[14:37:09] <apetrescu> FT: we haven't talked IPv6
[14:37:14] <apetrescu> SK: it says /128
[14:37:17] <apetrescu> FT: true
[14:37:27] <apetrescu> FT: but underneath the VET interface
[14:37:32] <apetrescu> FT: derives from it.
[14:37:40] <apetrescu> FT: as long as MLAs are underneath
[14:37:54] <apetrescu> SK: but that needs to be specified, so that every time you come up with it you want it to have same thing.
[14:38:08] <apetrescu> SK: need like a consistent mechanisms, 100 manet interfaces, needs to be specified.
[14:38:21] <apetrescu> FT: if manet ifaces go up and down then your link-local ifaces go up and down
[14:38:28] <apetrescu> SK: kind of like a loopback to me.
[14:38:37] <apetrescu> SK: I want you to pick like a method to make
[14:38:52] <apetrescu> FT: different projects, , or consider configuring _and_ link-local addresses
[14:38:56] <apetrescu> SK: only one
[14:39:01] <apetrescu> FT: in the next revision on.
[14:39:06] <apetrescu> Charles PErkins is CP
[14:39:29] <apetrescu> CP: if you have lot of mobile routers in your, olsr or dymo routers, according to ..., consider it to be on the same all virtual media?
[14:39:37] <apetrescu> FT: olsr would run it on the same interface here
[14:39:45] <apetrescu> CP: same virutal ethernet interface?
[14:39:52] <apetrescu> CP: like bridging all together?
[14:39:57] <apetrescu> FT: each manet...
[14:40:11] <apetrescu> CP: lot of multiple over radio media, still being modelled as a single ethernet?
[14:40:13] <apetrescu> FT: yes
[14:40:36] <apetrescu> CP: what you try to do is define a manet a single virtual media, dhcp not quite well, but there should be some multi-hop underneath
[14:40:39] <apetrescu> FT: yes
[14:40:48] <apetrescu> FT: what's go unde r is dynamically changing all the time
[14:40:57] <apetrescu> CP: compatible with what's going on on manet wg?
[14:41:00] <apetrescu> FT: what?
[14:41:29] <apetrescu> CP: in a way, on manet agenda doesn't look as high up in the archi, it's basically concerned how to get packets from one manet router to another, no req to make these nodes look as they're bridged together.
[14:41:36] <apetrescu> FT:... bridged, manet.
[14:42:03] <apetrescu> CP: can I also two short summary: if you can make the the manet nodes look as a bridge then you can easily run dhcp, because we know how to over ethernet.
[14:42:07] <apetrescu> FT: as well as SLAAC
[14:42:21] <apetrescu> GD: do they (manet routers) appear as adjacent, to the .
[14:42:38] <apetrescu> GD: asking this because if we just do what virginia wants us today then how do we track smth
[14:42:52] <apetrescu> FT: within this room, manet beginnin s to look as a .
[14:43:12] <apetrescu> JM: what the manet interfaces are? relationship to manet routing might work?
[14:43:27] <apetrescu> JM: in some deployments the routers aren't all equalt, we may not want rou tun traffic.
[14:43:49] <apetrescu> JM: aggregating this heterogeneous stuff together, or a problem? cost-based routing? IP routing can do have heterogeneity well.
[14:43:58] <apetrescu> JM: if we collapse, manet in trerfaces under the hood.
[14:44:12] <apetrescu> JM: if you trust the multicast would get through one way or another, then you want to look the same.
[14:44:25] <apetrescu> FT: what goes one here is IP routing over heterogeneous, but here is homeogeneus.
[14:44:53] <apetrescu> JM: say I have a multicast packet lnk-local, needs to go all neighbours, but with manet looks as collapsed (layer 2), but what's the best up?
[14:45:07] <apetrescu> JM: is the VET interface an intelligent routing? Or just drops down
[14:45:13] <apetrescu> FT: just latter, looks like Ethernet
[14:45:17] <apetrescu> Gabriel Montenegro
[14:45:46] <apetrescu> GM: model looks like 6lowpan, like IP link, common mehcanisms with trill doing pretty much same thing, trill uses packet format encapsulation, not want to use their is-is maybe
[14:45:49] <apetrescu> FT: right...
[14:46:03] <apetrescu> GM: path encapsulaiton... synergy more and more as we go further into this archi
[14:46:13] <apetrescu> FT: to look at, not a requirement for IP-IP encapsulation
[14:46:24] <apetrescu> FT: we favor IP-IP, because manet low layer can harmonize...
[14:46:29] <apetrescu> FT: ;not a possibliity...
[14:46:36] <apetrescu> GM: debatable
[14:46:42] <apetrescu> GM: bridging is supported
[14:46:46] <apetrescu> GM: can you bridge similar media?
[14:46:51] <apetrescu> FT was that
[14:46:52] <apetrescu> GM: yes
[14:46:56] <apetrescu> GM: 802 media
[14:47:01] <apetrescu> FT: but fddi and ethernet?
[14:47:07] <apetrescu> FT: wouldn't work then
[14:47:17] <apetrescu> Dave Thaler is DT
[14:47:35] <apetrescu> DT: what encaps is at data plane? IP-IP ok. But straight IP-IP encap or map multicast over smth?
[14:47:46] <apetrescu> FT: honestly not thought multicast. subsequent draft.
[14:47:59] <apetrescu> DT: unicast is just straight IP dst address directly with IP and MLA dst address
[14:48:01] <apetrescu> FT: correct
[14:48:13] <apetrescu> GD: q is this only for IPv6 hosts eth? Or for all network hosts?
[14:48:32] <apetrescu> GD: if just IPv6 IP-IP is fine, but some additional encap may be necessary, IP and a certian piece of media.
[14:48:43] <apetrescu> FT: certainly in the upper layer we lean towards IPv6.
[14:48:53] <apetrescu> FT: goals of autoconf is config of v6 addresses.
[14:48:59] <apetrescu> FT: layer could be v4 and v6.
[14:49:05] <apetrescu> FT: maybe next version of draft.
[14:49:32] <apetrescu> TC: reiterate that this is individual submission and FT was responsive on the list, please discuss that on list.
[14:50:33] <apetrescu> TC: people in hallways standing, please here are two chairs available here.
[14:50:48] <apetrescu> Kenichi Mase going to present is KM
[14:50:59] <apetrescu> TC: requesting forwarding bulesheets
[14:51:13] <apetrescu> slide: A Common Framework for Autoconf of Stand-alne Ad hoc
[14:51:18] <apetrescu> slide: Aims
[14:52:13] <apetrescu> slide: Change from ver.02
[14:52:57] <apetrescu> slide: duplicate address detected
[14:53:42] <apetrescu> slide: Fig. 3 Phases model with in-service DAD.
[14:54:07] <apetrescu> slide: Fig. 4 Phases model with full DAD
[14:54:41] <apetrescu> slide: Duplicate address advertisement (DAA)
[14:55:17] <apetrescu> slide: The baselines fo the framework
[14:55:40] --- bkhabs@jabber.org has left
[14:55:48] <apetrescu> slide: Appendix
[14:56:11] <apetrescu> SK: what is the security model for daa? Easy attack vetor, just do DAA for any address advert? Thought?
[14:56:22] <apetrescu> KM: not thought sec issues now, just a possibl emethod
[14:56:34] <apetrescu> KM: in industry solutions we shoul dbe careful secutiry
[14:56:58] <apetrescu> DT: in this presentation you kep saying address, but manet arch doc says prefix, how to terminology? You meant prefix? Relationship is ?
[14:57:21] <apetrescu> DT: only works with address?
[14:57:24] <apetrescu> KM: manet local address
[14:57:33] <apetrescu> DT: I understand applies to manet intefrface
[14:58:04] <apetrescu> TC: clarifying we are interesting in getting prefixes to routers and routers can do whatever; these pref can be generated within the manet or obtained. Symbolic to addr assignment as such is happenning...
[14:58:12] <apetrescu> TC: get a prefix to a router, be that manet-generated or.
[14:58:22] <apetrescu> DT: chartered against the ablity to get some unique thing to.
[14:58:29] <apetrescu> DT: the nunique thing is to get a prefix
[14:58:42] <apetrescu> DT: in this propovbesal you get address is unique but prefix?
[14:58:47] <apetrescu> EB: just terminology is this
[14:58:51] <apetrescu> EB:another q
[14:59:09] <apetrescu> EB: in beginning os slide you said targetting only standalone manet, why does it apply to only this scenario?
[14:59:20] <apetrescu> EB: could apply to other scenarios too right?
[14:59:28] <apetrescu> KM: you mean to others?
[14:59:31] <apetrescu> EB: yes
[14:59:42] <apetrescu> KM: now not sure about the model when we couldnt scenario
[14:59:49] <apetrescu> KM: connected manet I'll go to.
[14:59:54] <apetrescu> KM: generalized is better.
[15:00:08] <apetrescu> CP: q on pre-service DAD was a MAY?
[15:00:27] <apetrescu> CP: not understand why is such a weak suggestion because I think it's important for devices in network to do this to ensure uniqueness.
[15:00:32] <apetrescu> CP: in-service there
[15:01:03] <apetrescu> CP: at some point you have to do something or try reall hard to get these addresses unique (we discussed this abou tnetwork partitioning sometim) to avoid duplicate address...
[15:01:07] <apetrescu> KM: you mean?
[15:01:11] <apetrescu> CP: that work MAY
[15:01:15] <apetrescu> KM: you suggest SHOULD?
[15:01:23] <apetrescu> CP: SHOULD is reasonable until (explains it)
[15:01:52] <apetrescu> KM: we may yes, but a little reluctant to use SHOULD or MUST because there are many apps and different situaitons and probability of duplication depends on ...
[15:02:09] <apetrescu> CP: should cover that case, because if you have some ensurance then you fulfill the escape clause to a sHOUDL
[15:02:21] <apetrescu> KM: reconsider will I, but current draft we consider possible models.
[15:02:50] <apetrescu> KM: what kind of DAD solution depends on overhead on solution, currently its's just a kind of solution, but I don't say here any model is better thna oteher.
[15:03:04] <apetrescu> TC: discuss modesl proposed, and not the MAY/SHOULD discussion
[15:03:15] <apetrescu> TC: editorial change individual ID, but on mailing list.
[15:03:19] <apetrescu> TC: here I'd like to.
[15:03:29] <apetrescu> TC: not cutting CP, but not discuss on may.should
[15:04:05] <apetrescu> CP: undre the impression, would led to a device get an address, amanet node olsr/dymo once getting an address, etherente, or something supplyu addresses for more traditional way.
[15:04:12] <apetrescu> CP: (can't hear_)
[15:04:33] <apetrescu> CP: need a way to dad an address, scotch around the terminology document, cant believe we cant get an address.
[15:04:37] <apetrescu> Chris Dearlove is CD
[15:04:56] <apetrescu> CD: you get an address, use it for yourself as an address
[15:04:59] <apetrescu> CP: but not a prefix
[15:05:02] <apetrescu> CD: a very long prefix
[15:05:13] <apetrescu> TC:other qs?
[15:05:20] <apetrescu> TC: see it discussed on mailing list I'd like
[15:05:26] <apetrescu> TC: modern framework presented
[15:05:57] <apetrescu> TC: next topic is owada(spelling?)
[15:06:12] <apetrescu> Yasunori Owada is YO is going to present
[15:06:47] <apetrescu> slide: Gateway Aggregation Protocol draft-mase-autoconf-gap-01
[15:07:10] <apetrescu> slide: Status
[15:07:44] <apetrescu> slide: Overview
[15:09:06] <apetrescu> slide: Scenario
[15:09:42] <apetrescu> slide: Basica GAP Operation
[15:11:57] <apetrescu> slide: Protocol interaction
[15:13:12] <dthaler> anyone follow why an anchor BR is needed?
[15:13:27] <apetrescu> slide: Next step
[15:13:59] <apetrescu> Anshul Kantalawa (spelling?)
[15:14:14] <apetrescu> AK: BRs would discover being connected to a manet rt protocols?
[15:14:25] <apetrescu> AK: BRs would know connected to internet?
[15:14:33] <apetrescu> AK: how to differentiate?
[15:15:08] <apetrescu> YO: tunnel does not create, then MN and change the MBR, it can communicate with CN but tunnel past, must be manet.
[15:15:19] <apetrescu> AK: where is the tunnel created: to manet or to fixed network?
[15:15:26] <apetrescu> YO: fixed network, not to manet
[15:15:35] <apetrescu> AK: if so, then why not all this create a tunnel.
[15:16:07] <apetrescu> AK: I don't see, would be hard, should be switch, maybe data network merging and partitionign frequently, data border router I need or not create a tunnel.
[15:16:24] <apetrescu> AK: unless automaticattllly created tunnels, regarldess network merging or not.
[15:16:48] <apetrescu> YO: the manet transation, in that case you mane one manet stop advertising, create tunnel.
[15:16:59] <apetrescu> AK: could be a case where you continuously create and remove tunnel.
[15:17:24] <apetrescu> YO: if this manet in separated then it does not that does not change, yes that's right, need to change the partition network
[15:17:28] <apetrescu> YO: ok
[15:17:55] <apetrescu> EB: thinks that what is meant here in the case of multihoming then you establish tunnels; if not multhiomed then just tear down tunnels. You talked flapping?
[15:17:58] <apetrescu> AK: yes
[15:18:01] <apetrescu> AK: ok
[15:18:19] <apetrescu> DT: clarifying, is the scenario where the MBGs are owned by same organizaiton (or two that trust each other)?
[15:18:31] <apetrescu> YO: I need to , something, it is required trust each other.
[15:18:42] <apetrescu> DT: ok, so these are all managed by same org.
[15:19:06] <apetrescu> DT: why the redline goes back to anchor router, and thus why MBG? Is that an important point?
[15:19:16] <apetrescu> YO: in this case the manet rt protocol uses the niece part
[15:19:30] <apetrescu> DT: why does it matter when teh tunnels are used in the outbound direction?
[15:19:33] <apetrescu> Thomas NArten is TN:
[15:19:37] <apetrescu> TN: optimization
[15:19:39] <apetrescu> DT: no no
[15:19:51] <apetrescu> GD: maybe because you may have something for prefix A goes that way
[15:20:00] <apetrescu> DT: I can understand, if ingress filteriing
[15:20:15] <apetrescu> GD: but why prefix B because you don't get either advantage (doesnt understand).
[15:20:39] <apetrescu> YO: is ok, but in this case the manet routing protocol possibly either route this protocl touches not anything in the routing mechanism
[15:20:44] <apetrescu> YO: in that case
[15:20:49] <dthaler> the red line in the diagrams just doesn't make any sense
[15:20:51] <apetrescu> S (c-o-chair_
[15:20:52] <dthaler> diagram
[15:20:59] <apetrescu> slide: Next Steps
[15:21:10] <apetrescu> TB: it';s default gateway in the picture, only one
[15:21:14] <apetrescu> EB: more graphs?
[15:21:21] <apetrescu> EB: default route the red line is?
[15:21:26] <apetrescu> TB: only one is default gw
[15:21:29] <apetrescu> YO: yes, default
[15:21:29] --- dthaler has left
[15:21:39] <apetrescu> EB: so the anchor is the only exit that is advertised
[15:21:45] <apetrescu> DT: I though hearing all are...
[15:21:47] <apetrescu> EB: no
[15:22:01] <apetrescu> DT: why the red line is not within the manet
[15:22:06] <apetrescu> TC: re-asking same q
[15:22:11] <apetrescu> TC: get through
[15:22:16] <apetrescu> TB: rt protocol is short, low metric
[15:22:42] <apetrescu> TC: if you don't sign bluesheets next time there won't be chairs in the room
[15:23:36] <apetrescu> Carlos Bernardos
[15:23:41] <apetrescu> going to presnet is CB
[15:23:52] <apetrescu> slide: Survey of IP ...
[15:23:55] <apetrescu> slide: Outline
[15:25:45] <apetrescu> slide: Introduction and motivation
[15:26:34] <apetrescu> slide: Classification Properties (I)
[15:26:52] <apetrescu> S: now the terminology doc is already a WG doc, better to be consistent about terminology, eg... gives example
[15:26:55] <apetrescu> CB: right
[15:27:25] <apetrescu> TC: also suggests that first work with ps authors determine terminology, 2nd point consider JM where you have transitory situations, standalone at some point and connected at other time
[15:27:34] <apetrescu> TC: analyze supporting this or not, need to think about it
[15:27:38] <apetrescu> CB: absolutely
[15:28:31] <apetrescu> slide: Classification Properties (II)
[15:28:52] <apetrescu> TC: comment again, please synch with ps document, eg DAD is a protocol existing elseqhere, is this a concept?
[15:29:07] <apetrescu> CB: when I say DAD I mean a mechanism to ensure uniqueness, not mention DAD protocol.
[15:29:40] --- keyajima has left
[15:29:41] <apetrescu> TC: general comment, please very careful when using the term 'DAD', all authors of documents think, in-service DAD, specific time for a protocol described somewhere else...
[15:29:47] <apetrescu> CB: think about it
[15:30:01] <apetrescu> JM: suggest to tense there? Keeps coming often, need to go away from that.
[15:30:08] <apetrescu> JM: terminology makers is there somewhere?
[15:30:14] <apetrescu> CD: prefix is not addresses?
[15:30:40] <apetrescu> TC: try to to fix that in next version of terminology, authors who promissed to give an update, have this terminology clarified, is this doable?
[15:31:04] <apetrescu> EB: in the bad autoconf ps document, not only a single mention of DAD? pre-service uniquencess, what JM suggested is on the draft already
[15:31:11] <apetrescu> TC: so the task is coordinate with ...
[15:32:24] --- narten has joined
[15:32:35] <apetrescu> slide: Classification Properties (III)
[15:34:04] <apetrescu> slide: Classification Properties (IV)
[15:35:08] <apetrescu> CD: you may all to get 2nd and 3rd case by using packetbb, but it would derive architecture, if not laugh, if not using packetbb, then you get lower overhead (not sure I got this ok)
[15:35:29] <apetrescu> slide: Solutions analysed (I)
[15:35:44] <apetrescu> slide: Classification results (I)
[15:36:44] <apetrescu> slide: Classification results (II)
[15:37:34] <apetrescu> (sorry, low battery I'm on, and now power socket around, I might drop notes soon)
[15:38:09] --- apetrescu has left
[15:42:57] --- fp has left
[15:43:15] --- owada has joined
[15:44:41] <shubranshu> Prefix distribution presentation
[15:45:13] <shubranshu> slide no. 2
[15:45:39] <shubranshu> slide 3
[15:46:34] <shubranshu> individual prefix distribution slide
[15:46:55] <shubranshu> case II (next slide)
[15:47:20] <shubranshu> slide: common prefix distribution
[15:47:45] <shubranshu> proposal classification slide
[15:48:12] --- owada has left
[15:49:38] <shubranshu> presentation ends
[15:50:38] <shubranshu> tc: next step
[15:51:04] <shubranshu> aim is to WGLC on Arch
[15:51:31] <shubranshu> wglc PS ID befor next IETF
[15:51:42] --- igarashi has left
[15:51:59] --- kakima has left
[15:52:45] <shubranshu> next ietf plans is to discuss solutions space
[15:54:00] <shubranshu> session ends
[15:54:04] --- shubranshu has left
[15:59:24] --- narten has left
[16:01:01] --- Thomas.Heide.Clausen has left
[16:24:22] --- hb47713 has joined
[16:25:00] --- hb47713 has left