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
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!
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.
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:
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.
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.
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.
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.
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)
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.
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.
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.
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?
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.