1 / 15

NETCONF WG 65 th IETF Dallas, TX USA March 20, 2006

NETCONF WG 65 th IETF Dallas, TX USA March 20, 2006. NETCONF WG Details. Mailing List Discussion: netconf@ops.ietf.org Subscribe: netconf-request@ops.ietf.org ‘subscribe’ in the message body Archive: http://ops.ietf.org/lists/netconf/ WG Chairs Simon Leinen <simon@switch.ch>

cwing
Download Presentation

NETCONF WG 65 th IETF Dallas, TX USA March 20, 2006

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. NETCONF WG65th IETFDallas, TX USAMarch 20, 2006

  2. NETCONF WG Details • Mailing List • Discussion: netconf@ops.ietf.org • Subscribe: netconf-request@ops.ietf.org • ‘subscribe’ in the message body • Archive: http://ops.ietf.org/lists/netconf/ • WG Chairs • Simon Leinen <simon@switch.ch> • Andy Bierman <ietf@andybierman.com> • WG Charter Page • http://www.ietf.org/html.charters/netconf-charter.html • WG Home Page • http://www.ops.ietf.org/netconf/

  3. NETCONF Drafts • Completed Work • NETCONF Configuration Protocoldraft-ietf-netconf-prot-12.txt • Using the NETCONF Protocol Over SSHdraft-ietf-netconf-ssh-06.txt • Using the NETCONF Protocol Over BEEPdraft-ietf-netconf-beep-10.txt • Using the NETCONF Protocol Over SOAPdraft-ietf-netconf-soap-08.txt • Current Work • NETCONF Event Notificationsdraft-ietf-netconf-notification-00.txt

  4. NETCONF WG Agenda • Status of Completed WG Documents (10 min) • NETCONF Experimental Namespace and Extension Registry (15 min) • Discuss need/interest in an experimental "branch" for NETCONF protocol extensions. • NETCONF Implementation Guide (15 min) • Discuss need/interest in an Informational RFC to help NETCONF protocol developers produce interoperable implementations • NETCONF Event Notifications (90 min) • Discuss current Notifications draft • Identify areas of WG consensus (or lack thereof) • Identify all open issues • Open Discussion / Unchartered Items (20 min) • NETCONF Data Modeling • Access Control Model • ???

  5. Administrivia • Agenda bashing • Volunteers • Note takers for the minutes • Jabber scribe • Jabber proxy • Please use the microphones when asking questions • Speakers, please announce slide changes (for the benefit of remote attendees)

  6. Completed Work Status • NETCONF “Version 1” ready for approval by the IESG • NETCONF Configuration Protocoldraft-ietf-netconf-prot-12.txt • Using the NETCONF Protocol Over SSHdraft-ietf-netconf-ssh-06.txt • Using the NETCONF Protocol Over BEEPdraft-ietf-netconf-beep-10.txt • Using the NETCONF Protocol Over SOAPdraft-ietf-netconf-soap-08.txt • IANA Port Assignment issue is the last detail remaining to be resolved

  7. NETCONF Experimental • The NETCONF ‘base’ namespace and capability registry requires standards action for modification • Another namespace would be needed for non-standards track extensions, even if added by this WG • This is an IESG concern, which needs to be addressed • A separate IANA registry for URNs identifying experimental NETCONF protocol extensions is proposed: • urn:ietf:params:netconf:experiment:<exp-name>:<exp-version> • urn:ietf:params:netconf:experiment:batch:1.0 • Provides a freely available, centralized source of NETCONF extension and experiment information • Help promote interoperability of NETCONF extensions • Details: • First-come, first-serve naming rights • Required Documentation: Capability template (may need new Experiment template)

  8. NETCONF Implementation Guide • Purpose: • Help new NETCONF protocol developers more easily create inter-operable implementations • Examples: • RFC 2683 - IMAP4 Implementation Recommendations • IPFIX Implementation Guidelines draft-boschi-ipfix-implementation-guidelines-01.txt • An Implementation Guide for RTP MIDIdraft-ietf-avt-rtp-midi-guidelines-15.txt • Phase 1: • Collect implementation experience, advice, pitfalls, etc. • Phase 2: • Publish Informational RFC

  9. NETCONF Event Notifications • Document: • draft-ietf-netconf-notification-00.txt • Issue Areas • Notification Architecture • Configurability • Notification Message Definition • Event Classes • Transport Details • Security • Normative Data Model for monitoring • Non-normative extensions • Examples within normative text • XSD

  10. NETCONF Notification Architecture • Shared session vs. dedicated session • Best current practice does not send notifications to the same port number (or same connection) as operations • How important is the ability to intermix RPC operations and notifications in the same session? • Overlay notification model on RPC model or create a separate model for Notifications? Content Operations Content RPC Notification Transport Transport RPC Model Notification Model

  11. Notification Architecture (cont.) • One-Way RPC vs. Plain Notification • Should this extra layer be in the architecture and PDU? • Subscription vs. Long-lived RPC Model • Given: Manager sends an RPC to start receiving notifications • For dedicated sessions, a long-lived RPC is a simple approach that is already defined • Agent sends <rpc-reply>, then <notification> elements as needed, but never sends the closing </rpc-reply> element • If the ‘start-notifications’ RPC cannot be completed, the usual <rpc-reply> with an <rpc-error> is sent instead • Manager terminates the session to stop receiving notifications • Is the Modify subscription operation really needed? • Manager could start up a new notification session with the new desired parameters, then shutdown the old notification session to avoid missing any notifications

  12. Notification Configurability • 3 Combined Filter Configuration Methods • By Event Classes • encoded as empty elements like <state/> • By Content Filter (subtree or XPath) • By Named Profile • a string that names a non-volatile configuration of unspecified content • Another filtering approach: • Event Class string + optional Event Sub-class element • Each class can define the structure of its own sub-class element, typically a string • Need for modify-subscription RPC not clear • Need for multiple subscriptions per session not clear

  13. Notification Message • Current definition example (w/o namespace junk)<one-way-rpc message-id=“101”> <notification> <subscription-id>123456</subscription-id> <event-classes><fault/><configuration/></event-classes> <sequence-number>7</sequence-number> <date-time>2006-03-20T09:14:00Z</date-time> <data> ….. </data> </notification></one-way-rpc> • Taken from XSD; doc. examples do not follow the XSD • Why do we need to include multiple event-classes in one notification? Do we need to allow a single event type to be given multiple event-class classifications?

  14. Event Classes • Pre-determined feature set defined by the event classes:

  15. Other Notification Issues • Additional Incomplete or Controversial sections • Transport Specific Details • Security Considerations (empty section) • Normative Data Model for monitoring • Doesn’t follow container model in Framework • Should this be mandatory or even included in this document? • Non-normative extensions • Appendix A: Potential Event Content • Appendix B: Configuration Event Class Notifications • Appendix C: NETCONF Event Notifications and Syslog • Examples within normative text do not match XSD • XSD complicated and contains some errors

More Related