6MAN Working Group - Virtual Vancouver IETF Meeting 14:30 - 16:30 (UTC), 31 March 2020, Tuesday Chairs: Bob Hinden, Ole Trøan Minute taker: Barbara Stark Jabber Scribe: TBD Jabber Room: 6man@jabber.ietf.org Webex: https://ietf.webex.com/ietf/j.php?MTID=m34712748394253ee72466def184033a6 ================================================================================ Agenda - 14:30 - 16:30 UTC, 31 March 2020, Tuesday Introduction, Agenda Bashing, Document Status, Chairs, 10 min. Working Group Drafts Gratuitous Neighbor Discovery: Creating Neighbor Cache Entries on First-Hop Routers, draft-ietf-6man-grand-00 , Jen Linkova, 15 min. Privacy Extensions for Stateless Address Autoconfiguration in IPv6, draft-ietf-6man-rfc4941bis , Chairs & Fernando Gont, 15 min. Operations, Administration, and Maintenance (OAM) in Segment Routing Networks with IPv6 Data plane (SRv6), draft-ietf-6man-spring-srv6-oam , Zafar Ali, 15 min. Active Individual Drafts IPv6 Application of the Alternate Marking Method, draft-fz-6man-ipv6-alt-mark , Giuseppe Fioccola, 15 min. Transmission of IPv6 Packets over Overlay Multilink Network (OMNI) Interfaces, draft-templin-6man-omni-interface , Fred L Templin, 20min. Improving the Robustness of Stateless Address Autoconfiguration (SLAAC) to Flash Renumbering Events, draft-gont-6man-slaac-renum Fernando Gont, 15 min. Problem Statement Regarding IP Address Usage, draft-gont-6man-address-usage-recommendations , Fernando Gont, 10 min. ************************************ Chair Intro https://datatracker.ietf.org/meeting/interim-2020-6man-01/materials/slides-interim-2020-6man-01-sessa-introduction-agenda-bashing-document-status No-one bashed the agenda. ************************************ Gratuitous Neighbor Discovery: Creating Neighbor Cache Entries on First-Hop Routers, draft-ietf-6man-grand-00 , Jen Linkova Jen Linkova presented slides: https://datatracker.ietf.org/meeting/interim-2020-6man-01/materials/slides-interim-2020-6man-01-sessa-gratuitous-neighbor-discovery-creating-neighbor-cache-entries-on-first-hop-routers There were no questions for Jen. Discussion between Ole and Jen around when to do WGLC vis-a-vis WGLC on the problem statement draft in v6ops. The problem statement draft is informative and this is normative. Warren Kumari: Fernando Gont: The problem statement draft is useful and it might be useful to WGLC together. Ole Trøan: Bob and I will take AI to coordinate with v6ops to do WGLC on both Bob Hinden: Note that sometime requirements docs don't get published because it's sometimes harder to get consensus on requirements. But we'll talk to v6ops. ACTION: Chairs will check with v6ops chairs about coordinating w.g. last call. *********************************** Privacy Extensions for Stateless Address Autoconfiguration in IPv6, draft-ietf-6man-rfc4941bis , Chairs & Fernando Gont Fernando Gont presented slides: https://datatracker.ietf.org/meeting/interim-2020-6man-01/materials/slides-interim-2020-6man-01-sessa-temporary-address-extensions-for-stateless-address-autoconfiguration-in-ipv6 Ole Trøan: Have WGLC comments been sufficiently addressed? We'll confirm on list, but you can speak up now if you think that isn't the case. Alex Petrescu: Is this privacy about the address or the IID? Fernando Gont: I tried to stay away from privacy and this draft is about addresses and not IIDs. Privacy means different things for different people, so staying away from that term. This draft is about temporary addresses. Apps may can determine their own needs for temp addresses. Alex Petrescu: Privacy does have many different interpretations. My question was whether this draft said anything about IID. But OK. Fernando Gont: This mechanism does help with privacy in some scenarios. Loganaden (Logan) Velvindron: On FreeBSD / OpenBSD side, there are no problems or objections from the implementation side. Ole Trøan: No further comments on queue. We will confirm on list, but we seem ready to ship this document. ACTION: Verify issues have been resolved, then plan to advance to the IESG for publication. ************************************* Operations, Administration, and Maintenance (OAM) in Segment Routing Networks with IPv6 Data plane (SRv6), draft-ietf-6man-spring-srv6-oam , Zafar Ali Zafar Ali presented slides: https://datatracker.ietf.org/meeting/interim-2020-6man-01/materials/slides-interim-2020-6man-01-sessa-srv6-oam-draft-ali-spring-srv6 Joel Halpern: You said you added illustrations to address my comments. You did add illustrations but the description does not address my comment. The document needs to address what the router actually has to do when the O bit is set. The text does not describe this. Zafar Ali: How the device implements this is up to the device. Joel: You need to specify what the external observable behavior is wrt the O bit. Zafar: It will make copy of packet for telemetry operation. Joel: That's not observable. Bob: Joel, can you propose text? Joel: I cannot because I don't know what the observable behavior is supposed to be. Zafar: The pseudocode is normative behavior. Joel: No, the pseudocode is internal. You need to specify external expected behavior. Zafar: Happy to have call with you and discuss. Joel: I understand sendtext is normal response. But with current text I don't know what to tell my implementers to implement. Zafar: This is being implemented. We should have call, because I don't know what you expect. Joel: I am happy to talk to you further. I don't think this can progress until it is solved. Ole: We should take to list. If there are others who see same problem as Joel it would be helpful if they can express perceived problem. It would be good to get other PoV. Greg Mirsky: I did not read latest version, so I haven't seen latest changes. I think your interpretation of RFC 7799 is incorrect. O-bit, according to the definition or active, passive, and "in between" OAM,would be an example of the hybrid OAM method. I also think what you are trying to achieve with O-bit is achievable with current iOAM (in-situ OAM). I want to continue our discussion on difference in approaches of using O-bit and iOAM. I would also like to participate in discussion with Joel because I have similar concern. Zafar: I think this is terminology problem. The purpose is to get data from specific endpoints. Ron Bonica: You're just sending an IP packet and that's it. So the first is, ... and then ... Is that right? Presence of SRH will change result. If packet has extension header, ping won't get through. Zafar: Fair comment. Ron: How do we fix it? Zafar: Can take to mailing list. We will come back to it. On Next Steps slide... Discussing use of GitHub. Ole: We're still experimenting with use of GH. It's not meeting all expectations yet. Need new rev of draft. *************************************************** IPv6 Application of the Alternate Marking Method, draft-fz-6man-ipv6-alt-mark , Giuseppe Fioccola Giuseppe Fioccola presented: https://datatracker.ietf.org/meeting/interim-2020-6man-01/materials/slides-interim-2020-6man-01-sessa-ipv6-application-of-the-alternate-marking-method Ron Bonica: It might be good to mark this draft as experimental. Giuseppe: We are just talking about methodology that is transport agnostic. But this is standard track because in the mentioned use case we are just trying to do the same in IPv6 as what is already done for (IPv4?). Ron: It's not clear to me that the experiment is concluded. Would you mind using experimental code points? Giuseppe: The experiment is completed. We cannot fully deploy this until it goes beyond experimental. We already have limited experimental deployment. We need Standards Track. Ole: Need to continue this discussion on list. Éric Vyncke: I want to understand more about using hop-by-hop extension header. This requires more resources from router because of need to remember end-to-end. Giuseppe: I know hop-by-hop is not recommended. But the internal gate nodes only need to read and not handle or notify others. So this can be simply managed. Éric V: Please pay attention to this. Erik Kline (no hat): Similar to Eric's comment, I was wondering if there was value in having both? Giuseppe: Yes, the scope of the draft is the general option. But the draft also mentioned other case. For now we can concentrate on both of these options. Erik K: It wasn't clear if you were specifying to use just one, or both. Giuseppe: The intent is to leave it to implementers. But if draft is adopted, we can discuss further. ************************************************* Transmission of IPv6 Packets over Overlay Multilink Network (OMNI) Interfaces, draft-templin-6man-omni-interface , Fred L Templin Fred Templin presented slides: https://datatracker.ietf.org/meeting/interim-2020-6man-01/materials/slides-interim-2020-6man-01-sessa-transmission-of-ipv6-packets-over-overlay-multilink-network-omni-interfaces Alexandre Petrescu: Several questions. I have written them in jabber for reference. It looks like mobile prefix fits well in IID. Could mobile prefix be longer? Fred: We've said that for prefixes up to 64, it goes in IID. For prefixes longer than 64, we've said additional bits appear in bits 10-63. Because we have prefix length of 10, that lets us use these additional bits. Erik Kline (not hats): If we set aside MTU reassembly, is there any reason this couldn't be just a regular router? Fred: So you're asking whether virtual interface model could be lifted? Erik: assuming reassembly issue could be punted to lower layer. Fred: I have additional charts we don't have time for. Please look at these because I describe there why we need to do it this way. And then please take to mailing list. Erik: There seems to be a certain fate-sharing about needing the link to be up. But I will look at your slides and comment on list. S. DaSilva: What is relationship to other IETF drafts? Fred: We're looking at mobility solution that isn't widely know to IETF participants. But OMNI interface would just be triggered by air-to-ground interface. Meant to be a generic interface. Bob: This is work in progress. I would like to see more justification for why parts of the proposed solution are necessary and why existing standards cannot be used. But we will discuss this on the list. *************************************************** Improving the Robustness of Stateless Address Autoconfiguration (SLAAC) to Flash Renumbering Events, draft-gont-6man-slaac-renum Fernando Gont Fernando Gont presented: https://datatracker.ietf.org/meeting/interim-2020-6man-01/materials/slides-interim-2020-6man-01-sessa-improving-the-reaction-of-ipv6-slaac-to-flash-renumbering-events Jen Linkova: Does this mean if router A advertises zero lifetime and 2nd router advertises ... then prefix will be immediately deprecated? Fernando: Jen: I think it's dangerous when you have 2 routers and both are advertising. Fernando: I'm not sure we have considered that specific case. We'll take to list. Philip Homburg: This is important. But it seems the routers Fernando is working with are fragile wrt ULAs. Newer routers have separate processing for ULAs. This doesn't seem to work to me. Ole: Important comment. We need to make sure we don't end up with a less robust protocol. Eric Vyncke: On slide 6, it's typical for PIO to be sent multiple times. RAs are not sent every minute or so. Frequency is much higher. With this algorithm, frequency may need to be reduced. Fernando: Both algorithms consider that all options may not be in same message. We don't set preferred lifetime to zero immediately. We set to 5 seconds so 2nd RA can be sent with other specifics. You can accommodate use cases by setting values as on this slide. Eric V:This is defeating purpose of your draft. But if you're aware, we can work on this. Fernando: I haven't actually seen case with multiple RAs. I've been working with Tim (Winters). Eric V: We can take this offline. Richard Patterson: We need to look at some other options. Ole: There have been useful comments on list. ******************************************************** Ole: We've run out of time so will skip last presentation. Bob: This has worked rather well. We will consider scheduling another call. We'll be in touch on that. ******************************************************** Meeting Adjourned ********************************************************