Use Cases for Autonomic Networking (UCAN) BoF at IETF 90

Chairs: Michael Behringer, Brian Carpenter

Notes: Dave Waltermire (slightly updated by chairs) and
additional notes by Tom Taylor.

1. Agenda bashing - no changes

2. Overview of autonomic networking ideas; the need, scope & criteria
for use cases:

Michael Behringer (draft-irtf-nmrg-autonomic-network-definitions):
Started in the Network Management Research Group; a number of drafts exist.
Autonomic functions (AF) are horizontal, independent functions with a 
lightweight northbound interface. Little operator input with some high-level policy.
Overall goal = simplify networking
o Distribute what you can, centralize what you must
o Finding the best balance between centralized and distributed functions
OSPF is an autonomic function. Not trying to redefine existing AF. Where are there
new needs? Where are there repetitive tasks? Many existing protocols.
Common trust anchor used to negotiate with multiple protocols.
Good number of attendees read the draft. Can we make specific functions easier?

Sheng Jiang (draft-irtf-nmrg-an-gap-analysis):
Gap Analysis discusses (currently)
non-autonomic behaviors - Hardware aspects less likely to become autonomic.
Software behaviors are good candidates for AF. More coordination is needed between
parts of the network. Approach - Dry runs can be used to reduce failure risks.
Devices can understand the impact of a change through coordination.

Michael Behringer: Scope and Criteria for Use Cases
What infrastructure is needed to support AF? How do the use cases support 
future work?
Criteria = How much value does the function add? How much sharing is needed?
How easy is the use case to abstract? How simple/easy is it to implement?

3. What operators want from autonomic networking (Diego Lopez, Telefonica):
Flexibility through Autonomy in Network Operations
Simplified view - Set of very clearly defined functions and associated devices.
Fulfillment - How do you analyze how it is happening?
Integration/operational efforts cost money and time
Pros and Cons - Cons of current solutions out-weigh pros. Problems:
1) Costly to maintain
2) Static
3) Not service-oriented/long time to market/less personalized options
   for customers - Not monetized for customers.
Build it first, manage it later - Make it work and then manage it. Management
is often an afterthought. "Spaghetti" network management. Provide self-management
to "cut through the spaghetti". Gaining Flexibility through Autonomy - Self 
protecting and healing. Achieved through network software.

4. Use cases (multiple speakers, 5 min each):

Use Case #1 Home Networks (draft-carpenter-nmrg-homenet-an-use-case)
Intended Experience - It works with no human intervention; no administration needed.

Use Case #2 Automatic Address Management (draft-jiang-auto-addr-management)

Use Case #3 Autonomic Bootstrap (draft-behringer-autonomic-bootstrap)
Targeted at different parts of the use case problem set. Executives are interested
in making deployment easier with  less travel.
Don't want to touch the device, no pre-staging, no "leap of faith" during enrollment.
Time windows may be used to identify the time periods when a device may be installed.
Interactions - Registrar connects to the second use case to get addresses.

Use Case #4 Autonomic Control Plane (draft-behringer-autonomic-control-plane)
Provides a "virtual out-of-band channel" that is resilient to issues with the
target network. Should run using IPv6 at day-zero

Use Case #5 Distributed Detection of SLA Violations 
(draft-irtf-nmrg-autonomic-sla-violation-detection)

Use Case #6 Microwave Mobile Backhaul Networks 
(draft-bogdanovic-nmrg-mobile-backhaul-use-case)
I2RS provides a mechanism for providing routing updates. Can coordinate
layer 1 with routing to provide more efficient routing.

Use Case #7 Risk Aware Routing
No draft provided; presented previously in NMRG at IETF 89.
Requires only monitoring local device information. Context awareness is
needed through network coordination to optimize for better performance/behavior.

5. Approaches to solution space
- Discovery + negotiation (Sheng Jaing, draft-jiang-config-negotiation-protocol, 
  draft-jiang-config-negotiation-ps)
- Autonomic bootstrap and Autonomic Control Plane (Toerless Eckert,
  draft-pritikin-bootstrapping-keyinfrastructures,
  draft-behringer-autonomic-control-plane) 


6. Open Mic

Benoit Claise (Area Director) - Asked operators if this is useful to them?

Mark Townsley (Homenet co-chair) - Too many presentations; not enough discussion. 
Disagreed that dedicated plug&play solutions have been proposed (slide 3). 
Asked if the intent is to replace the homenet WG. 

Brian Carpenter (as use case author) - No. Looking at homenet to inform the AN
work in the IETF.

(Someone) - Homenet work has been a massive investment already, but the problem statement
reads as if it could be thrown away

Brian - That was not intended at all. 

Markus Stenberg - Some generalizations about equivalent protocols are inaccurate.

Dirk Kutscher - There is a scoping problem to solve here. 

(Someone) - Just agreeing on common terminology and a problem statement will
be a fair bit of work.

Michael Richardson - Unclear about what a non-working group creating BoF. What
is the path forward? A second WG forming BoF? 

Chair - that is one option. Agree to a set of terminology and problem statement. 
Define a system with properties to drive discussion. Need to be able to reason 
about who owns what device. Don't get bogged down in  anything else.

Michael - This discussion could lead to a common understanding of who owns what device.

Brian - Agree on the importance of that issue. 

Michael - focus efforts there, and drop other issues. He used the term "certificate"
in describing the work to be done. 

Erik Nordmark - This looks like a desire to build infrastructure without addressing 
any AFs. Needs to be used by other WGs. Pick examples to make sure it is working.
Needs more thought.

Mikael Abrahamsson - Not obvious how decentralized this needs to be. Bootstrapping
securely is very hard. Need to look first at architecture then implementations.
As an operator this is important and needs to be solved. 

Chairs - not able to solve all problems in a first release. Is it ok to get there 
in multiple steps?

Mikael - An incremental approach makes sense.

Dean Bogdanovic [jabber] -  I'm in support for moving fwd with the work in UCAN.
UCAN should rely on I2RS and coordinate work with that WG. How is autonomic
bootstrap different from zero touch provisioning?

Max Pritikin [jabber] - There are technical differences that we could argue
about a bunch but in general there are mostly similarities. 

Chairs - at high level they are largely similar.

[Note added after the meeting: this was actually a reference to
 draft-ietf-netconf-zerotouch.]

Elliot Lear - Good work; hard; timescale might not suit the IETF. Work is
needed in small and large scale. Autonomic functions need to be applied at all
layers. Need to think beyond the IETF. Surface additional requirements to the
IAB  to address liaison with other orgs.

Chair Questions:

Is this work useful? In general the room though it was useful. Only one thought
it wasn't.

Which use cases are most helpful? Chair asked for submissions of new use cases.

Are the requirements clear enough to proceed to design?
o Mikael Abrahamsson - It depends on what additional use cases we want 
  to consider. How many do we need?
  Chairs - It is not so much how many we need. It's about identifying common
  needs that resonate across use cases.
o IT/OT convergence - Factories do not always allow network engineers to get in.
o Ran Atkinson - Some focus is needed to shrink the space. A 6-months or less requirement process
  would help with this. Come back for another BoF with a draft requirements document.
o Michael Richardson - Some things can be worked on quickly. Consensus on most
  important areas might not be possible. Agreement on moving quickly might be.
  Suggested an interim meeting to discuss this more. Perhaps a F2F around an ARIN,
  *NOG, or CES meeting.
o  Rene Struik - Little verbiage around the use side of the usage scenarios. Need to
   understand the users dependency on the vendor over the long-run. From user perspective,
   one should aim for no forced lock-in by vendor by technical means, i.e., one needs
   "vendor dependency neutrality", similar to "network neutrality". 

Who is willing to contribute to this work? About 20 hands raised.
Should we draft a proposed WG charter? No objections.
Noted that Homenet, I2RS and zerotouch issues need to be clarified.

---