Last Modified: 2003-05-19
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 |
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 |