1. IETF/JTC1 Agreement on IS-IS protocol development zinin@psg.com

2. Problem statement zCurrent approach: yPublish as INFO y“submit” to ISO/IEC JTC1 zProblems: yWe are not putting specs of Internet-related mechanisms on the STD track yDerivative work cannot go STD either--ref problem yOther SDOs cannot cite our docs normatively yNo registry to manage the TLV namespace

3. Approach zBasis: yIETF is the place to STD’ize Internet-related stuff yISO/IEC JTC1 owns the protocol spec zNOT 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.” zFor others: yApply STD track procedure yPublish as INFO ySubmit to JTC1 fast track zAsk IANA to create and maintain an IS-IS registry zGive cooperation guidelines

4. Internet-specific IS-IS extensions zBased 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 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.) zDefinition: 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. 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.

6. Work Separation 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.... 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.... zInternet-specific extensions:

7. Work Separation (cont.) 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). 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). zOther extensions:

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

9. Discussion zOn-the-border cases zAdd some text on how IETF comments can be distributed within JTC1 zIETF -> JTC1 document mapping zProject editor for JTC1 submissions