IETF-98 babel Swissotel, Chicago, Illinois. Tuesday, 28 March 2017. 13:00 - 14:30 Zurich A Room Chairs: Russ White (LinkedIn) Donald Eastlake (Huawei) Minutes: Barbara Stark, Gabriel Kerneis, David Schinazi Jabber: Alia Atlas 5 min. Administrativia (scribes), Agenda Bashing, Chairs 5 min. Status, Review of Milestones, Chairs https://www.ietf.org/proceedings/98/slides/slides-98-babel-agenda-and-status-03.pdf 25 min. Juliusz Chroboczek (U. of Paris-Diderot) draft-ietf-babel-rfc6126bis-01 Juliusz presented slides: https://www.ietf.org/proceedings/98/slides/slides-98-babel-about-some-babel-drafts-00.pdf Slide 7 Discussion... David Schinazi: Asked about possibilities. Will try to see what he can implement. Denies being a security expert. Juliusz: Expressed reasons why possibilities probably wouldn't work. Alia Atlas: Sometimes the implementation only has to appear externally to have implemented an algorithm. Slide 9 Discussion... Margaret Cullen: Suggested simply serializing the sending of Hellos over unicast. Send Hello unicast to all neighbors at same intervals as currently done with multicast. Juliusz: Perfectly correct. But is this ambitious enough? Is there case where you want to send Hello to one neighbor and not the other? Margaret: I know what we did works. Donald Sharp: [missed that question] Juliusz: refrain from implementing things that the users don't ask for. Dave Taht (channeled from jabber): Margaret: what if you have a mix of mcast and unicast capable recievers? How do you signal other nodes that you are unicast capable? Margaret: probably either/or. Cannot find a use case where some neighbours are unicast and other multicast. Toke Høiland-Jørgensen (channeled from jabber): wifi bridged over ethernet Dave Taht (channeled from jabber): plunk a new generation of babeld in an existing network. David Schinazi: Juliusz: I would say unicast hellos have no seqno. I would have a minimalistic unicast hello (unless there is a requirement to do differently). David Schinazi: That works. Another thing... Receiving a unicast from someone I would treat that as a Hello. Russ White: expressing concerns with what David said David: I do like the idea of a unicast hello. slide 13 discussion... Margaret: At first, the mandatory bit sounded right to me. But if you don't know the AE, won't know how to use this in forwaringd traffic. So I changed my opinion from yesterday that it's ok. Juliusz: the main issue is that [???] David: My implementation doesn't support IPv4. What are we going to do with all these fancy IPv4 examples? Margaret: And it would be bad if packets are not understood. David S: I agree. Dave Taht (channeled from jabber): AE is good. I do kind of think we end up with more than one new AE. Do we end up with a mirror image of the existing 4 AEs? Do we only end up with one AE? Toke (channeled from jabber): Bird will also drop the entire TLV if it doesn't understand the AE. Dave Taht (channeled from jabber): AE for... sake of argument - MPLS? What other AEs are possibly needed? Slide 17... Russ White (as chair): Experience isn't needed in an applicability statement. That would be better documented in a subsequent "Experience with..." document. Donald Eastlake (as chair): tended to agree with what Russ said. 15 min. Multicast Babel Extension, Zheng Zhang draft-zheng-pim-babel-ext-01 Sandy (Zheng) Zhang presented slides: https://www.ietf.org/proceedings/98/slides/slides-98-babel-multicast-babel-extensions-00.pdf Juliusz: I read both versions of this draft. Babel does not have concept of sub-sub TLV. It doesn't exist. Need to find different encoding. We are in the process now of figuring out how to encode this sort of info in Babel. We think this can be done with a different AE number. You are saying: "I am encoding it as a prefix, but this prefix is weird". Babel is designed to be implemented in [???]. It doesn't have TLVs inside TLVs inside TLVs all the way down. It's not recursive; we don't have sub-sub-TLVs. Perhaps we *do* need them, if we find a good reason. But we should not introduce a third level unless we find a good reason to need them. Sandy: maybe 2 levels is enough. Juliusz: I would say that what we want is a new AE number. Sandy: you mean we need a new AE for BIER; good. David S: I don't know much about BIER but what is the status of implementation? Sandy: If we agree to changes then we will implement. David: I think you need to write the code first, and then you see if your draft makes sense. If you want to move forward with this document in this WG, we would like you to implement it as a first step. Sandy: I have discussed with many experts about this… David: nothing is better than running code. Alia Atlas: We do encourage writing code and in this working group there is agreement to do that. There are open source implementations out there that you can play with and test out your proposal. In this working group there is a desire to have implementation first because it's straightforward. Donald Eastlake: agreed Alia: I think BIER is a good idea. It is a shift of paradigm, from longest prefix match to "bitmap" [???]. There is desire in homenet to use a lot of multicast. Read up on BIER. If done right, it does have potential. Dave That would like Babel to be forward-parsable 10 min. Babel Information Model, Barbara Stark draft-stark-babel-information-model-01 Barbara Stark presented slides: https://www.ietf.org/proceedings/98/slides/slides-98-babel-babel-information-model-00.pdf Juliusz: 3 students this summer working on viz for the babel daemon. Willing to get suggestions about what to display and how. Barbara: XML format, would that be okay? Juliusz: JSON please? Barbara: I could do JSON yes. Alia: Donald Eastlake: Next version will be submitted as WG draft. Adjourn