IETF112 ANIMA WG Meeting Agenda and Notes

Master on

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

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

Presenter: Michael Richardson
Time: 10:15 5 minutes
Slides received

Now there is a 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:

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

Presenter: Steffen Fries
Length: 10:20 10 minutes
Slides Received

No questions on slide contents.

05 Update on JWS signed Vouchers

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

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

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
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

Presenter: Toerless Eckert
Length: 11:10 5 minutes
Slides received

Discussion about adoption!
No discussion.

10 Updates of MASA and Registrar Considerations
Presenter: Michael Richardson
Length: 11:15 5 minutes

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
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:
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.