NETCONF WG
Download
1 / 9

NETCONF WG 66 th IETF Montreal, QC, Canada July 14, 2006 - PowerPoint PPT Presentation


  • 166 Views
  • Uploaded on

NETCONF WG 66 th IETF Montreal, QC, Canada July 14, 2006. NETCONF WG Details. Mailing List Discussion: [email protected] Subscribe: [email protected] ‘subscribe’ in the message body Archive: http://ops.ietf.org/lists/netconf/ WG Chairs Simon Leinen <[email protected]>

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'NETCONF WG 66 th IETF Montreal, QC, Canada July 14, 2006' - southern-olson


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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

NETCONF WG66th IETFMontreal, QC, CanadaJuly 14, 2006


Netconf wg details
NETCONF WG Details


Administrativia
Administrativia

  • Volunteers

    • Note takers for the minutes

    • Jabber scribe (please announce slide numbers)

    • Jabber proxy

  • Please use the microphones when asking questions


Interim meeting
Interim Meeting

  • Today (Friday 14 July) 1PM – 6PM

  • Tomorrow (Saturday 15 July) 9AM – 6PM

  • Hotel Delta Centre-Ville, St. Charles room


Submitted drafts
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.)?


Active drafts
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


Agenda
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


Requirements list 1 2
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]


Requirements list 2 2
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]


ad