2.5.5 IS-IS for IP Internets (isis)

NOTE: This charter is a snapshot of the 63rd IETF Meeting in Paris, France. It may now be out-of-date.

Last Modified: 2005-07-12

Chair(s):

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 05  Submit Experimental TLVs to IESG for publication as an Informational RFC
Jun 05  Submit Definition of an IS-IS Link Attribute sub-TLV to IESG for publication as Informational RFC
Jun 05  Submit A Policy Control Mechanism in IS-IS Using Administrative Tags to IESG for publication as Informational RFC
Aug 05  Submit IS-IS MIB to IESG for consideration as a Proposed Standard
Aug 05  Submit Multi Topology (MT) Routing in ISIS to IESG for publication as Informational RFC
Aug 05  Submit IS-IS extensions for advertising router information to IESG for publication as Informational RFC
Aug 05  Submit Routing IPv6 with IS-IS to IESG for publication as Proposed Standard
Nov 05  Review WG's priorities and future potential

Internet-Drafts:

  • draft-ietf-isis-wg-mib-22.txt
  • draft-ietf-isis-ipv6-05.txt
  • draft-ietf-isis-gmpls-extensions-19.txt
  • draft-ietf-isis-wg-multi-topology-10.txt
  • draft-ietf-isis-igp-p2p-over-lan-05.txt
  • draft-ietf-isis-admin-tags-03.txt
  • draft-ietf-isis-experimental-tlv-05.txt
  • draft-ietf-isis-link-attr-01.txt
  • draft-ietf-isis-ipv6-te-00.txt
  • draft-ietf-isis-caps-03.txt

    Request For Comments:

    RFCStatusTitle
    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
    RFC3784 I IS-IS extensions for Traffic Engineering
    RFC3786 I Extending the Number of IS-IS LSP Fragments Beyond the 256 Limit
    RFC3787 I Recommendations for Interoperable IP Networks using IS-IS
    RFC3847 I Restart signaling for IS-IS

    Current Meeting Report
    ISIS WG meeting minutes from IETF 63

    Thanks to Alia Atlas for taking the minutes.

    0) Status & Admin:
    Admin-tags
    moving forward in process - cleared AD Last Call Please send in implementation info. I'll send out a last call for these.
    M-ISIS: cleared ADLC & LC for implementation reports
    MIB: Going to LC any day now
    Capability Advert: dependent on ISIS-TE one last revision needed
    BFD Bit: very little discussion on list... requested to be a WG item. If any comments, interesting to hear those. (No comments). Multi-instance ISIS: after presenation, see about WG item Traffic Engineering: Finally an informational RFC. Want to now submit it for standardization. Will allow others to become standard. Are going to take another run around this. I'd expect to see it for the first rev to be exactly the same as the Informational RFC. Reason it went informational, hadn't cleared up responsibility between ITU and IETF, but now is clear.
    V6: protocol analysis
    Experimental TLV: Need implementation report - know of none & can't move forward. Without any implementation, very hard to have become a standard.
    V6TE: dying & expired. Will contact the authors directly. When take the TE draft, may take the V6 in. (ADs indicate lack of caring about whether this is in separate draft or same.)
    In Editor queue:
    Alex: checking what the P2P over LAN is stuck on. It is in edit state, which means they are working on text.
    Dave: GMPLS is stuck on the TE drafts.
    Bill: (shows scary graph of dependencies for the GMPLS extensions. mpls-bundle was blocking everything. They're all clear now. MPLS-bundle was pulled from queue shortly after it was approved, b/c a fatal flaw was found, it's been reworked, and then got put back into the queue. So complicated, not sure RFC Editor has caught up. It's unclear, so I'm going to talk to RFC Editor this week to make sure. This group of 20 docs is going to pop out of the RFC Editor's queue some day when we're not looking.
    Bill: We're in a situation where even docs without any blocking references, etc, it's taking about 6 months for docs to get through the RFC Editor's queue.
    Alex: Doc can stay in edit state for few weeks to few months, depending on how complicated the doc is.
    Milestones:
    Dave: On track - completely amazing, but we are. In Vancouver, we're supposed to recharter, so bring items. TRILL related drafts to appear & need to see where work will be. Jumbo frames

    Alex: Had conversation with IEEE about jumbo frames & we came to pretty good agreement. No objections to an informational RFC on what people do & what to look out for. They agreed to provide us with a technical advisor to give us some guidance on jumbo frames. The thinking is that we need to decide where we want to scope this work; whether it should stay here or be a design team between here & INT, because they're interested also.

    Dave: ISIS-IP has come & gone & come & gone. Various meetings where people want to run IPSEC over ISIS. It might come back, but let's save discussion for Vancouver & list.
    ============

    1) Multi-Instance IS-IS: Stefano Prevardi draft will be released very very soon

    Stefano: Idea is to allow multiple instances of ISIS to run over the same links. Ships in the night approach. Similar approach for OSPFv3. Add an instance identifier via a new TLV and add to each ISIS packet. Mechanism intended just to distinguish multiple instances. How to forward is out of scope.

    Still need to submit draft. Just flushing out the details. We're still looking at the backwards compatibility because routers not supporting this extension will silently ignore the IID TLV. think it's similar to migration from narrow metric to wide metric, so not expecting any major issues. A special IID value of 0 may be used to indicate the default topology to ease transitions.

    Questions?:

    Radia Perlman: What kind of problems do you have in mind for this to address?

    Stefano: Personally no problems, but customers want ways of having separate topologies. Not sharing fate, flooding scope. Which topologies should converge first. What if topology 1 is having an SPF & topology 2 that is higher priority then needs one.

    Radia: Did you have in mind something like VLANs, where you want to have totally separate networks. Then you'd probably have to

    Dino: I think we're at a point where we're not sending ISH

    Tony Li: Real problem I see here is to resurrect QoS routing...

    Acee Lindem: Actually, in all 3 protocols, in BGP, you can mix address families. In OSPF, can have a single adjacency or have per address family/adjacency, can demux various packets. I don't think that there's a problem with being able to do this two different ways. Make it easier to debug if just want separate neighbor databases, topologies, etc.

    tony Li: Thanks, don't see how that's arguing against what I'm saying. There are multiple ways

    Dave Ward: Just use generic term "service separation".

    Acee: Could use this to separate IPv4 versus IPv6 or unicast versus multicast topology. Any way you want to slice & dice.

    Dave: Assume you want to take this to WG as an item.

    Stefano: First, we have to submit a draft.

    Dave: Details, details ....

    Alex: Just to be clear, we're not talking about adding the ID yet to be submitted as a WG item, but talking about adding a work item to the charter.

    Dave: yes

    Dino: Might want to consider having run on a different MAC address, so those not participating, won't have to hear.

    Stefano: Yeah, we thought about. I'm not sure that it brings that much other than another method of complexity. Would give two levels of complexity. We're talking about control packets so not flooding much.

    Dave: What it would allow is routers in an LAN where some don't support & some do. Might help with interop.

    Dino: Would help with densely meshed. This might be something to add in addition, so as not to bother the single instance box.

    Dave: Any comments on this. Should all welcome Hank Smith back. See you all on the list.

    Slides

    None received.