1. Network Configuration Prepared by: Menna Hamza Mohamad Hesham Mona Abdel Mageed Yasmine Shaker

2. Agenda • OPS • NetConfig Work Group • NetConfig Protocol • XML Detour • Definitions • Protocol Layers • Protocol Main Scenario • Basic Operations • Filters • Demo • Partial Lock RPC • With Default Capability • TLS

3. operations and management area • Area Workgroups Examples: • CAPWAP : Control And Provisioning of Wireless Access Points. • BMWG: Benchmarking Methodology • DIME : Diameter Maintenance and Extensions • NETCONF : Network Configuration

4. netconf working group • The NETCONF Working Group is chartered to produce a protocol suitable for network configuration. • required characteristics includes: • Differentiate between configuration data and non-configuration data. • Extensible. • Integration with user authentication methods. • Integration with configuration database systems. • Wide configuration transactions with features such as locking and rollback capability.

5. NetConfig Protocol • The protocol provides mechanism to transfer and manipulate configuration data in a network device • It uses an Extensible Markup Language (XML)-based data encoding for the configuration data and the protocol messages. • The NETCONF protocol operations are realized on top of a simple Remote Procedure Call (RPC) layer.

6. Agenda • OPS • NetConfig Work Group • NetConfig Protocol • XML Detour • Definitions • Protocol Layers • Protocol Main Scenario • Basic Operations • Filters • Example • Partial Lock RPC • With Default Capability • TLS

7. XML Detour • XML • Why XML? • XSD and Schemas • Xpath • XML Node • XML Sub Tree • Example

8. XML Example Value of Xpath (top/users/user/name) <top xmlns="http://example.com/schema/1.2/config"> <users> <user> <name>root</name> <type>superuser</type> <full-name>Charlie Root</full-name> <company-info> <dept>1</dept> <id>1</id> </company-info> </user> </users> </top>

9. Definitions • Application / client / Manager • Server / Device / Agent • Data Store / Configuration file • Capabilities

10. Agenda • OPS • NetConfig Work Group • NetConfig Protocol • XML Detour • Definitions • Protocol Layers • Protocol Main Scenario • Basic Operations • Filters • Demo • Partial Lock RPC • With Default Capability • TLS

11. Protocol Layers

12. <Hello> • A way for both client and server to announce there existence • It also serves as an announcement of session ID as well as supported features !!! • Extendible protocol means that there is no guarantee that the server and client support the same set features. • Base capability must be supported • How to handle different set of features?

13. Serve Me • The client uses the needed advertised capabilities to send requests to the Server. • The Server processes the requests on a FIFO basis (Pipeline) • The Server sends Required Data/ request status to the client • How to associate a request with a reply? ID • Client closes the session or Server terminates session due to timeout

14. RPC For Life • Client Requests are RPC calls • The data store is conceptually a list of XML namespaces • The RPC manipulates these XML namespaces • Changes to the XML name spaces are mapped by the device to actual changes in it’s internal configuration (registers, etc..) • Server reply contains requested XML data, errors, warnings and optionally execution success feedback

15. Agenda • OPS • NetConfig Work Group • NetConfig Protocol • XML Detour • Definitions • Protocol Layers • Protocol Main Scenario • Basic Operations • Filters • Demo • Partial Lock RPC • With Default Capability • TLS

16. Basic Operations • Get • get • get-config • Manipulate • edit-config • copy-config • delete-config • Parallel access control • Lock • unlock • End session • close-session • kill-session

17. RPC blocks • <rpc> • <rpc-reply> • <rpc-error> • </ok> • <data>

18. Filters • What’s a filter • Using a filter • <filter>

19. Demo

20. <rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <get-config> <source> <running/> </source> <filter type="subtree"> <top xmlns="http://example.com/schema/1.2/config"> <users> <user> <name>root</name> </user> </users> </top> </filter> </get-config> </rpc>

21. <rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <data> <top xmlns="http://example.com/schema/1.2/config"> <users> <user> <name>root</name> <type>superuser</type> <full-name>Charlie Root</full-name> <company-info> <dept>1</dept> <id>1</id> </company-info> </user> </users> </top> </data> </rpc-reply>

22. Extended Capabilities Case Study • Partial lock • With default Capabilities

23. Agenda • OPS • NetConfig Work Group • NetConfig Protocol • XML Detour • Definitions • Protocol Layers • Protocol Main Scenario • Basic Operations • Filters • Example • Partial Lock RPC • With Default Capability • TLS

24. Partial Lock RPC • Describes the lock and unlock operations on parts of configuration data stores using XPath filtering mechanisms • Definition of Terms • Scope of the lock • Protected area

25. Partial Locking Capability • Usage Scenarios • Multiple managers with overlapping sections • Multiple managers, distinct management areas • New Operations • <partial-lock> • <partial-unlock>

26. <partial-lock> • Locking a node protects the node itself and the complete sub-tree under the node • The XPath expressions are evaluated only once at lock time • NETCONF server that supports partial locking MUST be able to grant multiple simultaneous partial locks to a single NETCONF session • Failure • Global lock • Already locked • User does not have access rights

27. RPC • Parameters • Filter (Lock) • ID (Unlock) • Deadlock Avoidance • RPC Reply • Positive (Lock ID in case of lock) • Negative

28. Agenda • OPS • NetConfig Work Group • NetConfig Protocol • XML Detour • Definitions • Protocol Layers • Protocol Main Scenario • Basic Operations • Filters • Demo • Partial Lock RPC • With Default Capability • TLS

29. With default capability • part of the configuration data is not set by the NETCONF client, but rather a default value is used. • Some times NETCONF client has a prior knowledge about this default data, so the NETCONF server does not need to send it to the client. • In other situations the NETCONF client will need this data so it must be sent at the NETCONF <rpc-reply> messages. • A new XML child element added to the method-name element.

30. Reporting modes • report-all: • All default data is always reported. • trim: • Values are not reported if they match the default. • explicit: • Default data is not reported except explicitly set default data.

31. Agenda • OPS • NetConfig Work Group • NetConfig Protocol • XML Detour • Definitions • Protocol Layers • Protocol Main Scenario • Basic Operations • Filters • Demo • Partial Lock RPC • With Default Capability • TLS

32. NETCONF over TLS • Configuration exchange must be secure. • TLS provide support for certificate-based mutual authentication. • TLS is application-protocol-independent. • How NETCONF can be used within a TLS session?

33. NETCONF over TLS • Connection Initiation Client Hello message Handshake Start Exchange XML • Connection Closure Manager (NETCONF) Client (TLS ) Agent (NETCONF) Server (TLS)

34. NETCONF over TLS • Endpoint Authentication and Identification • Server Identity • The server hostname • Matching is case-insensitive. • A "*" wildcard character. • multiple names is acceptable. • Client Identity

35. Agenda • OPS • NetConfig Work Group • NetConfig Protocol • XML Detour • Definitions • Protocol Layers • Protocol Main Scenario • Basic Operations • Filters • Demo • Partial Lock RPC • With Default Capability • TLS

36. Questions!