# IETF112 ANIMA WG Meeting Agenda and Notes Master on https://codimd.ietf.org/notes-ietf-112-anima Wednesday Session III, 16:00 UTC - 18:00 UTC Preliminary agenda. Slot number will be assigned when candidate outstading slot for WG documents are resolved. Note taking: Michael Richardson ## 01 Chair-Slides Time: 10:00 10 minutes Presenter: Sheng Jiang, Toerless Eckert Slides received Notes about number of RFCs and errata received and IP protocol Journal article. WG document state: -> asa-guidelines pushed to IESG. -> brski-cloud, WGLC -> constrained-join-proxy, WGLC finished. grasp-distribution: was ready for WGLC in July. voucher-delegation: MCR reports in minutes that the document is low on the priority list until constrained-voucher is done. plea for Shepherds: please volunteer! ## 02 Post WGLC Constrained Join Proxy for Bootstrapping Protocols Draft: https://datatracker.ietf.org/doc/draft-ietf-anima-constrained-join-proxy/05/ Presenter: Michael Richardson Time: 10:10 5 minutes Slides received Reminder this is a stateless proxy for DTLS WGLC in October, received comments from 3 people, no significant technical concerns. Peter has implementations and so does Esko. Sheng: Have you addressed the comments from IOTDIR review? Michael: Yes, these came from Russ Housley Sheng: Next step is on me. ## 03 Status of Constrained-Voucher/BRSKI Draft: https://datatracker.ietf.org/doc/draft-ietf-anima-constrained-voucher/ Presenter: Michael Richardson Time: 10:15 5 minutes Slides received Now there is a brski.org web page Presenting changes since IETF 111. Michael trying to help push dependent draft through CORE WG so this doc would not stall in RFC editor queue. corrected slides at: https://datatracker.ietf.org/meeting/112/materials/slides-112-anima-constrained-voucher-slides-real-ones-00 ### Hackathon results First time successfully using IETF VPN solution. Testing join proxy across network was working. IoT-Onboarding also tested in conjunction with this. Esko Dijk: Our software implementations did also show interop. Nice interop showing/result.. Using EC2 containers, so could not use IPv6. generic problem with docker in AWS. Constrained voucher will only use IPv6. ## 04 Status of BRSKI-AE and derived work Draft: https://datatracker.ietf.org/doc/html/draft-ietf-anima-brski-async-enroll-04 Draft: https://datatracker.ietf.org/doc/html/draft-ietf-anima-brski-prm-00.html Presenter: Steffen Fries Length: 10:20 10 minutes Slides Received No questions on slide contents. ## 05 Update on JWS signed Vouchers Draft: https://datatracker.ietf.org/doc/draft-ietf-anima-jws-voucher/ Presenter: Thomas Werner Length: 10:30 10 minutes Slides Received TE: is this more variability in encoding options ... is this safe against operators not knowing what is occuring, because a Pledge/Registry does not know. TW: This draft just defines the format, and doesn't go into the question of compatibility. TE: does the draft say what is supported? TW: this is in the Accept: header as to what the Pledge wants to receive. TE: so many drafts, but also making sure that when we can't interoperate, we'll know why. TW: if nothing is specified in the headers, then it replies back with whatever is POST'ed. ## 06 Status of RFC8366bis effort Draft: https://datatracker.ietf.org/doc/draft-richardson-anima-rfc8366bis/ Presenter: Michael Richardson Length: 10:40 5 minutes Slides received TBD(chairs): Call for WG adoption. Should get this doc out as RFC in time for BRSKI-AE. Could also try to run Voucher for Internet Standard with h Toerless: Was extensibility in RFC8366 well enough documented ? Michael: Probably not, but also state of YANG back then was not as good (review etc.) as now. Michael: We could also collect extensions from other documents and put into some new document that is all-in-one. Rob Wilton suggests that we probably can go to IS. We could also publish as IS, and do a status change document/process at the IESG. (Followed by discussion about confusion that can result) Toerless: Going directly to IS means that the correct status is reported in the document, which otherwise can cause confusion in the future. ## 07 Autonomic IP Address To Access Control Groups Mapping Draft: https://datatracker.ietf.org/doc/draft-yizhou-anima-ip-to-access-control-groups/ Presenter: Yizhou Length: 10:45 10..15 min Slides received There were questions about how to use GRASP well in this situation. It seems that further discussion is needed to get the mechanism better. Toerless was asking for an explicit service example with its parameters, possibly as an appendix, to show something that could be actually implemented for a fully working reference implementation. One of the important things to work out, where this helps is then to identify the extension points needed, and which/how to pass them to IANA (registries required) ## 08 An Autonomic Mechanism for Resource-based Network Services Auto-deployment Presenter: Yujing Zhou Draft: https://www.ietf.org/archive/id/draft-dang-anima-network-service-auto-deployment-01.txt Length: 11:00 5..10 min Slides received Toerless: An appendix with a full example would help (like last draft shown) Michael: (re cross-domain scenario:) Important to understand what is the use case for this, to figure out the appropriate trust. It might be this needs the appropriate authentication in GRASP, or it might ... But I think that it would be helpful to call out the example for the cross domain example. Yujing: Want to discuss negotiation in this draft. Michael: Before going to the effort of describing this cross-domain, please explain why we would ever want to do this. Need to explain why cross-domain. Before you solve the hard problem, check that it needs to be solved. Sheng: As co-author. We are not going to solve this in this draft. All ANIMA drafts are limited to a single domain. We do have the use case in the real world, mostly for end-to-end quality guarantees. If part of the path across one domain is only best-effort then that would be a problem. But that is not the purpose of the draft. How to solve this cross-domain is another issue. Michael: I think that I am saying exactly that. Why are you introducing the question of cross-domain? Sheng: Point taken. We will make that clear in the draft. ## 09 Status of GRASP / DNS work Draft: https://datatracker.ietf.org/doc/draft-eckert-anima-services-dns-autoconfig/ Draft: https://datatracker.ietf.org/doc/draft-eckert-anima-grasp-dnssd/ Presenter: Toerless Eckert Length: 11:10 5 minutes Slides received Discussion about adoption! No discussion. ## 10 Updates of MASA and Registrar Considerations https://datatracker.ietf.org/doc/draft-richardson-anima-masa-considerations/ https://datatracker.ietf.org/doc/draft-richardson-anima-registrar-considerations/ Presenter: Michael Richardson Length: 11:15 5 minutes NO SLIDES RECEIVED Michael: Documents are not dead. Some work in 2TG RG, but not receiving a lot of feedback that these are useful documents. Toerless: Perhaps we don't have enough operators complaining. ## 11 Draft: Requirement and a Reference Model of L2 ACP based ANI https://datatracker.ietf.org/doc/draft-yizhou-anima-l2-acp-based-ani/ Presenter: Zhou Yujing Time: 11:25 10 minutes Slides received TE: discusses IPv6-LL forwarding process for ACP (over L3). Can you explain the same process for L2ACP? ZY: the draft is discussing scenarios and requirements. TE: I think that would be the first step, but some way about how forwarding would work. ZY: needs to think more about the question. Michael: Considering slide 3(L2ACP case), trying to understand this use case. We do this work to talk to management interfaces. None of these have L3 addresses, or run L3 protocols. ZY: ??? Michael: Sounds like they don't need to be managed. I.e., they don't have any management interfaces. Yizhou: I'm sure that they are going to have management interfaces (all equivalent does). This about what happens before it is enroled. The Mgmt interface still needs to make a DHCP request. This happens are the L2 loop free topology has been built up. Hence, doing it step by step. Michael: If it works now, why change it? We created ACP so that we don't need to do that. I.e., we can onboard devices even if they don't have L2 or L3 connectivity. If L2 works then you can DHCP, so I don't know why you need ACP. I don't find this example credible. It looks like you are trying to do L2 tricks rather than then do L3. What is going to happen to these devices? Sounds like a people management problem rather than a network management problem. Toerless: Can we take this on to the next part of the converstation? ## 12 Discussion about L2 ACP efforts Prior slot new work and pre-existing work: https://datatracker.ietf.org/doc/draft-richardson-anima-l2-friendly-acp/ Lead by: Michael Richardson, Zhou Yujin, Toerless Eckert Time: 11:35 20 minutes No slides planned TE: ACP might be slow if there is no L3 hardware MCR: MACsec? L2 mechanism to transport data. Doesn't require discovery or GRASP at L2. MCR asks why this implies DULL/GRASP at L2, vs just forwarding L2 frames. TE: the control plane CPUs would be hosts on this L2 "VPN"/ "VLAN" Michael: Is this just GRASP over a new transport? TE: Crypto could still be IPsec, P2P from core router to on-link devices (via VLAN and STP L2) Michael: Over that STP VLAN? TE: Do we need any new cypto. Like MACsec due to these joint L2/L3 switches that can do it in hardware and that is faster than doing IP Sec in software. Problem is MACsec isn't in all switches, only high end switches. Michael: Does it matter if IPsec is being done in software. Still concerned about spanning tree. Spanning tree for VOIP is a disaster. Need to use OSPF or IS-IS. TE: Lots of service provider networks are using L2 access networks, so sometimes do have Michael: Quick a lot of VoIP customers own access networks so that they don't tolerate delays. STP might be off for other reasons and don't want to turn it for this scenario. Until the devices are connected in. TE: ??? Michael: I think that you are going to have L3 anyway. Realized that we could L2 discovery over LLDP. But after that the traffic would be unicast host/host. (Need to turn off ND) TE: There is an ACP use case for L2 switches. Michael: What is the conclusion? TE: Need to find time a proposal for the L2ACP case.