Last Modified: 2004-07-23
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.
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. |
RFC | Status | Title |
---|---|---|
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 |
ISIS
IETF-60 - ITU Liaison Statement Jonathan Sadler No Comments. --- - draft-ietf-isis-wg-mib-16.txt Removes multiple instances (MIB) Q: Why ? Chris: . 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 <chopps@rawdofmt.org> 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 <naiming@redback.com> 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 <Jon.Berger@dataconnection.com> 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 <jvasseur@cisco.com> 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 --- - RBRIDGE 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 --- - MERGED STDS TRACK DOCUMENT: 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 .... |