IETF 93 MANET WG Meeting Notes Meeting : IETF 93 Thursday July 23, 2015 Time : 1520-1720 Afternoon Session II Chairs : Justin Dean Stan Ratliff Secretary : Ulrich Herberg Jabber : xmpp:manet@jabber.ietf.org Scribe : Brian Adamson Minutes : Brian Adamson, Charlie Perkins Meetecho : http://recordings.conf.meetecho.com/Playout/watch.jsp?recording=IETF93_MANET&chapter=chapter_1 URLs : http://www.ietf.org/html.charters/manet-charter.html http://tools.ietf.org/wg/manet/ Agenda Bash =========================================== Alvaro Retana - would like to strike the AODVv2 as it can be handled on the list. Rick Taylor - Why? Alvaro Retana - At the last meeting, we spoke about having the interim meetings and having the last in-meeting discussion be the last. Things on the list and the interim meetings have been working and don't need to do it for the list. Brian Adamson - a minimal status update would be useful Alvaro Retana - perhaps will be included in chair's WG Status/Overview? Morten Pederson - Frank Fitzek is not here so that brief will not be presented Rick Taylor - so we should perhaps retain the AODVv2 item? Room consensus - keep the AODVv2 agenda item WG Status =========================================== Stan - draft-ietf-manet-aodvv2-11 submitted yesterday, draft-ietf-manet-dlep-16 was LC'ed and is now back to WG, draft-ietf-manet-ibs document in some sort of purgatory, draft-ietf-manet-olsrv2-dat-metric cleared WGLC needs shepherd write-up, draft-ietf-manet-olsrv2-multipath about to be WGLC'ed, new WG document: draft-ietf-manet-rfc5444-usage. draft-ietf-manet-olsrv2-management-snapshot has been declared dead by AD. Alvaro (AD) - draft-ietf-manet-olsrv2-management-snapshot was developed for OPS AD. OPS AD wants a _general_ MANET management document, not just an OLSR-specific one. Stan Ratliff - draft-ietf-manet-tlv-naming renaming IANA registries, should be finalized soon DISCUSS on draft-ietf-manet-olsrv2-multitopology, lots of discussion between Alvaro and Chris. Henning Rogge - we _really_ need this to deal w/ heterogeneous links. Justin Dean - issue is the document as an Experimental does not address the experiment it addresses Ron in 't Velt - authors were asked for a companion document, etc. facetious; makes it harder to have an Experimental than standard track?! Alvaro Retana (AD) - really just need a revision from the authors, adding some more bullets to the section describing the experiments. Justin Dean - draft-ietf-manet-rfc6779-bis waiting on MIB doctor review draft-ietf-manet-rfc5444-usage - Henning Rogge =========================================== Henning Rogge: (see slides). New WG document, reflecting lessons learned from designing protocols for improving extensibility and enabling creation of generic RFC5444 parser Lotte Steenbrink - I asked for an API. When designing AODVv2 messages, we didn't know what we were allowed to assume and what to set. John Dowdell - I second that. IETF may not be the best place to design API. But we need some sort of behavior in the doc that says this is presented by the upstream protocol, and these things happen. There are parts of RFC5444 only used for parser and upstream protocol should keep away from. Henning Rogge - You can always add new TLVs, but there is only a fixed set of header options. I am not quite sure of status of packet level TLVs - is similar to link-local information. Rick Taylor - I have been looking at packet level TLVs. I am unclear where you cover the packet handling rules, how do they handle an interim hop may strip some information out. Henning Rogge - There are no intermediate stations for packet level information. Packets only traverse 1 hop; information for multi-hop destinations should be handled in messages. AODVv2 - Charlie Perkins =========================================== Perkins: Routing area review was positive, and RFC5444 compliance seems to be well addressed. [ex post facto clarification: The review can be accessed at: http://www.ietf.org/mail-archive/web/manet/current/msg18005.html The review was sent to the authors on 06/22/2015 and forwarded by the authors to the MANET mailing list on 08/11/2015] Multicast RREP (route reply) - to alleviate bi-directionality concerns. Rick Taylor - good review by Chris Dearlove posted today ... will that be included? Charlie Perkins - making last call does not mean more comments won't arrive. Want to make document go to completion as quickly as possible. Has not fully read Chris' comments, but they will be taken into account. Stan Ratliff - short answer - yes, the comments will be considered. Some of the issues may have already been addressed. Comments are small enough that they shouldn't preclude last call. Justin Dean - who have read? (4 hands raised) ... we need more eyes on the document. The DLEP activity may have detracted from attention to AODVv2. Lou Berger - all identified issues should really be addressed before a last call Charlie Perkins - comments provided very recently Lou Berger - if document has not yet entered last call, outstanding comments should be addressed John Dowdell - I appreciate the review of Chris Dearlove. But when do we stop? Can we not take these comments as part of the WGLC? Stan Ratliff - _could_ go to last call with just these comments, but we need to take IETF experience into account and address Christopher's comments first. Then WGLC. Lotte Steenbrink - We made a deal in Dallas that some things should be addressed and then last call and those things were addressed. Stan Ratliff - I can't give you a guarantee. Justin, Alvaro and I need to sit together. We did have an agreement, and I also think the document has improved a lot and that we fulfilled our agreement. I understand that we could create a vicious, never ending circle could. That being said, we need to have consensus before moving forward. Justin Dean - I second what Stan said. We did have an agreement, and we're in a better state than a year ago and in Dallas. We are very close to a WGLC, but Chris' comments should be addressed. Teco Boot - Why not go ahead and address remaining issues in a second WGLC? What is the problem? Justin Dean - Would be OK to have last call after one more revision. If someone gets comments in before document is revised, those should be addressed, too. Ron in 't Velt - Chris' mentioned he didn't yet do a full review. There may be more coming. Justin Dean - In this case it's a race between who gets the comments in first and the review done first. Charlie Perkins - Chris' comments are largely editorial and can be addressed in a timely fashion. But we should make sure that we don't continue delaying the LC with more comments getting in. That would be bad. Stan Ratliff - What do you think Teco? Teco Boot - Can we set a date for incorporating the changes and then have a WGLC? Stan Ratliff - Fair to say that we can make the changes in two weeks time. DLEP - Rick Taylor =========================================== Rick Taylor - (see slides) Juliusz Chroboczek - question about TLS: is it MUST implement/SHOULD deploy, or SHOULD implement? Rick Taylor - have not finalized that Markus Stenberg - can say SHOULD have encryption, and if so MUST use a specific mechanism Rick Taylor - guidance is MUST be implemented, SHOULD be used John Dowdell - in many cases where this is used, DLEP is not exposed Lou Berger - here are some risks, in environments where this is a concern, this is what you MUST do Rick Taylor - we have given some wiggle room Lou Berger - in other contexts, the operator makes the choice Henning Rogge - using DLEP within in the same box so "TLS over loopback" doesn't make sense Rick Taylor - we need to get the wording right Lou Berger - almost every control protocol deals with this situation. Tech - need to think about it being securable Rick Taylor - feedback "was this is a complex problem, so describe better than use TLS" ... Tech - this is typically not _information_ that needs to be protected but more about it being validated (state of modem ...) so TLS may not be the answer? Lou Berger - going through the response to my comments, there may be a few areas that were not addressed but could be discussed. Can we have a time to discuss it this week or do it on the list? Stan Ratliff - would love to have discussion this week (not time in this meeting) so yes. Ultimately we would need to provide a synopsis to the list. Rick Taylor - ditto Lou Berger - ok need to document the resolution Rick Taylor - I know that not all comments were addressed. MANET Re-charter Discussion =========================================== Justin Dean - are there other items (that you want to work on)? Rick Taylor - interfacing applications with the underlying behavior of the MANET Justin Dean - are there other working groups? Rick Taylor - other groups have suggested working the issue in MANET Justin Dean - need to have some written rationale for this Henning Rogge - MANET configuration Charlie Perkins - intermediate route reply for AODV now that it's not part of the base spec. I think this is an important feature and should be included. Stan Ratliff - already implicitly covered Teco Boot - source dependent routing ... thinks this is very important. Justin Dean - also implicitly covered. Alvaro Retana (AD) - there are many things that fit under "maintenance" ... as much as we can, scope the working group. Henning Rogge - I have at least 3 extensions in working code that have been running for a year. Justin Dean - do we have willingness for these items: MANET Management - required. MANET Maintentance RFC5444 Security Extensions - (some hums) Enhanced AODVv2 gateway extension (some hums) MANET Multicast Multicast FIB - (consensus hums) James Nguyen - MIBs have been done for NHDP/OLSRv2. Why/what is the requirement for management? Justin Dean - Since OLSRv2 management snapshot was kicked back, it is back to your draft. James Nguyen - Are you looking for a framework or architecture? Justin Dean - That's a good question. James Nguyen - We can work on the draft again, but we need clearer direction on requirements to restart the work. Ron in 't Velt - There are only two bullets under "MANET Maintenance"? Justin Dean - The list represents the minimum/required, but additional drafts can be considered. Ron in 't Velt - Previously, there were proposals to work on metric. Would we have to delay working on these until the required items have been completed? Justin Dean - I wouldn't say has to be postponed. Current charter lists proactive routing protocol, reactive routing protocol and experimental multicast flooding. We put out nearly 20 RFCs to address those. We still don't have reactive protocol done, so it's not an inclusive list, but a required list. We have enough willing participants to work on these things. Brian Adamson - So if someone had a draft (e.g., on configuration), it could be brought to the WG, even if it is not on the required minimum list. Stan Ratliff - Absolutely. James Nguyen - Why is gateways for AODVv2 up there? Justin Dean - The way AODVv2 deals with gateways can be improved. It's done better in SMF and OLSRv2. That's way this is up here. Rick Taylor - Just confirming, potential DLEP extensions would always be welcomed by the WG.