-
Notifications
You must be signed in to change notification settings - Fork 3
/
draft-03b.txt
1512 lines (1090 loc) · 67.8 KB
/
draft-03b.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
Network Working Group A. Clemm
Internet-Draft Futurewei
Intended status: Informational L. Ciavaglia
Expires: June 4, 2021 Nokia
L. Granville
Federal University of Rio Grande do Sul (UFRGS)
J. Tantsura
Juniper Networks
December 1, 2020
Intent-Based Networking - Concepts and Definitions
draft-irtf-nmrg-ibn-concepts-definitions-03
Abstract
Intent and Intent-Based Networking (IBN) are taking the industry by
storm. At the same time, those terms are used loosely and often
inconsistently, in many cases overlapping and confused with other
concepts such as "Policy." This document clarifies the concept of
"Intent" and provides an overview of the functionality that is
associated with it. The goal is to contribute towards a common and
shared understanding of terms, concepts, and functionality that can
be used as the foundation to guide further definition of associated
research and engineering problems and their solutions.
This document is a product of the IRTF Network Management Research
Group (NMRG). It reflects the consensus of the RG, receiving reviews
from 8 members and explicit support from 14 (beyond the authors). It
is published for informational purposes.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 4, 2021.
Clemm, et al. Expires June 4, 2021 [Page 1]
Internet-Draft December 2020
Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Key Words . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Definitions and Acronyms . . . . . . . . . . . . . . . . . . 5
4. Introduction of Concepts . . . . . . . . . . . . . . . . . . 6
4.1. Intent and Intent-Based Management . . . . . . . . . . . 6
4.2. Related Concepts . . . . . . . . . . . . . . . . . . . . 9
4.2.1. Service Models . . . . . . . . . . . . . . . . . . . 9
4.2.2. Policy and Policy-Based Network Management . . . . . 11
4.2.3. Distinguishing between Intent, Policy, and Service
Models . . . . . . . . . . . . . . . . . . . . . . . 13
5. Principles . . . . . . . . . . . . . . . . . . . . . . . . . 14
6. Intent-Based Networking - Functionality . . . . . . . . . . . 17
6.1. Intent Fulfillment . . . . . . . . . . . . . . . . . . . 17
6.1.1. Intent Ingestion and Interaction with Users . . . . . 17
6.1.2. Intent Translation . . . . . . . . . . . . . . . . . 18
6.1.3. Intent Orchestration . . . . . . . . . . . . . . . . 18
6.2. Intent Assurance . . . . . . . . . . . . . . . . . . . . 18
6.2.1. Monitoring . . . . . . . . . . . . . . . . . . . . . 19
6.2.2. Intent Compliance Assessment . . . . . . . . . . . . 19
6.2.3. Intent Compliance Actions . . . . . . . . . . . . . . 19
6.2.4. Abstraction, Aggregation, Reporting . . . . . . . . . 20
7. Life-cycle . . . . . . . . . . . . . . . . . . . . . . . . . 20
8. Additional Considerations . . . . . . . . . . . . . . . . . . 22
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
10. Security Considerations . . . . . . . . . . . . . . . . . . . 22
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24
12. Informative References . . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
Clemm, et al. Expires June 4, 2021 [Page 2]
Internet-Draft December 2020
1. Introduction
Traditionally in the IETF, interest regarding management and
operations has focused on individual network and device features.
Standardization emphasis has generally been put on management
instrumentation that needed to be provided to a networking device. A
prime example of this is SNMP-based management [RFC3411] and the 200+
MIBs that have been defined by the IETF over the years. More recent
examples include YANG data model definitions [RFC7950] for aspects
such as interface configuration, ACL configuration, and Syslog
configuration.
There is a sense and reality that in modern network environments
managing networks by configuring myriads of "nerd knobs" on a device-
by-device basis is no longer sustainable. Significant challenges
arise with keeping device configurations not only consistent across a
network but also consistent with the needs of services and service
features they are supposed to enable. Additional challenges arise
with regards to being able to rapidly adapt the network as needed and
to be able to do so at scale. At the same time, operations need to
be streamlined and automated wherever possible to not only lower
operational expenses but also allow for rapid reconfiguration of
networks at sub-second time scales and to ensure that networks are
delivering their functionality as expected. Among other things, this
requires the ability to consume and process analytics in a way that
is aware of context as well as intended outcomes at near real-time
speeds.
Accordingly, the IETF has begun to address end-to-end management
aspects that go beyond the realm of individual devices in isolation.
Examples include the definition of YANG models for network topology
[RFC8345] or the introduction of service models used by service
orchestration systems and controllers [RFC8309]. Much interest has
been fueled by the discussion about how to manage autonomic networks,
as discussed in the ANIMA working group. Autonomic networks are
driven by the desire to lower operational expenses and make the
management of the network as a whole more straightforward, putting it
at odds with the need to manage the network one device and one
feature at a time. However, while autonomic networks are intended to
exhibit "self-management" properties, they still require input from
an operator or outside system to provide operational guidance and
information about the goals, purposes, and service instances that the
network is to serve.
This input and operational guidance are commonly referred to as
"intent," and networks that allow network operators to provide their
input using intent as Intent-Based Networks (IBN) and the systems
that help implement intent as Intent-Based Systems (IBS). However,
Clemm, et al. Expires June 4, 2021 [Page 3]
Internet-Draft December 2020
intent is about more than just enabling a form of operator
interaction with the network that involves higher-layer abstractions.
It is also about the ability to let operators focus on what they want
their desired outcomes to be while leaving details about how those
outcomes would, in fact, be achieved to the IBN (respectively IBS).
This, in turn, enables much greater operational efficiency at greater
scale, in shorter time scales, with less dependency on human
activities (and possibility for mistakes), and an ideal candidate,
e.g., for artificial intelligence techniques that can bring about the
next level of network automation [Clemm20].
This vision has since caught on with the industry in a big way,
leading to a significant number of solutions that offer Intent-Based
Management that promise network providers to manage networks
holistically at a higher level of abstraction and as a system that
happens to consist of interconnected components, as opposed to a set
of independent devices (that happen to be interconnected). Those
offerings include IBN and IBS (offering full a life-cycle of intent),
SDN controllers (offering a single point of control and
administration for a network), and network management and Operations
Support Systems (OSS).
However, it has been recognized for a long time that comprehensive
management solutions cannot operate only at the level of individual
devices and low-level configurations. In this sense, the vision of
intent is not entirely new. In the past, ITU-T's model of a
Telecommunications Management Network (TMN) introduced a set of
management layers that defined a management hierarchy, consisting of
network element, network, service, and business management [M3010].
High-level operational objectives would propagate in a top-down
fashion from upper to lower layers. The associated abstraction
hierarchy was crucial to decompose management complexity into
separate areas of concern. This abstraction hierarchy was
accompanied by an information hierarchy that concerned itself at the
lowest level with device-specific information, but that would, at
higher layers, include, for example, end-to-end service instances.
Similarly, the concept of Policy-Based Network Management (PBNM) has,
for a long time, touted the ability to allow users to manage networks
by specifying high-level management policies, with policy systems
automatically "rendering" those policies, i.e., breaking them down
into low-level configurations and control logic.
What has been missing, however, is putting these concepts into a more
current context and updating them to account for current technology
trends. This document clarifies the concepts behind intent. It
differentiates intent from related concepts. It also provides an
overview of first-order principles of IBN as well as the associated
functionality. The goal is to contribute to a common and shared
Clemm, et al. Expires June 4, 2021 [Page 4]
Internet-Draft December 2020
understanding that can be used as a foundation to articulate research
and engineering problems in the area of IBN. It should be noted that
the articulation of those problems is beyond the scope of this
document.
2. Key Words
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
3. Definitions and Acronyms
ACL: Access Control List
API: Application Programming Interface
Intent: A set of operational goals (that a network should meet)
and outcomes (that a network is supposed to deliver), defined in a
declarative manner without specifying how to achieve or implement
them.
IBA: Intent-Based Analytics - Analytics that are defined and
derived from users' intent and used to validate the intended
state.
Intent-Based Management - The concept of performing management
based on the concept of intent.
IBN: Intent-Based Network - A network that can be managed using
intent.
IBS: Intent-Based System - A system that supports management
functions that can be guided using intent.
PBNM: Policy-Based Network Management
Policy: A set of rules that governs the choices in behavior of a
system.
PDP: Policy Decision Point
PEP: Policy Enforcement Point
Service Model: A model that represents a service that is provided
by a network to a user.
Clemm, et al. Expires June 4, 2021 [Page 5]
Internet-Draft December 2020
SSoT: Single Source of Truth - A functional block in an IBN system
that normalizes users' intent and serves as the single source of
data for the lower layers.
SVoT: Single Version of Truth
4. Introduction of Concepts
The following section provides an overview of the concept of intent
and Intent-Based Management. It also provides an overview of the
related concepts of service models and policies (and Policy-Based
Network Management), and explains how they relate to intent and
Intent-Based Management.
4.1. Intent and Intent-Based Management
The term intent was first introduced in the context of Autonomic
Networks, where it is defined as "an abstract, high-level policy used
to operate a network" [RFC7575]. According to this definition, an
intent is a specific type of policy provided by a user to provide
guidance to the Autonomic Network that would otherwise operate
without human intervention. However, to avoid using intent simply as
a synonym for policy, a distinction that differentiates intent
clearly from other types of policies needs to be introduced.
Intent-Based Management aims to lead towards networks that are
fundamentally simpler to manage and operate, requiring only minimal
outside intervention. Networks, even when they are considered
autonomic, are not clairvoyant and have no way of automatically
knowing particular operational goals nor what instances of networking
services to support. In other words, they do not know what the
intent of the network provider is that gives the network the purpose
of its being. This still needs to be communicated by what informally
constitutes intent. That being said, the concept of intent is not
limited just to autonomic networks, such as networks that feature an
Autonomic Control Plane [I-D.ietf-anima-autonomic-control-plane], but
applies to any network.
More specifically, intent is a declaration of operational goals that
a network should meet and outcomes that the network is supposed to
deliver, without specifying how to achieve them. Those goals and
outcomes are defined in a manner that is purely declarative - they
specify what to accomplish, not how to achieve it. Intent thus
applies several important concepts simultaneously:
o It provides data abstraction: users and operators do not need to
be concerned with low-level device configuration and nerd knobs.
Clemm, et al. Expires June 4, 2021 [Page 6]
Internet-Draft December 2020
o It provides functional abstraction from particular management and
control logic: users and operators do not need to be concerned
even with how to achieve a given intent. What is specified is the
desired outcome, with the IBS automatically figuring out a course
of action (e.g., using an algorithm or applying a set of rules
derived from the intent) for how to achieve the outcome.
The following are some examples of intent, expressed in natural
language for the sake of clarity (actual interfaces used to convey
intent may differ):
o "Steer networking traffic originating from endpoints in one
geography away from a second geography, unless the destination
lies in that second geography."
o "Avoid routing networking traffic originating from a given set of
endpoints (or associated with a given customer) through a
particular vendor's equipment, even if this occurs at the expense
of reduced service levels."
o "Maximize network utilization even if it means trading off service
levels (such as latency, loss) unless service levels have
deteriorated 20% or more from their historical mean."
o "VPN service must have path protection at all times for all
paths."
o "Generate in-situ OAM data and network telemetry across for later
offline analysis whenever significant fluctuations in latency
across a path are observed."
In contrast, the following are examples of what would not constitute
intent (again, expressed in natural language for the sake of
clarity):
o "Configure a given interface with an IP address." This would be
considered device configuration and fiddling with configuration
knobs, not intent. Pointing to a resourse that could potentially
serve as the resource pool for providing IP addresses and/or
similar network artifacts that could be used for conifguration
would still be a part of intent.
o "When interface utilization exceeds a specific threshold, emit an
alert." This would be a rule that can help support network
automation, but a simple rule is not an intent.
o "Configure a VPN with a tunnel from A to B over path P." This
would be considered as a configuration of a service.
Clemm, et al. Expires June 4, 2021 [Page 7]
Internet-Draft December 2020
o "Deny traffic to prefix P1 unless it is traffic from prefix P2."
This would be an example of an access policy or a firewall rule,
not intent.
In an autonomic network, intent should be rendered by the network
itself, i.e., translated into device-specific rules and courses of
action. Ideally, it should not even be orchestrated or broken down
by a higher-level, centralized system but by the network devices
themselves using a combination of distributed algorithms and local
device abstraction. In this idealized vision, because intent holds
for the network as a whole, intent should ideally be automatically
disseminated across all devices in the network, which can themselves
decide whether they need to act on it.
However, such decentralization will not be practical in all cases.
Certain functions will need to be at least conceptually centralized.
For example, users may require a single conceptual point of
interaction with the network. Likewise, the vast majority of network
devices may be intent-agnostic and focus only (for example) on the
actual forwarding of packets. This implies that certain intent
functionality needs to be provided by functions that are specialized
for that purpose (which, depending on the scenario, may be hosted on
dedicated systems or co-hosted with other networking functions). For
example, functionality to translate intent into courses of actions
and algorithms to achieve desired outcomes may need to be provided by
such specialized functions. Of course, to avoid single points of
failure, the implementation and hosting of those functions may still
be distributed, even if conceptually centralized.
Accordingly, an IBN is a network that can be managed using intent.
This means that it is able to recognize and ingest intent of an
operator or user and configure and adapt itself autonomously
according to the user intent, achieving an intended outcome (i.e., a
desired state or behavior) without requiring the user to specify the
detailed technical steps for how to achieve the outcome. Instead,
the IBN will be able to figure out on its own how to achieve the
outcome. Similarly, an IBS is a system that allows users to manage a
network using intent. Such a system will serve as a point of
interaction with users and implement the functionality that is
necessary to achieve the intended outcomes, interacting for that
purpose with the network as required.
Other definitions of intent exist, such as [TR523]. Intent there is
simply defined as a declarative interface that is typically provided
by a controller. It implies the presence of a centralized function
that renders the intent into lower-level policies or instructions and
orchestrates them across the network. While this is certainly one
way of implementation, the definition presented here is narrower in
Clemm, et al. Expires June 4, 2021 [Page 8]
Internet-Draft December 2020
the sense that it emphasizes the importance of managing the network
by specifying desired outcomes without the specific steps to be taken
in order to achieve the outcome. A controller API that simply
provides a network-level of abstraction would not necessarily qualify
as intent. Likewise, ingestion and recognition of intent may not
necessarily occur via a traditional API but may involve other types
of human-machine interactions.
4.2. Related Concepts
4.2.1. Service Models
A service model is a model that represents a service that is provided
by a network to a user. Per [RFC8309], a service model describes a
service and its parameters in a portable/implementation-agnostic way
that can be used independently of the equipment and operating
environment on which the service is realized. Two subcategories are
distinguished: a "Customer Service Model" describes an instance of a
service as provided to a customer, possibly associated with a service
order. A "Service Delivery Model" describes how a service is
instantiated over existing networking infrastructure.
An example of a service could be a Layer 3 VPN service [RFC8299], a
Network Slice [I-D.ietf-teas-ietf-network-slice-definition], or
residential Internet access. Service models represent service
instances as entities in their own right. Services have their own
parameters, actions, and life-cycles. Typically, service instances
can be bound to end-users, who might be billed for the services
provided.
Instantiating a service typically involves multiple aspects:
o A user (or northbound system) needs to define and/or request a
service to be instantiated.
o Resources, such as IP addresses, AS numbers, VLAN or VxLAN pools,
interfaces, bandwidth, or memory need to be allocated.
o How to map services to the resources needs to be defined.
Multiple mappings are often possible, which to select may depend
on context (such as which type of access is available to connect
the end-user with the service).
o Bindings between upper and lower-level objects need to be
maintained.
Clemm, et al. Expires June 4, 2021 [Page 9]
Internet-Draft December 2020
o Once instantiated, the service operational state needs to be
validated and assured to ensure that the network indeed delivers
the service as requested.
They involve a system, such as a controller, that provides
provisioning logic. This includes breaking down high-level
abstractions into lower-level device abstractions, identifying and
allocating system resources, and orchestrating individual
provisioning steps. Orchestration operations are generally conducted
using a "push" model in which the controller/manager initiates the
operations as required, then pushes down the specific configurations
to the device and validates whether the new changes have been
accepted and the new operational/derived states are achieved and in
sync with the intent/desired state. In addition to instantiating and
creating new instances of a service, updating, modifying, and
decommissioning services need to be also supported. The device
itself typically remains agnostic to the service or the fact that its
resources or configurations are part of a service/concept at a higher
layer.
Instantiated service models map to instantiated lower-layer network
and device models. Examples include instances of paths or instances
of specific port configurations. The service model typically also
models dependencies and layering of services over lower-layer
networking resources that are used to provide services. This
facilitates management by allowing to follow dependencies for
troubleshooting activities, to perform impact analysis in which
events in the network are assessed regarding their impact on services
and customers. Services are typically orchestrated and provisioned
top-to-bottom, which also facilitates keeping track of the assignment
of network resources (composition), while troubleshooted bottom-up
(decomposition). Service models might also be associated with other
data that does not concern the network but provides business context.
This includes things such as customer data (such as billing
information), service orders and service catalogs, tariffs, service
contracts, and Service Level Agreements (SLAs), including contractual
agreements regarding remediation actions.
[I-D.ietf-teas-te-service-mapping-yang] is an example of a data model
that provides a mapping for customer service models (e.g., the L3VPN
Service Model) to Traffic Engineering (TE) models (e.g., the TE
Tunnel or the Abstraction and Control of Traffic Engineered Networks
Virtual Network model)
Like intent, service models provide higher layers of abstraction.
Service models are often also complemented with mappings that capture
dependencies between service and device or network configurations.
Unlike intent, service models do not allow to define a desired
Clemm, et al. Expires June 4, 2021 [Page 10]
Internet-Draft December 2020
"outcome" that would be automatically maintained by the intent
system. Instead, the management of service models requires the
development of sophisticated algorithms and control logic by network
providers or system integrators.
4.2.2. Policy and Policy-Based Network Management
Policy-Based Network Management (PBNM) is a management paradigm that
separates the rules that govern the behavior of a system from the
functionality of the system. It promises to reduce maintenance costs
of information and communication systems while improving flexibility
and runtime adaptability. It is present today at the heart of a
multitude of management architectures and paradigms, including SLA-
driven, Business-driven, autonomous, adaptive, and self-* management
[Boutaba07]. The interested reader is asked to refer to the rich set
of existing literature, which includes this and many other
references. In the following, we will only provide a much-abridged
and distilled overview.
At the heart of policy-based management is the concept of a policy.
Multiple definitions of policy exist: "Policies are rules governing
the choices in the behavior of a system" [Sloman94]. "Policy is a
set of rules that are used to manage and control the changing and/or
maintaining of the state of one or more managed objects"
[Strassner03]. Common to most definitions is the definition of a
policy as a "rule." Typically, the definition of a rule consists of
an event (whose occurrence triggers a rule), a set of conditions
(which get assessed and which must be true before any actions are
actually "fired"), and, finally, a set of one or more actions that
are carried out when the condition holds.
Policy-based management can be considered an imperative management
paradigm: Policies precisely specified what needs to be done when and
in which circumstance. By using policies, management can, in effect,
be defined as a set of simple control loops. This makes policy-based
management a suitable technology to implement autonomic behavior that
can exhibit self-* management properties, including self-
configuration, self-healing, self-optimization, and self-protection.
In effect, policies define management as a set of simple control
loops.
Policies typically involve a certain degree of abstraction in order
to cope with the heterogeneity of networking devices. Rather than
having a device-specific policy that defines events, conditions, and
actions in terms of device-specific commands, parameters, and data
models, a policy is defined at a higher level of abstraction
involving a canonical model of systems and devices to which the
policy is to be applied. A policy agent on a controller or the
Clemm, et al. Expires June 4, 2021 [Page 11]
Internet-Draft December 2020
device subsequently "renders" the policy, i.e., translates the
canonical model into a device-specific representation. This concept
allows applying the same policy across a wide range of devices
without needing to define multiple variants. In other words - policy
definition is de-coupled from policy instantiation and policy
enforcement. This enables operational scale and allows network
operators and authors of policies to think in higher terms of
abstraction than device specifics and be able to reuse the same,
high-level definition across different networking domains, WAN, DC,
or public cloud.
PBNM is typically "push-based": Policies are pushed onto devices
where they are rendered and enforced. The push operations are
conducted by a manager or controller, which is responsible for
deploying policies across the network and monitor their proper
operation. That being said, other policy architectures are possible.
For example, policy-based management can also include a pull-
component in which the decision regarding which action to take is
delegated to a so-called Policy Decision Point (PDP). This PDP can
reside outside the managed device itself and has typically global
visibility and context with which to make policy decisions. Whenever
a network device observes an event that is associated with a policy
but lacks the full definition of the policy or the ability to reach a
conclusion regarding the expected action, it reaches out to the PDP
for a decision (reached, for example, by deciding on an action based
on various conditions). Subsequently, the device carries out the
decision as returned by the PDP - the device "enforces" the policy
and hence acts as a PEP (Policy Enforcement Point). Either way, PBNM
architectures typically involve a central component from which
policies are deployed across the network and/or policy decisions
served.
Like Intent, policies provide a higher layer of abstraction. Policy
systems are also able to capture dynamic aspects of the system under
management through the specification of rules that allow defining
various triggers for specific courses of actions. Unlike intent, the
definition of those rules (and courses of actions) still needs to be
articulated by users. Since the intent is unknown, conflict
resolution within or between policies requires interactions with a
user or some kind of logic that resides outside of PBM. In that
sense, policy constitutes a lower level of abstraction than intent,
and it is conceivable for Intent-Based Systems to generate policies
that are subsequently deployed by a PBM, allowing PBM to support
Intent-Based Networking.
Clemm, et al. Expires June 4, 2021 [Page 12]
Internet-Draft December 2020
4.2.3. Distinguishing between Intent, Policy, and Service Models
What Intent, Policy, and Service Models all have in common is the
fact that they involve a higher-layer of abstraction of a network
that does not involve device-specifics, that generally transcends
individual devices, and that makes the network easier to manage for
applications and human users compared to having to manage the network
one device at a time. Beyond that, differences emerge. Service
models have less in common with policy and intent than policy and
intent do with each other.
Summarized differences:
o A service model is a data model that is used to describe instances
of services that are provided to customers. A service model has
dependencies on lower-level models (device and network models)
when describing how the service is mapped onto the underlying
network and IT infrastructure. Instantiating a service model
requires orchestration by a system; the logic for how to
orchestrate/manage/provide the service model and how to map it
onto underlying resources is not included as part of the model
itself.
o Policy is a set of rules, typically modeled around a variation of
events/conditions/actions, used to express simple control loops
that can be rendered by devices without requiring intervention by
the outside system. Policies let users define what to do under
what circumstances, but they do not specify the desired outcome.
o Intent is a high-level, declarative goal that operates at the
level of a network and services it provides, not individual
devices. It is used to define outcomes and high-level operational
goals, without specifying how those outcomes should be achieved or
how goals should specifically be satisfied, and without the need
to enumerate specific events, conditions, and actions. Which
algorithm or rules to apply can be automatically "learned/derived
from intent" by the intent system. In the context of autonomic
networking, intent is ideally rendered by the network itself;
also, the dissemination of intent across the network and any
required coordination between nodes is resolved by the network
without the need for external systems.
One analogy to capture the difference between policy and intent
systems is that of Expert Systems and Learning Systems in the field
of Artificial Intelligence. Expert Systems operate on knowledge
bases with rules that are supplied by users, analogous to policy
systems whose policies are supplied by users. They are able to make
automatic inferences based on those rules but are not able to "learn"
Clemm, et al. Expires June 4, 2021 [Page 13]
Internet-Draft December 2020
new rules on their own. Learning Systems (popularized by deep
learning and neural networks), on the other hand, are able to learn
without depending on user programming or articulation of rules.
However, they do require a learning or training phase, and
explanations of actions that the system actually takes provide a
different set of challenges. Analogous to intent-based systems,
users focus on what they would like the learning system to accomplish
but not how to do it.
5. Principles
The following main operating principles allow characterizing the
intent-based/-driven/-defined nature of a system.
1. Single Source of Truth (SSoT) and Single Version/View of Truth
(SVoT). The SSoT is an essential component of an intent-based
system as it enables several important operations. The set of
validated intent expressions is the system's SSoT. SSoT and the
records of the operational states enable comparing the intended/
desired state and actual/operational states of the system and
determining drift between them. SSoT and the drift information
provide the basis for corrective actions. If the intent-based
system is equipped with prediction capabilities or means, it can
further develop strategies to anticipate, plan, and pro-actively
act on the diverging trends with the aim to minimize their
impact. Beyond providing a means for consistent system
operation, SSoT also allows for better traceability to validate
if/how the initial intent and associated business goals have been
properly met, to evaluate the impacts of changes in the intent
parameters and impacts and effects of the events occurring in the
system.
Single Version (or View) of Truth derives from the SSoT and can
be used to perform other operations such as query, poll, or
filter the measured and correlated information to create so-
called "views." These views can serve the operators and/or the
users of the intent-based system. In order to create intents as
single sources of truth, the IBS must follow well-specified and
well-documented processes and models. In other contexts
[Lenrow15], SSoT is also referred to as the invariance of the
intent.
2. One-touch but not one-shot. In an ideal intent-based system, the
user expresses its intents in one form or another, and then the
system takes over all subsequent operations (one-touch). A zero-
touch approach could also be imagined in the case where the
intent-based system has the capabilities or means to recognize
intentions in any form of data. However, the zero- or one-touch
approach should not be mistaken the fact that reaching the state
Clemm, et al. Expires June 4, 2021 [Page 14]
Internet-Draft December 2020
of a well-formed and valid intent expression is not a one-shot
process. On the contrary, the interfacing between the user and
the intent-based system could be designed as an interactive and
iterative process. Depending on the level of abstraction, the
intent expressions will initially contain more or less implicit
parts and unprecise or unknown parameters and constraints. The
role of the intent-based system is to parse, understand, and
refine the intent expression to reach a well-formed and valid
intent expression that can be further used by the system for the
fulfillment and assurance operations. An intent refinement
process could use a combination of iterative steps involving the
user to validate the proposed refined intent and to ask the user
for clarifications in case some parameters or variables could not
be deduced or learned by means of the system itself. In
addition, the Intent-Based System will need to moderate between
conflicting intent, helping users to properly choose between
intent alternatives that may have different ramifications.
3. Autonomy and Supervision. A desirable goal for an intent-based
system is to offer a high degree of flexibility and freedom on
both the user side and system side, e.g., by giving the user the
ability to express intents using its own terms, by supporting
different forms of expression of intents and being capable of
refining the intent expressions to well-formed and exploitable
expressions. The dual principle of autonomy and supervision
allows operating a system that will have the necessary levels of
autonomy to conduct its tasks and operations without requiring
the intervention of the user and taking its own decisions (within
its areas of concern and span of control) as how to perform and
meet the user expectations in terms of performance and quality,
while at the same time providing the proper level of supervision
to satisfy the user requirements for reporting and escalation of
relevant information.
4. Learning. An intent-based system is a learning system. By
contrast to the imperative type of system, such as Event-
Condition-Action policy rules, where the user defines beforehand
the expected behavior of the system to various events and
conditions, in an intent-based system, the user only declares
what the system should achieve and not how to achieve these
goals. There is thus a transfer of reasoning/rationality from
the human (domain knowledge) to the system. This transfer of
cognitive capability also implies the availability in the intent-
based system of capabilities or means for learning, reasoning,
and knowledge representation and management. The learning
abilities of an IBS can apply to different tasks such as
optimization of the intent rendering or intent refinement
processes. The fact that an intent-based system is a
Clemm, et al. Expires June 4, 2021 [Page 15]
Internet-Draft December 2020
continuously evolving system creates the condition for continuous
learning and optimization. Other cognitive capabilities such as
planning can also be leveraged in an intent-based system to
anticipate or forecast future system state and response to
changes in intents or network conditions and thus elaboration of
plans to accommodate the changes while preserving system
stability and efficiency in a trade-off with cost and robustness
of operations. Cope with unawareness of users (smart
recommendations).
5. Capability exposure. Capability exposure consists in the need
for expressive network capabilities, requirements, and
constraints to be able to compose/decompose intents and map the
user's expectations to the system capabilities.
6. Abstract and outcome-driven. Users do not need to be concerned
with how intent is achieved and are empowered to think in terms
of outcomes. In addition, they can refer to concepts at a higher
level of abstractions, independent e.g. of vendor-specific
renderings.
The described principles are perhaps the most prominent, but they are
not an exhaustive list. There are additional aspects to consider,
such as:
o Intent targets are not individual devices but typically
aggregations (such as groups of devices adhering to a common
criteria, such as devices of a particular role) or abstractions
(such as service types, service instances, topologies)
o Abstraction and inherent virtualization: agnostic to
implementation details
o Human-tailored network interaction: IBN SHOULD speak the language
of the user as opposed to requiring the user to speak the language
of the device/network
o Explainability as an important IBN function, detection and IBN-
aided resolution of conflicting intent, reconciliation of what the
user wants and what the network can actually do.
o Inherent support, verification, and assurance of trust
All of these principles and considerations have implications on the
design of intent-based systems and their supporting architecture and
need to be considered when deriving functional and operational
requirements.
Clemm, et al. Expires June 4, 2021 [Page 16]
Internet-Draft December 2020
6. Intent-Based Networking - Functionality
Intent-Based Networking involves a wide variety of functions that can
be roughly divided into two categories:
o Intent Fulfillment provides functions and interfaces that allow
users to communicate intent to the network and that perform the
necessary actions to ensure that intent is achieved. This
includes algorithms to determine proper courses of action and
functions that learn to optimize outcomes over time. In addition,
it also includes more traditional functions such as any required
orchestration of coordinated configuration operations across the
network and rendering of higher-level abstractions into lower-
level parameters and control knobs.
o Intent Assurance provides functions and interfaces that allow
users to validate and monitor that the network is indeed adhering
to and complying with intent. This is necessary to assess the
effectiveness of actions taken as part of fulfillment, providing
important feedback that allows those functions to be trained or
tuned over time to optimize outcomes. In addition, Intent
Assurance is necessary to address "intent drift." Intent drift
occurs when a system originally meets the intent, but over time
gradually allows its behavior to change or be affected until it no
longer does or does so in a less effective manner.
The following sections provide a more comprehensive overview of those
functions.
6.1. Intent Fulfillment
Intent fulfillment is concerned with the functions that take intent
from its origination by a user (generally, an administrator of the
responsible organization) to its realization in the network.
6.1.1. Intent Ingestion and Interaction with Users
The first set of functions is concerned with "ingesting" intent,
i.e., obtaining intent through interactions with users. They provide
functions that recognize intent from interaction with the user as
well as functions that allow users to refine their intent and
articulate it in such ways so that it becomes actionable by an
Intent-Based System. Typically, those functions go beyond those
provided by a traditional API, although APIs may still be provided
(and needed for interactions beyond human users, i.e., with other
machines). Typically, there also would have a set of intuitive, easy
to navigate workflows that would guide the user throughout intent
consumption phase, also making sure that all the data nessesary for
Clemm, et al. Expires June 4, 2021 [Page 17]
Internet-Draft December 2020
intent modeling and consecutive translation has been gathered. They
may support unconventional human-machine interactions, in which a
human will not simply give simple commands but which may involve a
human-machine dialog to provide clarifications, to explain
ramifications and trade-offs, and to facilitate refinements.
The goal is ultimately to make Intent-Based Systems as easy and
natural to use and interact with as possible, in particular allowing
human users to interact with the IBS in ways that do not involve a
steep learning curve that forces the user to learn the "language" of
the system. Ideally, it will be the Intent-Based Systems that should
increasingly be able to learn how to understand the user as opposed
to the other way round. Of course, further research will be required
to make this a reality.
6.1.2. Intent Translation
A second set of functions needs to translate user intent into courses
of actions and requests to take against the network, which will be
meaningful to network configuration and provisioning systems. These
functions lie at the core of IBS, bridging the gap between
interaction with users on the one hand and the traditional management
and operations side that will need to orchestrate provisioning and
configuration across the network.
Beyond merely breaking down a higher layer of abstraction (intent)
into a lower layer of abstraction (policies, device configuration),
Intent Translation functions can be complemented with functions and
algorithms that perform optimizations and that are able to learn and
improve over time in order to result in the best outcomes,
specifically in cases where multiple ways of achieving those outcomes
are conceivable. For example, satisfying an intent may involve
computation of paths and other parameters that need will need to be
configured across the network. Heuristics and algorithms to do so
may evolve over time to optimize outcomes that may depend on a myriad
of dynamic network conditions and context.
6.1.3. Intent Orchestration
A third set of functions deals with the actual configuration and
provisioning steps that need to be orchestrated across the network
and that were determined by the previous intent translation step.
6.2. Intent Assurance