[09:36:00] --- Ian has joined
[09:36:09] --- Ian has left
[10:56:58] --- Justin Dean has joined
[11:31:07] --- jlcjohn has joined
[11:44:39] --- badamson has joined
[11:55:23] --- Yangwoo Ko has joined
[12:00:29] --- Seung has joined
[12:01:17] --- Yangwoo Ko has left: Lost connection
[12:01:31] --- Seung has left: Logged out
[12:03:20] --- behcet.sarikaya has joined
[12:03:46] --- ks has joined
[12:04:18] --- monden has joined
[12:04:25] --- ThomasHC has joined
[12:04:44] * Justin Dean has changed the subject to: start of meeting
[12:05:10] --- Yangwoo Ko has joined
[12:05:19] <Justin Dean> https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=67
[12:05:34] <Justin Dean> is the location of agenda and presentations
[12:05:58] * Justin Dean has changed the subject to: agenda bashing
[12:06:14] --- dowstreet@jabber.postel.org has joined
[12:07:02] --- Ian has joined
[12:07:08] <Justin Dean> Thomas Clausen has a smaller presentaion than is on the agenda
[12:07:40] --- Seung Yi has joined
[12:07:45] <Justin Dean> Joe some of these documents may be ready to move forward so would like to have an open discussion on these documents (packetbb)
[12:08:07] <Justin Dean> Perkins would also like to present on path accumulation durring his DYMO presentation
[12:08:19] <Justin Dean> Joe thats fine
[12:09:43] * Justin Dean has changed the subject to: MANET wg progress presentation
[12:10:19] <Justin Dean> IPR reminder RFC 3979 https://datatracker.ietf.org/public/ipr_disclosure.cgi
[12:10:20] --- jasso1 has joined
[12:11:02] <Justin Dean> wg documents: packetbb NHDP SMF DYMO and OLSRv2 are all progressing
[12:12:06] <Justin Dean> DSR in final stage of RFC editor queue
[12:13:13] <Justin Dean> InterWG items autoconf arch and problem definition, MANET router prefix assignment, MANET-OSPF design team perspective.
[12:13:47] --- memo57 has joined
[12:15:04] <Justin Dean> Authors should look at requirements for proposed standard track documents
[12:15:56] <Justin Dean> Clausen for packetbb we need to think about security, what needs to be in there. What are the expectations from the other branches in regards to security.
[12:16:44] <Justin Dean> Fenner: the draft-fenner-zinin-rtg-standard document is the wrong document to look at
[12:17:22] <Justin Dean> Fenner: The isg doesn't need implementations for standards track documents
[12:17:27] <Justin Dean> Joe: good to know
[12:18:08] <Justin Dean> Joe: Security may be borrowed from other documents rfcs
[12:18:39] <Justin Dean> Joe: please review documents and send comments to authors
[12:18:55] <Justin Dean> Clausen: can we add send comments to the mailing list and the authors
[12:19:54] <Justin Dean> Joe: NHDP and packetbb need to be mature so documents using them can also progress so please focus on packetbb and NHDP for review
[12:20:05] --- ShoichiSakane has joined
[12:20:41] --- igarashi has joined
[12:21:02] * Justin Dean has changed the subject to: OLSR Interop Workshop 2006
[12:21:40] --- yowada has joined
[12:21:54] <Justin Dean> Clausen: One day of workshop and 2.5 days of interop
[12:22:08] --- yowada has left: Logged out
[12:22:23] <Justin Dean> Clausen 6 OLSRv1 which interoped without major issues
[12:23:13] <Justin Dean> Clausen: 4 OLSRv2 implementations based on slightly different ietf documents, but some interoping did occur.
[12:23:21] * Justin Dean has changed the subject to: packetbb
[12:23:43] <Justin Dean> Clausen: removed fragmentation from packetbb since last ietf
[12:24:38] <Justin Dean> Clausen: Address- Block-Semantics field needs some rearanging
[12:25:00] <Justin Dean> Clausen: move text to IANA to discuss private/std usage allocation
[12:25:53] <Justin Dean> Macker: Would like to talk about the security section regarding encryption keys comment
[12:26:41] <Justin Dean> Clausen: we actually state that we do not say how do security but we do mention what would be allowed
[12:26:54] <Justin Dean> Clausen: question is do we need that at all?
[12:27:35] <Justin Dean> Macker: its nebulous and I am not sure its needed in its current form
[12:27:57] <Justin Dean> Macker: I don't know about the immutability of fields either.
[12:28:19] <Justin Dean> Clausen: I somewhat agree
[12:28:48] <Justin Dean> Macker: Its not wrong but its also not clear what the meaning of that section is currently
[12:29:13] <Justin Dean> Clausen: open for debate and change
[12:30:07] <Justin Dean> Perkins: Packet size matters. Would like to encourage people to look at packet size of packetbb and how it may be improved.
[12:31:23] <Justin Dean> Perkins: would like packetbb to be more efficent and more complex parsing
[12:32:09] <Justin Dean> Clausen: I disagree and think that ease of parsing is important for implementations and flexability
[12:32:40] <Justin Dean> Perkins: I don't know that we need to go as small as possible but it should be looked at.
[12:33:32] <Justin Dean> Macker: your point charlie is that would like to look at effecently/packet size and the tradeoffs between flexability
[12:34:27] <Ian> Justin please announce - People should make suggestions to improve PacketBB. If you have optimizations that decrease packet size, please propose them on the list.
[12:34:30] <Justin Dean> clausen: the tradeoff since paris has been to make some options tlvs and others optional fields
[12:35:06] <Justin Dean> people should make suggestions to improve packetbb. If you have optimizations that decrease packet size, please propose them to the list.
[12:35:34] <Ian> Justin - I meant on the mike :)
[12:35:51] <Justin Dean> Sar: mabye have a differnt packetbb for sensor networks
[12:36:49] <Justin Dean> Bormann: 6lowpan needs to do some work even if packetbb is close work will still need to be done because of differnet size addresses etc.
[12:38:27] <Justin Dean> Clausen: a mechinism to present a packetbb type of message as the same would be one approach even if 6lowpan packetbb is differnet the information conatined would be similar even if formats are slightly differnet
[12:39:47] <Justin Dean> Kim:related to 6lowpan...submitted draft of low power dymo using packetbb..so reducing overhead is important
[12:40:50] <Justin Dean> Macker: our group is not chartered to fix the 6lowpan problem specficly so that may be a 6lowpan issue
[12:41:06] <Justin Dean> Macker: not saying we don't want to help but its not he main goal of packetbb
[12:41:32] <Justin Dean> Clausen: do these address lend themselves to address agregation?
[12:43:15] <Justin Dean> Clausen: packetbb was designed to be generic to be the most usable for as many protocols as possible.
[12:44:01] <Justin Dean> Clausen: Where do we draw the line wr2 to how general vs. efficient PacketBB is?
[12:44:31] <Justin Dean> Kim: Thinks there is potential for some commonality between 6lowpan & MANET
[12:45:50] <Justin Dean> Perkins: Should not provide service to other working groups ... feels that PacketBB is contrary to a large potential used of MANET (sensor nets, etc), and it is crucial for this WG to get it right ... for MANET to be most useful.
[12:46:05] --- yowada has joined
[12:46:21] <Justin Dean> Macker: Minimizing number packets vs. packets of minimal size better for some MAC layers.
[12:46:41] <Justin Dean> Perkins: Stated that something like PacketBB should be/probably can be accomplished and would be useful.
[12:47:13] <Justin Dean> Dean: Any suggestions to improve efficiency of PacketBB would be useful to group. Such suggestions / input is strongly encouraged
[12:47:40] <Justin Dean> Dean: In some cases PacketBB is more efficient than some original OLSRv1 messaging.
[12:48:12] <Justin Dean> Clausen: Agreed that PacketBB was actually more efficient in some cases wr2 OLSR
[12:49:04] <Justin Dean> Macker: I think we all agree that this is still a solid document and we really need to move forward with this document
[12:50:18] <Justin Dean> Clausen: I don't want to spend lots of time for small effecincies as other MANET documents are based on packetbb and need packetbb to be "fixed" so other protocols can move forward
[12:51:04] * Justin Dean has changed the subject to: NHDP
[12:51:16] <Justin Dean> awating packetbb finalization
[12:52:09] <Justin Dean> Clausen: review with smf functionality as we have done work with OLSRv2
[12:52:47] <Justin Dean> Macker: terminology bi-directional is a better term than symetric link
[12:53:17] <Justin Dean> Macker: SMF needs solidifid tlvs for CDS algorthms
[12:53:56] <Justin Dean> Clausen: would like to explore the idea of a document of tlvs which we have found to be useful
[12:54:33] <Justin Dean> Perkins: Has some questions about the mandated behavor of NHDP. Does it need to send out messages on timers?
[12:55:06] <Justin Dean> Clausen: we are going to take that out as it came from OLSRv2 and the behavor came from olsr spec we are planning on making it work reactivly as well
[12:55:51] <Justin Dean> Adamson: The messages allow for reactive messaging but there may be some left over text which we hasn't been removed yet
[12:56:58] <Justin Dean> Dean: need to make sure protocols using NHDP do not cause bad behaviors when working in the same network
[12:57:11] * Justin Dean has changed the subject to: OLSRv2
[12:57:31] <Justin Dean> Clausen: awiting packetbb and nhdp finalization
[12:57:44] <Justin Dean> Clausen: remove lingering text
[12:57:48] --- jasso1 has left
[12:58:54] <Justin Dean> Clausen: making changes to multi-address nodes to allow for the efficent correct behavoir of routing with multiple interfaces
[12:59:22] <Justin Dean> Macker: how do you feel about the multiple interface spec and how much implemtation experience do you have with it.
[12:59:58] <Justin Dean> Clausen: we had 3 implemtations which supported multiple interfaces and one which didn't but we didn't do any exaustive testing
[13:00:17] <Justin Dean> Clausen: we have done tests with 12 nodes with about half having multiple interfaces
[13:00:30] <Justin Dean> Clausen: seems to work
[13:01:52] <Justin Dean> Adamson: related to NHDP different interfaces may have different requirements for messaging on different timers. This work still needs to take place in NHDP.
[13:02:21] <Justin Dean> Clausen: please review packetbb and NHDP and give feedback.
[13:03:04] * Justin Dean has changed the subject to: smf
[13:03:29] <Justin Dean> Macker: ver. 3 has been posted
[13:03:37] <Justin Dean> draft-ietf-manet-smf-03.txt
[13:03:57] <Justin Dean> Macker: needs text changes
[13:05:45] <Justin Dean> Macker: changes: uses NHDP, gateway issues considertations, applicability section, model of attached non-smf nodes discussed, some cds tlvs were removed
[13:06:15] <Justin Dean> Macker: people are working on integrating pim with smf and they have taken different approaches
[13:07:01] <Justin Dean> Macker: removed tlvs will live in some other documents; currently its in OLSRv2
[13:07:09] <Justin Dean> Clause: yes that is correct
[13:07:54] <Justin Dean> Macker: smf supporst different CDS algorithms and there is an ongoing issue on where these TLVs are going to live
[13:08:18] <Justin Dean> Macker: SMF is targeting experimental
[13:09:00] <Justin Dean> Macker: seems to work and would like to move it forward but biggest issue is making clear tlv definitions
[13:09:51] <Justin Dean> Macker: issues with multiple gateway still exist.
[13:10:44] <Justin Dean> Macker: there are two implemtations of SMF
[13:12:38] <Justin Dean> Macker: NRL using nrlolsr for neighborhood discovery and boeing using MANET-OSPF for dicovery.
[13:12:56] <Justin Dean> Clausen: a third at inria using OLSRv2 for discovery.
[13:13:03] * Justin Dean has changed the subject to: DYMO
[13:14:03] <Justin Dean> Fix Clausen 3rd implemtation of smf is not inrias code
[13:15:02] <Justin Dean> Clausen: changes: packetbb naming and tlv's, packet diagram nits, removed some items that had little interest , administrative model for future MIB document, checking routing inromation freshness...
[13:15:46] <Justin Dean> Clause: there was a discussion regarding packetbb and bits which described forwarding/processing behaviors of the messages
[13:16:55] <Justin Dean> Perkins: is the price of extensibility to expensive in terms of extra bits?
[13:18:12] <Justin Dean> Perkins: Fressness discussion; stale, loop-prone, inferior, superior information categories are described
[13:19:25] <Justin Dean> Perkins: if anyone has better naming please comment
[13:21:06] <Justin Dean> Perkins: timeouts are used with clear state changes alternative is to use a single timeout when removing old information and discussion would be welcome
[13:21:55] <Justin Dean> Dean: how many implemtations of DYMO are there?
[13:22:27] <Justin Dean> Perkins: fewer than a dozen but not sure of the number
[13:22:40] * Justin Dean has changed the subject to: path accumulation in dymo
[13:23:11] <Justin Dean> Followup: There are at least 2 full implemtations of DYMO
[13:24:14] <Justin Dean> Perkins: should be able to equip rreq and rrep with more topology to convey more information thoughout the network
[13:24:35] <Justin Dean> Perkins: longer routes allow acquisition of more data
[13:25:41] <Justin Dean> Perkins: has a path accumulation extensions. results are not yet clear
[13:26:11] <Justin Dean> Perkins: when network has a high PDR then path accumulation will not help.
[13:26:23] <Justin Dean> Perkins: under congestion Path accumulation can help
[13:28:13] <Justin Dean> Perkins: discussing study results
[13:29:34] <Justin Dean> Perkins: results show that with static networks path accumulation allows for faster dicovery with fewer route req
[13:30:18] <Justin Dean> Perkins: another benefit allows intermediate nodes rrep to provide shorter routes
[13:31:06] <Justin Dean> Perkins: Reduces number of rreq but also increases the packet size
[13:31:31] <Justin Dean> Perkins: benefit is mitigated if routes are no used before being purged from the routing cache
[13:32:39] * Justin Dean has changed the subject to: reliable flooding
[13:33:19] <Justin Dean> Perkins: SMURF algorithm request retransmission when failure noticed
[13:34:05] <Justin Dean> :Perkins: No explicit NACK, Checksums periodically advertise to dicover failures
[13:34:26] <Justin Dean> Perkins: further investigation on rough idea last year yielded ambiguous results
[13:36:37] <Justin Dean> Clausen: regarding the testing you did recently did you use the checksums?
[13:36:41] <Justin Dean> Perkins: yes
[13:36:59] <Justin Dean> Perkins: using this term reliable broadcasting but its not 100%
[13:37:24] <Justin Dean> Clausen: understand. When we did testing using checksum for detecting duplicates we detected alot of false positives
[13:38:02] <Justin Dean> Clausen: I was wondering if you were seeing results which reflected this or have algorithmes which mitigate this factor
[13:38:32] <Justin Dean> Perkins: we have not run suffenctly relistic scenerios to answer that question.
[13:39:21] <Justin Dean> Macker: I would like to comment that in some cases minimal cds algorithms outperform reliable transimisons
[13:39:23] --- memo57 has left
[13:40:07] <Justin Dean> Macker: There are methods which use methods which can "repair" missed messages
[13:41:01] <Justin Dean> Adamson: using network coding techines which use FEC coding techiquies to combine multiple message together to allow local netowrk repair for packet which may have been missed.
[13:41:40] <Justin Dean> Perkins: Need to identify percise failure mechanisms
[13:41:55] --- juampe has joined
[13:42:09] <Justin Dean> Perkins: likely culprit increased neighbor congestion
[13:43:10] <Justin Dean> Macker: if its a hop by hop method maybe its applicable to MANET but if its an end to end method it might be better to have it in another wg
[13:44:24] <Justin Dean> Adamson: our current ip stack model doesn't capture all of that space that we are trying to engineer against unless there is a revolution in the ip stack I am not sure we can do a whole lot there
[13:45:15] * Justin Dean has changed the subject to: MANET IANA Needs
[13:46:01] <Justin Dean> MANET UDP port ? having one udp port for manet routing?
[13:46:49] <Justin Dean> link local multicast: LL MANET routers: 224.0.0.TBD FF02::TBD
[13:47:11] <Justin Dean> Macker: scoped multicast addresses MANET routers...
[13:48:02] <Justin Dean> Macker: hopefully we can just use one multicast address but maybe get 2 or 3 addresss
[13:48:44] <Justin Dean> Macker: relevent RFCs rfc 3171, rfc 307
[13:49:36] <Justin Dean> Maker: proposel for site-local scoped multicast addresses MANET routers IPv4 MANET Routers 239.255.255.TBD
[13:49:50] <Justin Dean> ipv6 MANET Routers ff05::TBD
[13:50:14] <Justin Dean> Perkins: site-local is heavly deprecated...
[13:50:31] <Justin Dean> Macker: Multicast site-local is still around unicast is deprecated
[13:50:48] <Justin Dean> Macker: people still may debate if that is a useful thing but its still around
[13:51:17] <Justin Dean> Perkins: what happens if you have a link-local packet with a ttl greater than 1
[13:51:32] <Justin Dean> Macker: they are not forwared
[13:51:53] <Justin Dean> Perkins: what happens on the processing if you say get a ttl=10 packet
[13:52:31] <Justin Dean> Fenner: if it comes in on your interface you would process it. its not well defined but the host portion doesn't care what the ttl is
[13:52:50] <Justin Dean> Fenner: the routing poriton only cares if it decided it needs to foward it
[13:54:10] <Justin Dean> Macker: its not our intent to forward link-local scoped multicast packets
[13:54:27] <Justin Dean> Macker: if you wanted to send more than on hop site-local would be the way to go
[13:54:59] <Justin Dean> Macker: people are still confused about what we are trying to do and we should try to be as clear as possible on what the various defintions are
[13:55:25] <Justin Dean> draft-fenner-iana-exp-2780-05.txt
[13:55:34] <Justin Dean> In rfc editor queue
[13:55:45] <Justin Dean> ipv4 224.0.1.20-global
[13:55:55] <Justin Dean> 224.0.0.tbd - link-local
[13:56:02] <Justin Dean> tbd - site-local
[13:56:20] <Justin Dean> ipv6 ff0x::114 all scopes
[13:56:36] <Justin Dean> Fenner the numbers are assigned but the document isn't out of the queue yet
[13:57:13] <Justin Dean> Fenner: you have to take into account the rules of using these numbers.
[13:58:21] * Justin Dean has changed the subject to: DYMO implementation
[13:58:42] <Justin Dean> </subject>
[13:59:57] <Justin Dean> Oh: compliant w/ DYMO-05, Linux implementation, used Netfilter hooks
[14:00:50] <Justin Dean> PacketBB - a little difficult to implement, processing overhead for various tlvs in one addr block
[14:02:11] <Justin Dean> How to make use of optional fields ... suggested #ifdef approach to save CPU ... planning to examine re-arranging addresses in address block ... not using optional fields saves CPU/memory ...
[14:03:08] <Justin Dean> If we re-order the addresses in the packet more gaines can be had
[14:03:23] <Justin Dean> Uset NHDP instead of hello messages
[14:03:38] <Justin Dean> Macker: did you create new tlvs?
[14:04:04] <Justin Dean> Oh: no we just used the ones currently defined
[14:04:43] * Justin Dean has changed the subject to: open discussion
[14:05:07] <Justin Dean> Macker: please review packetbb and NHDP
[14:05:30] --- behcet.sarikaya has left
[14:05:38] --- ShoichiSakane has left
[14:05:41] <Justin Dean> Macker: okay I we are finished...
[14:05:45] <Justin Dean> clapping...
[14:05:56] --- ks has left
[14:05:56] <Justin Dean> thanks everyone for comming
[14:06:12] --- igarashi has left
[14:06:29] --- dowstreet@jabber.postel.org has left: Logged out
[14:06:44] --- Seung Yi has left
[14:06:49] * Justin Dean has changed the subject to: meeting ended
[14:07:10] --- Ian has left: Logged out
[14:07:37] --- monden has left
[14:08:54] --- badamson has left
[14:08:54] --- yowada has left: Logged out
[14:13:15] --- Justin Dean has left
[14:16:12] --- ThomasHC has left: Logged out
[14:16:58] --- Yangwoo Ko has left: Computer went to sleep
[14:29:07] --- Yangwoo Ko has joined
[14:29:12] --- Yangwoo Ko has left
[15:33:24] --- juampe has left
[16:15:19] --- jlcjohn has left