1 / 9

NETCONF WG 66 th IETF Montreal, QC, Canada July 14, 2006

NETCONF WG 66 th IETF Montreal, QC, Canada July 14, 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>

southern-olson
Download Presentation

NETCONF WG 66 th IETF Montreal, QC, Canada July 14, 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 WG66th IETFMontreal, QC, CanadaJuly 14, 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. Administrativia • Volunteers • Note takers for the minutes • Jabber scribe (please announce slide numbers) • Jabber proxy • Please use the microphones when asking questions

  4. Interim Meeting • Today (Friday 14 July) 1PM – 6PM • Tomorrow (Saturday 15 July) 9AM – 6PM • Hotel Delta Centre-Ville, St. Charles room

  5. Submitted Drafts • Four drafts are in the RFC Editor Queue • Port numbers have been assigned • 830 netconf-ssh • 831 netconf-beep • 832 netconfsoaphttp • 833 netconfsoapbeep • Further IANA actions required(capabilities registry, XML namespace etc.)?

  6. Active Drafts • WG Draft: • NETCONF Event Notificationsdraft-ietf-netconf-notification-02.txt • Individual Submissions: • A SYSLOG Capability for NETCONFdraft-shafer-netconf-syslog-00.txt • Netconf System Architecturedraft-atarashi-netconfmodel-architecture-03.txt • Framework for Netconf Contentdraft-chisholm-netconf-model-05.txt

  7. Agenda • Agenda bashing (5') • Netconf System Architecture (B) (10') • Framework for Netconf Content (D) (10') • A SYSLOG Capability for NETCONF (C) (40') • NETCONF Event Notifications (A) (40') • NETCONF Notifications: Functional Requirements (45') • determine WG consensus on need and priority of requirements on Juergen's list:http://www.eecs.iu-bremen.de/wiki/index.php/Netconf_notifications

  8. Requirements list (1/2) • solution should focus on notification support for configuration [AB] • solution should support structured hierarchical data [BL, SC] • solution should be able to carry configuration fragments [?] • solution should support a reasonable message size limit (syslog and SNMP are rather constrained in terms of message sizes) [BL] • solution should provide reliable delivery of notifications [BL] • solution should support preconfigured notification destinations [AB] • solution should support agent initiated connections [KW] • solution should provide a subscription mechanism [HT] • solution should support multiple subscriptions [RP] • solution should provide a filtering mechanism [HT] • solution should support notification names [BL] • solution should support notification timestamps [BL]

  9. Requirements list (2/2) • solution should support notification classes [SC] • solution should support notification info [BL] • solution should provide the ability to specify the content of notifications to ensure predictability [SC] • solution should send sufficient information in a notification so that it can be analyzed independent of the transport mechanism [AB] • solution should allow notifications to refer to prior configuration change RPCs • solution should not bind subscriptions to a connection [RP] • channels for configuration change notifications should share fate with a session that includes a configuration channel [DP] • solution should support replay of locally logged notifications [KW] • solution should support message chunking capability in cases channels carry mixed RPCs [KW] • solution should scale to 30.000-100.000 nodes which may emit notifications [BL] • solution should scale to order 30.000-100.000 nodes to send notifications [BL]

More Related