2.5.5 IS-IS for IP Internets (isis)

NOTE: This charter is a snapshot of the 60th IETF Meeting in San Diego, CA USA. It may now be out-of-date.

Last Modified: 2004-07-23

Chris Hopps <chopps@rawdofmt.org>
David Ward <dward@cisco.com>
Routing Area Director(s):
Bill Fenner <fenner@research.att.com>
Alex Zinin <zinin@psg.com>
Routing Area Advisor:
Alex Zinin <zinin@psg.com>
Mailing Lists:
General Discussion: isis-wg@ietf.org
To Subscribe: isis-wg-request@ietf.org
In Body: subscribe
Archive: http://www.ietf.org/mail-archive/web/isis-wg/index.html
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.

The status of the WG documents maintained by the WG chairs can be found at http://skat.usc.edu/~tli/Schedule.htm.

Goals and Milestones:
Done  Submit I-D on IS-IS Traffic Engineering Extensions
Done  Submit I-D on IS-IS HMAC-MD5 Authentication
Done  Submit I-D on Maintaining more than 255 adjacencies in IS-IS
Done  Submit I-D on Optional Checksums on IIHs, CSNPs, and PSNPs in IS-IS
Done  Submit I-D on IS-IS MIB
Done  Submit IS-IS Traffic Engineering Extensions to IESG for publication as an Informational RFC
Done  Submit IS-IS HMAC-MD5 Authentication to IESG for publication as an Informational RFC
Done  Submit Maintaining more than 255 adjacencies in IS-IS to IESG for publication as an Informational RFC
Done  Submit Optional Checksums on IIHs, CSNPs, and PSNPs in IS-IS to IESG for publication as an Informational RFC
Done  Submit IPv6 to IESG for publication as an Informational RFC
Done  Submit M-ISIS to IESG for publication as an Informational RFC
Done  Submit 256+ Fragments to IESG for publication as an Informational RFC
Done  Submit Administrative Tags to IESG for publication as an Informational RFC
Done  Submit Interoperable IP Networks to IESG for publication as an Informational RFC
Done  Submit Interoperable Networks to IESG for publication as an Informational RFC
Done  Submit P2P over LAN to IESG for publication as an Informational RFC
Done  Submit Gracefull Restart to IESG for publication as an Informational RFC
Jun 03  Submit Automatic Encapsulation to IESG for publication as an Informational RFC
Jun 03  Review WG's priorities and future potential
Sep 04  Submit Experimental TLVs to IESG for publication as an Informational RFC
Sep 04  Submit IS-IS MIB to IESG for consideration as a Proposed Standard.
  • - draft-ietf-isis-wg-mib-16.txt
  • - draft-ietf-isis-gmpls-extensions-19.txt
  • - draft-ietf-isis-wg-multi-topology-07.txt
  • - draft-ietf-isis-igp-p2p-over-lan-05.txt
  • - draft-ietf-isis-admin-tags-02.txt
  • - draft-ietf-isis-experimental-tlv-03.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
    RFC3358 I Optional Checksums in ISIS
    RFC3359 I Reserved TLV Codepoints in ISIS
    RFC3373 I Three-Way Handshake for IS-IS Point-to-Point Adjacencies
    RFC3567 I Intermediate System to Intermediate System (IS-IS)Cryptographic Authentication
    RFC3719 I Recommendations for Interoperable Networks using IS-IS
    RFC3786 I Extending the Number of IS-IS LSP Fragments Beyond the 256 Limit
    RFC3787 I Recommendations for Interoperable IP Networks using IS-IS
    RFC3784 I IS-IS extensions for Traffic Engineering
    RFC3847 I Restart signaling for IS-IS

    Current Meeting Report


    - ITU Liaison Statement Jonathan Sadler
    No Comments.

    - draft-ietf-isis-wg-mib-16.txt
    Removes multiple instances (MIB)

    Q: Why ?
    . not likely to be used unless in VPN context (done for VPN)
    . multiple instances will be supported in latest OSPF draft

    - draft-ietf-isis-experimental-tlv-03.txt presnted by Christian Hopps
    Dave: consensus to go to enterprise code

    - draft-ietf-isis-admin-tags-03.txt Stefano Previdi <sprevidi@cisco.com>
    use of colouring in specific context (leaking for loo for MPLS VPN, fast convergence (route priority), ...)
    map BGP extended community => two different TLVs
    implementation, deployed
    WG document ?

    Acee: applications ?
    Stef: route distribution between levels, prioritize routes for ISIS (populating the RIB).
    Naiming: plan for IPv6 prefix ?
    Stef: no plan (IPv4 only). Will be done for IPv6

    - draft-ietf-isis-igp-p2p-over-lan-04.txt Naiming Shen <naiming@redback.com>
    No significant changes, IESG comments incorporated
    Clarification done (unnumbered interfaces: remove the proxy-ARP ... )
    Text added for IPv6, ND and OSPFv3

    Chris: has been last called, just couple of comments form IESG
    ... Objection ?
    Floor: no

    - draft-ietf-isis-wg-multi-topology-07.txt Naiming Shen <naiming@redback.com>
    no major changes
    went trough LS and SD review once
    rev 06 -> rev -07
    implemented by 3 vendors (Multicast Mutitopology and IPv6)

    Chris: which has been deployed rev 06 or rev -07
    Naiming: ???? Old version (I guess)
    Chris: should issue a last call again since implementations are based on rev -06

    - draft-shen-isis-interarea-route-attr-00.txt Naiming Shen

    Q: why use router-id of the next-hop frr
    A: router-id is not bundled to any interface it will allow more flexibility/stability. router may have multiple router-id

    Igor: is there any confidentiality issue in propagating the next-hop address into the level?
    Naiming: applications not entirely identified ... just a way to identify the NHOP's ABR

    Dave: go to the list before accepting as a WG document
    RTG WG needs first to conclude the FRR
    3 drafts to color things ... becomes challenging
    Naiming: not limited
    Dave: need to clarify the application ... take to the list

    - draft-shen-isis-extended-tlv-00.txt Naiming Shen <naiming@redback.com>

    Chris: What problem are you trying to solve?
    Naiming: problem is not present now
    Chris: why don't we wait the problem first
    alex: there's about 70 years left for code points...
    Dimitri/Alex: TLV code is not the pb but the size of TLV
    Naiming: lots of info for GMPLS TLV for instance ... could be big
    Alex: possibility of backward compatible way ? ... TLV parsing error from non compatible ?
    Naiming: no they can skip the TLV
    Naiming: length no right ???Lenght (hi) = 0 ... so no interop issue
    Alex: will check the draft

    - draft-harrison-isis-ipv6-te-00.txt Jon Berger
    limited amount of people had read the draft

    Adrian: suggest input from CCAMP

    - draft-vasseur-isis-caps-00.txt Jean Philippe Vasseur <jvasseur@cisco.com>
    merge of vasseur-iusis and raggarwa-isis drafts
    removed all management capabilities
    new capability tlv starting with router-id + flags + subTLVs
    propagation procedures/ interoperability requirements for capability tlv
    no issues
    wg doc ?

    Chris: decide on list.

    - draft-vasseur-isis-te-caps-00.txt Jean Philippe Vasseur

    Dave: send the conclusion of the PCE BOF to the list

    - draft-vasseur-isis-link-attr-01.txt Stefano Previdi <sprevidi@cisco.com>

    Alia: like the idea of link sub-TLV, may not apply to IPFRR

    FYI session - pointer providing about the BOF
    Goal: glue links together to appear to be a single LAN to IP nodes Spanning tree does not prevent temporary loops, suboptimal IP routes to link, not end nodes ...
    Keep transparency to end node with 0 config (Bridge) with best path and no temporary loops (IP).
    Idea: link state protocol between RBridges + mechanism

    Tony Li:
    Status after the BOF: no technical compliant ... no real conclusion
    Radia: should it be in IEEE ?
    Dave: interest from ISIS WG ? Need for a new protocol or need to extend Link State

    RFC1195 + Domain + Extension for TE + IP interoprable: interest in creating a new doc related to IS-IS IP routing

    Tony Li: any change ?
    Chris: no, just merged draft, part of standard track, take to the list,
    Suresh: what is the goal ? Should it apply to IPv6 as well (TE for instance)
    Chis: all of them are IPv4 .... Not known for IPv6 More convenient to have a single document, that's all.
    Alex: question for the WG: better to have one unified spec for implementors?
    Henke Shenk: why not proceed each one individually as standard track
    Acee: emotional issue of obsleting doc that people did ...
    Henke Shenk: why does this question come up ? Does not make sense
    Chris: IP interop is a delta document, compilcates finding information.
    John: let them separate
    Dave: to the list ....


    New RFCs
    ITU Liaison IS-IS for IP Standardization Request
    ISIS Route Tag sub-TLV
    P2P-Over-LAN Draft Update
    IS-IS MT Draft Update
    Inter-Area Route Attribute
    IS-IS Extended TLV
    Definition of an IS-IS Link Attribute sub-TLV
    Rbridges: Transparent Routing
    New Std Track Doc?