1 / 9

IETF/JTC1 Agreement on IS-IS protocol development

IETF/JTC1 Agreement on IS-IS protocol development. zinin@psg.com. Problem statement. Current approach: Publish as INFO “submit” to ISO/IEC JTC1 Problems: We are not putting specs of Internet-related mechanisms on the STD track Derivative work cannot go STD either--ref problem

helenmsmith
Télécharger la présentation

IETF/JTC1 Agreement on IS-IS protocol development

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. IETF/JTC1 Agreement onIS-IS protocol development zinin@psg.com

  2. Problem statement • Current approach: • Publish as INFO • “submit” to ISO/IEC JTC1 • Problems: • We are not putting specs of Internet-related mechanisms on the STD track • Derivative work cannot go STD either--ref problem • Other SDOs cannot cite our docs normatively • No registry to manage the TLV namespace

  3. Approach • Basis: • IETF is the place to STD’ize Internet-related stuff • ISO/IEC JTC1 owns the protocol spec • NOT trying to take the protocol over • Define “Internet-specific IS-IS extensions” • “JTC1 SHALL NOT and IETF MAY (subject to the IETF standards process) standardize any Internet-specific IS-IS Extensions.” • For others: • Apply STD track procedure • Publish as INFO • Submit to JTC1 fast track • Ask IANA to create and maintain an IS-IS registry • Give cooperation guidelines

  4. Internet-specific IS-IS extensions • Based on the “Core IS-IS mechanisms” definition: 2.1 Core IS-IS Mechanisms Core IS-S Mechanisms are subsystems with associated algorithms, data structures, and PDU formats as specified in (ISO/IEC 10589), constituting the core of the IS-IS protocol and including the following elements: a) Framework of PDU formats, including defined TLVs b) Encapsulation of PDUs c) Adjacency state machine and formation logic d) DIS election algorithm e) Initial LSP synchronization via CSNP exchange f) Asynchronous LSP flooding (including DIS flooding behavior) g) LSP database maintenance including LSP origination, aging, and purging h) Defined topology abstraction

  5. Internet-specific IS-IS extensions (cont.) 2.2 Internet-specific IS-IS Extensions: Internet-specific IS-IS Extensions are extensions to the IS-IS proto- col that are within the work scope of the IETF including any routing or packet forwarding technology that the IETF decides to work on in future. (such as IPv4 or IPv6 unicast and multicast routing, MPLS, MPLS TE, GMPLS, or any other routing technology that the IETF decides to work on in future), and: a) do not modify the Core IS-IS Mechanisms and do not change operation of non-IP or affect compatibility with non-IP and dual implementations of IS-IS, or b) add supplementary mechanisms to the Core IS-IS Mechanisms, are not generally applicable to non-IP implementations of IS-IS, and do not change operation of non-IP or affect compatibility with non-IP and dual implementations of IS-IS, or c) are de facto implementation agreements that are not generally applicable to non-IP implementations of IS-IS. Note that in the text above introduction of new TLVs or sub-TLVs without modifying the algorithms of the Core Mechanisms in a way affecting interoperability with non-IP or dual implementations of IS- IS is not considered to be a modification to the Core IS-IS Mecha- nisms. • Definition:

  6. Work Separation • Internet-specific extensions: 3.1 Separation of IS-IS Work Scope JTC1 SHALL NOT and IETF MAY (subject to the IETF standards process) standardize any Internet-specific IS-IS Extensions. ...

  7. Work Separation (cont.) • Other extensions: 3.1 Separation of IS-IS Work Scope ... Any IS-IS Extensions produced within the IETF that require standard- ization, but cannot be identified as Internet-specific per section 2.2 of this document SHOULD be submitted for standardization to JTC1 (see section 3.3.2). IETF SHALL NOT publish documents describing such IS-IS extensions other than as Informational RFCs. IS-IS extensions submitted from the IETF to JTC1 will be processed under the JTC1 fast track procedure. To ensure the quality of such submissions, IETF SHALL apply to them the procedures for Proposed Standard submission according to [RFC2026] (even though these docu- ments will not be published as standards-track IETF RFCs).

  8. Registries • Ask IANA to create an IS-IS registry (until JTC1 have their own) • IETF has the right to ask IANA to maintain permanent registries for Internet-specific things (such as TE sub-TLVs)

  9. Discussion • On-the-border cases • Add some text on how IETF comments can be distributed within JTC1 • IETF -> JTC1 document mapping • Project editor for JTC1 submissions

More Related