2.5.4 IS-IS for IP Internets (isis)

Last Modified: 2003-05-19

Chair(s):
Tony Li <tli@procket.com>
Tony Przygienda <prz@xebeo.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: ftp://ftp.ietf.org/ietf-mail-archive/isis-wg
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
Jun 03  Submit Experimental TLVs to IESG for publication as an Informational RFC
Jun 03  Submit IS-IS MIB to IESG for consideration as a Proposed Standard.
Jun 03  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
Internet-Drafts:
  • - draft-ietf-isis-wg-mib-12.txt
  • - draft-ietf-isis-traffic-05.txt
  • - draft-ietf-isis-ipv6-05.txt
  • - draft-ietf-isis-gmpls-extensions-16.txt
  • - draft-ietf-isis-wg-multi-topology-06.txt
  • - draft-ietf-isis-ext-eth-01.txt
  • - draft-ietf-isis-restart-04.txt
  • - draft-ietf-isis-igp-p2p-over-lan-02.txt
  • - draft-ietf-isis-ext-lsp-frags-02.txt
  • - draft-ietf-isis-auto-encap-03.txt
  • - draft-ietf-isis-proprietary-tlv-00.txt
  • - draft-ietf-isis-ip-interoperable-00.txt
  • - draft-ietf-isis-iso-interoperable-00.txt
  • - draft-ietf-isis-experimental-tlv-00.txt
  • Request For Comments:
    Use of OSI IS-IS for Routing in TCP/IP and Dual Environments (RFC 1195) (187866 bytes)
    Dynamic Hostname Exchange Mechanism for IS-IS (RFC 2763) (8593 bytes)
    Domain-wide Prefix Distribution with Two-Level IS-IS (RFC 2966) (32465 bytes)
    IS-IS Mesh Groups (RFC 2973) (14846 bytes)
    IS-IS Transient Blackhole Avoidance (RFC 3277) (13077 bytes)
    Optional Checksums in ISIS (RFC 3358) (8266 bytes)
    Reserved TLV Codepoints in ISIS (RFC 3359) (7843 bytes)
    Three-Way Handshake for IS-IS Point-to-Point Adjacencies (RFC 3373) (19522 bytes)
    Intermediate System to Intermediate System (IS-IS)Cryptographic Authentication (RFC 3567) (13467 bytes)

    Current Meeting Report

    ISIS WG Minutes
    
    
    - Agenda
     Draft Status
     Capabilities 
    
    
    - Draft Status:  Tony P. gave the draft status and summarized the 
    discussion from the mailing list. 
    MIB                            (12)            Ready for Last Call ?
    Cryptographic Authentication   (05)            Editors Queue
    GMPLS Extensions               (16)            Waiting for AD Comments
    TE Extensions                  (04)            AD Comments
    IPv6                           (05)            Waiting for AD Comments
    M-ISIS                         (06)            Was discussed again, AD
    Extended Ether Frame           (01)            Abandoned
    Restart                        (03)            LC Passed, Mailing List
    P2P over LAN                   (01)            External Party
    256+ Fragments                 (02)            Editors Queue
    Automatic Encapsulation        (02)            Under Discussion
    Administrative Tags            (01)            Mailing List, Expired
    Experimental TLVs              (00)            Ready for LC now ?
    Interoperable IP Networks      (00)            AD Comments
    Interoperable Networks         (00)            AD Comments
    
    
    Three-Way Handshake            RFC 3373        Published
    
    
    
    No comments from the audience.
    
    
    - Optional Router Capabilities (Naiming Shen)
    
    
    Follow up to Yokohoma discussion. That document has been split into an OSPF 
    and ISIS only documents.
    
    
    Draft proposes a new TLV to encode a router's capabilities. It is useful to 
    encode this information for troubleshooting, figure out misconfigs and also 
    to signal certain services, path computation server, location, etc.
    
    
    The TLV has its own encoding of the router id. An L1/L2 router verbatim 
    copies these TLV's in its L1 area into its own L2 LSP. The flooding of 
    these TLVs are controlled by using the following bits:
         F bit: flood to the whole domain
         T bit: to signal an external application
         Up/Down bit: to stop looping (see route leaking).
    
    
    The capabilities themselves are encoded as sub-tlv's.
    
    
    Paranta(sp?) from MCI: He is worried that the verbatim copying of these 
    tlv's can spread effect of buggy routers in one L1 area into the whole 
    domain. He would prefer if the L1/L2 router would first interpret these 
    TLV's and later rewrote them, similar to route leaking.
    
    
    Kireetee: He wanted to know how the ambiguity is resolved if two L1/L2 
    routers were to summarize these TLVs differently. Or if the origin router 
    was to incosistently send multiple of these tlvs. Naiming said you should 
    pick the one you heard last, or you can adopt another scheme which is 
    deterministic (e.g. of closest/farthest router to you based on metric). You 
    can check for errors, length, etc, before making it your own lsp.
    
    
    Kireeti requested to make the length in bytes.
    
    
    Tony P. said 1. we cant do anything about faulty 
    implementations. Tony favors copying verbatim, and thinks it might be 
    buggier if the router regenerated it from what it interpreted. 2. 
    providers have to determine for themselves what to leak and supress. 3. he 
    said the scheme introduces redundancy in a nasty way, if a bit is set, the 
    router has the capability and it is enabled, but there is no gurantee this 
    tlv is heard before another LSP using the capabiltiy. Hence, he is not sure 
    if the capability feature is really useful. As an example he gave: What 
    happens when a router sends you wide metric and not set the 
    corresponding capability bit.
    
    
    An IETFer from Juniper suggested router id to be made in a subtlv so that 
    that subtlv can be used conveniently inside other tlvs in order to reduce 
    number of encoding of the router id. He also said inside the same area this 
    subtlv can be skippped.
    
    
    Stephan: Makes l1/l2 router's lsps big...
    
    
    Dave Ward: no requirement to set bits for your capabilities. the tlv is 
    only adivisory. does the bit show how they are configured or does it 
    actually imply the router is using the capability? (i.e. what is 
    configured and what is actually being done can be different).
    
    
    Tony P: the bit has to be trusted, so it is not truely 
    informational. There was a question of which LSP fragment this tlv should be 
    inside. Naiming, any lsp number. When there is a change, and the tlv can 
    come inside any lsp and the latest lsp always overrides the earlier one.
    
    
    Someone pointed out the tlv is limited to v4 router ids only.
    
    
    Tony gave the group 2 options and asked for show of hands: 
    Options: 1. A per capabiltiy section has to be written, and one other 
    iteration has to be done before becoming a WG document. 2. Make it a WG 
    document now. 6 hands for option 1, 5 hands for option 
    2. Tony said too close to call and asked to take it to the WG mailing 
    list.
    
    
    Dave Ward suggested an alternative: Lets split the document (and 
    encoding) into two pieces, one for informational pieces and one for hard 
    coded pieces. There was a clear concensus on this 

    Slides

    None received.