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.|
|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|
- ITU Liaison Statement Jonathan Sadler
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 <email@example.com>
use of colouring in specific context (leaking for loo for MPLS VPN, fast convergence (route priority), ...)
map BGP extended community => two different TLVs
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 <firstname.lastname@example.org>
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 ?
- draft-ietf-isis-wg-multi-topology-07.txt Naiming Shen <email@example.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 <firstname.lastname@example.org>
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 <email@example.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
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 <firstname.lastname@example.org>
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
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 ....