Current Meeting Report
Jabber Logs

2.5.2 IS-IS for IP Internets (isis)

NOTE: This charter is a snapshot of the 55th IETF Meeting in Altanta, Georgia USA. It may now be out-of-date.

Last Modifield: 08/13/2002

Tony Li <>
Tony Przygienda <>
Routing Area Director(s):
Bill Fenner <>
Alex Zinin <>
Routing Area Advisor:
Alex Zinin <>
Mailing Lists:
General Discussion:
To Subscribe:
In Body: subscribe
Description of Working Group:
IS-IS is an IGP specified and standarized by ISO and incorporating extensions to support IP. It has been deployed successfully in the Internet for several years years. The IS-IS Working Group is chartered to document current protocol implementation practices and improvements, as well as to propose further extensions to be used within the scope of IS-IS and IP routing. Short term, the WG is expected to deliver a set of documents describing common implementation practices and extensions necessary to scale the protocol. These specifications will encourage multiple, inter-operable vendor implementations.

This working group will interact with other standards bodies that have responsibility for standardizing IS-IS.

Goals and Milestones:
DEC 98  Submit I-D on IETF recommendations for improvements to IS-IS
DEC 98  Submit I-D on IETF comments on the proposed second edition of IS-IS
DEC 98  Submit I-D on IS-IS Traffic Engineering Extensions
DEC 98  Submit I-D on IS-IS HMAC-MD5 Authentication
DEC 98  Submit I-D on IS-IS over IPv4
DEC 98  Submit I-D on Maintaining more than 255 adjacencies in IS-IS
DEC 98  Submit I-D on Optional Checksums on IIHs, CSNPs, and PSNPs in IS-IS
MAR 99  Submit I-D on IS-IS MIB
MAR 99  Submit IETF recommendations for improvements to IS-IS to IESG for publication as an Informational RFC.
MAR 99  Submit IS-IS Traffic Engineering Extensions to IESG for publication as an Informational RFC
MAR 99  Submit IS-IS HMAC-MD5 Authentication to IESG for publication as an Informational RFC
MAR 99  Submit Maintaining more than 255 adjacencies in IS-IS to IESG for publication as an Informational RFC
MAR 99  Submit IS-IS over IPv4 to IESG for publication as an Informational RFC
MAR 99  Submit Optional Checksums on IIHs, CSNPs, and PSNPs in IS-IS to IESG for publication as an Informational RFC
MAR 99  Review WG's priorities and future potential
JUL 99  Submit IS-IS MIB to IESG for consideration as a Proposed Standard.
  • - draft-ietf-isis-3way-06.txt
  • - draft-ietf-isis-wg-mib-09.txt
  • - draft-ietf-isis-wg-snp-checksum-03.txt
  • - draft-ietf-isis-hmac-03.txt
  • - draft-ietf-isis-traffic-04.txt
  • - draft-ietf-isis-ipv6-02.txt
  • - draft-ietf-isis-gmpls-extensions-13.txt
  • - draft-ietf-isis-wg-multi-topology-04.txt
  • - draft-ietf-isis-ext-eth-01.txt
  • - draft-ietf-isis-wg-tlv-codepoints-01.txt
  • - draft-ietf-isis-restart-01.txt
  • - draft-ietf-isis-ext-lsp-frags-01.txt
  • - draft-ietf-isis-interoperable-01.txt
  • - draft-ietf-isis-auto-encap-01.txt
  • - draft-ietf-isis-admin-tags-00.txt
  • Request For Comments:
    RFC1195 PS Use of OSI IS-IS for Routing in TCP/IP and Dual Environments
    RFC2763 I Dynamic Hostname Exchange Mechanism for IS-IS
    RFC2966 I Domain-wide Prefix Distribution with Two-Level IS-IS
    RFC2973 I IS-IS Mesh Groups
    RFC3277 I IS-IS Transient Blackhole Avoidance

    Current Meeting Report

    IS-IS WG Minutes - IETF 55, Atlanta GA
    November 19, 2002
    Chair: Tony Przygienda <>
    Recorder: Danny McPherson <>
    Milestones, Administrativia, Etc..
    Tony Przygienda <>
    3 RFCs Published:
    o Optional Checksums - 3358
    o TLV Codepoint List - 3359
    o 3-way Handshake - 3373
    Draft Status
    o MIB (-10) - will be ready for LC Dec 2002 ?
    o Cryptographic Authentication (-03) - AD COmments
    o GMPLS Extensions(-14) - AD COmments
    o TE Extensions (-04)- AD COmments
    o IPv6 (-03) - Last Call Dec '02
    o M-ISIS (-05) - Last Call Passed 11/11/02 o Extended Ethernet Frame (-01) - 
    AD Comments
    o Restart (-02) - Last Call Dec '02
    o P2P over LAN (-01) - Mar '03
    o 256+ Fragments (-02) - Waiting for Publication
    o Auto Encapsulation (-02) - Mar '03
    o Administrative Tags (-01) - Last Call Dec '02
    o Propietary TLVs (-00) - Last Call Dec '02
    o Interoperable IP Networks (-00) - LC Dec '02
    o Interoperable Networks (-00) - Last Call Dec '02
    +256 LSP Fragments
    Amir Hermelin <>
    o Pending issue o Comments since Yokohama have been integrated
    o In WG & AD/IESG Last Call
    o In RFC Editor
    o Document Issue:  Has normative reference to TE draft regarding sub-TLV 
    processing.  Until ISIS-TE draft is published this draft remains in queue 
    and won't be   published.
    Question:  Any suggestions?
    Amir Hermelin: If this draft doesn't progress because of  TE draft 
    progress then we need to find solution.
    AD/Alex Zinin: ADs will do everything possible to help  publish the draft 
    once new revision is completed.
    Christian Hopps:  v6 draft is on hold for same reason as well.
    Amir Hermelin: Need TE draft to progress.
    Multi-Topology Routing in ISIS (-05) Tony Przygienda 
    o Management color of sub-TLV gone
    o Genernic SPF and acording bit gone
    o Forwarding scenarios considerations added
    o Network management considerations added
    o Overload bit capability per MT added
    o MT #4 reserved for IPv6
    IETF/JTC1 Agreement on IS-IS Protocol Development
    AD/Alex Zinin <>
    Problem Statement:
    o Current Approach:
     - Publish as INFO
     - Submit to ISO/IEC JTC1
    o Problems:
     - We are not putting Internet-related mechanisms on STD track
     - Derivitive work cannot go STD either -- ref problem
     - Other SDOs can't cte our docs
     - No registry to manage TLV namespace
    Question to WG: Does anyone object that these are real problems?
    Kireeti Kompella: Managing TLVs, perhaps not, but STD issue is  problem for 
    lots of folks.
    Tony Przygienda: Concur with Kireeti.  Registry, secure a  solution.  
    Small number of implementing companies.  Information is more than 
    enough.  STD track just generates lots of work for standards weenies!  
    Doesn't need to be published, it's reality!
    Kireeti Kompella:  Let Alex Zinin do all the work and I'll be happy.  
    Interaction with JTC1 and we have the ability to make STD track and 
    reclassify RFCs great, otherwise, lots of reviews and more work is waste of 
    AD/Alex ZInin:  If we have rules then we can do this, but the WG can't 
    "reclassify", documents will have to be resubmitted to the STD process.
    Tony Przygienda:  Lots of work & time, irrelevant, and will hang there 
    until it expires.
    AD/Alex Zinin:  If WG agrees that it's a waste of time should  he talk to 
    JTC1 and try to do something useful?
    Tony Przygienda: It's useful if they want to cite our documents while they 
    remain INFO, otherwise, if they need to be STD forget it.  Lot of work.
    AD/Alex Zinin: Let them do the work.  Primary work is to get  stuff done, 
    this is getting WAY in the way of getting stuff  done.  Maybe you'll find 
    enough people to get the work done  but maybe not.
    Kireeti Kompella:  Current process as INFO still requires lots of 
    reviews.  However, we have this problem and it's reviewed as INFO but 
    treated like STD and now we're repeating the work.  If  workload can be 
    reduced in STD process but otherwise, forget it.
    Kireeti Kompella: Are other bodies interested in taking our 
    AD/Alex Zinin:  Submit means we're handing documents to them  and 
    serving as document editor.  Start fast-track process within JTC.  As far as 
    are they interested in our input, yes.  As far as getting the work done 
    themselves, he doubts.  First revision of submission of external class A 
    liasion submssion is in  original submission. Follwing submissions are 
    reformatted and  they handle it from there.
    AD/Alex Zinin:  Do we want to have responsibility?  Do we  want to have an 
    agreement with them or not?  Kireeti Kompella: It's black and white.  If you 
    have agreement but requires STD then we have to go back and work.  Don't 
    like that.
    AD/Alex Zinin: Goal of agreement is to give JTC1 ownsership of  spec but us 
    owning Internet-related technologies.  This  agreement does not create more 
    work than other WGs already have.  It creates more work than what we 
    currently have.
    Kireeti Kompella: It requires that we go back and redo things we've 
    already done.  INFO drafts have been treated like STD track and it's just 
    creeating more work.
    AD/Alex Zinin:  Can't make exception for IS-IS with real STD work,  else 
    Yakov or others will come and say "Why do I have to do this,  IS-IS 
    Back to Approach:
    o IETF is the Place for STD Internet-related stuff
    o ISO/IEC JTC1 owns the protocol spec
    o Not trying to take the protocol over
    o Define Internet-specific IS-IS Extensions
    [Other Stuff]
    - bunch of details o  IANA Create and maintain IS-IS registry
    Internet-specific IS-IS Extensions:
    o We specify based on the Core IS-IS definition
    - bunch of details  o We specify based Internet-specific Extensions
    - bunch of details o Defacto Implementation Agreements
    - bunch of details Work Separation: JTC1 will not standardize 
    Internet-specific stuff,
    Ask IANA to create and maintain an IS-IS registry  (until JTC creates 
    o On-the-border cases
    o Add some text on how IETF comments can be distributed   within JTC1 o 
    Need IETF -> JTC1 document mapping
    o Project editor for JTC1 submissions
     - In the loop of JTC1 process, can mostly take place in     email.
    AD/Alex Zinin:  Do we want this agreement or not?
    Tony Przygienda:  Then you need to Make a motion for each of  the 
    components, or do you want it to be made as a single  component.
    AD/Alex Zinin: Does the WG believe this agreement is useful?
    and should be progressed?
    Who is in favor?:
    [~15 hands in the audience are raised]
    Who is against?:
    [0 hands in the audience are raised]
    Meeting adjourned.


    ISOC/JTC1 agreement on IS-IS development