Network Intent concepts draft-moulchan-nmrg-network-intent-concepts-00 Kaarthik Sivakumar Mouli Chandramouli Cisco Systems

Objectives Definitions of Network Intent Differentiate Network Policy, Network Configuration A proposal for realizing Network Intent Some use cases Next steps of Research

First, several efforts on this topic Network Intent First, several efforts on this topic “Autonomic” network intent – distributed policy Domain Specific Language based approaches – NEMO , Promise theory Implementations often imply Intent = Network configuration Please see section 7.8.1 from RFC 2578 (SMIv2) on this issue: 7.8.1.  Relation between INDEX and AUGMENTS clauses     When defining instance identification information for a conceptual     table:     (1)  If there is a one-to-one correspondence between the conceptual rows     of this table and an existing table, then the AUGMENTS clause     should be used. I know this text, and read the above. Hence I concluded on AUGMENTS. However, I missed the "sparse" aspect of the following paragraph.     (2)  Otherwise, if there is a sparse relationship between the conceptual     rows of this table and an existing table, then an INDEX clause     should be used which is identical to that in the existing table.     For example, the relationship between RFC 2233's ifTable and a     media-specific MIB which extends the ifTable for a specific media     (e.g., the dot3Table in RFC 2358), is a sparse relationship.

Network Intent – Architecture Definition Network Administrator articulates a desired / expected outcome from the network Multiple approaches to realize Network Intent Can lead to conflicts with the state of the network or conflicts with previous intents Confusion with Network Policy, Service Models, Network Configuration Please see section 7.8.1 from RFC 2578 (SMIv2) on this issue: 7.8.1.  Relation between INDEX and AUGMENTS clauses     When defining instance identification information for a conceptual     table:     (1)  If there is a one-to-one correspondence between the conceptual rows     of this table and an existing table, then the AUGMENTS clause     should be used. I know this text, and read the above. Hence I concluded on AUGMENTS. However, I missed the "sparse" aspect of the following paragraph.     (2)  Otherwise, if there is a sparse relationship between the conceptual     rows of this table and an existing table, then an INDEX clause     should be used which is identical to that in the existing table.     For example, the relationship between RFC 2233's ifTable and a     media-specific MIB which extends the ifTable for a specific media     (e.g., the dot3Table in RFC 2358), is a sparse relationship.

Network Intent – Architecture User Intent API SDN Controller Intent Engine Instruct network Device 1 Device 2 Device 3 Please see section 7.8.1 from RFC 2578 (SMIv2) on this issue: 7.8.1.  Relation between INDEX and AUGMENTS clauses     When defining instance identification information for a conceptual     table:     (1)  If there is a one-to-one correspondence between the conceptual rows     of this table and an existing table, then the AUGMENTS clause     should be used. I know this text, and read the above. Hence I concluded on AUGMENTS. However, I missed the "sparse" aspect of the following paragraph.     (2)  Otherwise, if there is a sparse relationship between the conceptual     rows of this table and an existing table, then an INDEX clause     should be used which is identical to that in the existing table.     For example, the relationship between RFC 2233's ifTable and a     media-specific MIB which extends the ifTable for a specific media     (e.g., the dot3Table in RFC 2358), is a sparse relationship.

Network Intent – Use cases Place a video call from User A to User B What are congested links in the network ? Please see section 7.8.1 from RFC 2578 (SMIv2) on this issue: 7.8.1.  Relation between INDEX and AUGMENTS clauses     When defining instance identification information for a conceptual     table:     (1)  If there is a one-to-one correspondence between the conceptual rows     of this table and an existing table, then the AUGMENTS clause     should be used. I know this text, and read the above. Hence I concluded on AUGMENTS. However, I missed the "sparse" aspect of the following paragraph.     (2)  Otherwise, if there is a sparse relationship between the conceptual     rows of this table and an existing table, then an INDEX clause     should be used which is identical to that in the existing table.     For example, the relationship between RFC 2233's ifTable and a     media-specific MIB which extends the ifTable for a specific media     (e.g., the dot3Table in RFC 2358), is a sparse relationship.

Network Intent – Next steps Problem definition stage Solution approach in research Multiple approaches are pursued Autonomic based techniques DSL based techniques We are considering Natural Language Processing, ML and AI Suggestions/Collaborations welcome