Meeting Notes ISIS WG 2006-07-11 Document Status: - Docs progressing - Recharter in progress - Still operating under the old rules until things officially change. - v6 standardization process a bit held up because of a comment from the IESG that it needs more than a ref to the ISIS spec. WG chairs are going to push back on this, since this is deployed and interoperable. Stefano Previdi draft-previdi-isis-mi-mt-01.txt ISIS Extension, new TLV, used to identify the instance of ISIS the packet belongs to. The idea is to have multiple instances of isis with full separation. True ships in the night. Dino's suggestion from the last meeting: where you have MI and non-MI capable addresses, to use a different set of MAC's for multicast. This was documented in the draft. Hannes suggestion: Work on PDU version number. This is practically difficult since the IETF does not "own" the ISIS spec. Some discussion on the draft's solution to this interop issue between MI and non-MI routers. Alternate approaches were investigated. IID TLV seems more straightforward to implemetn and support. No major interop issues here. Next draft will incorporate the results of this. Chris: We need to do some more due dilligence on the assumption of interop. For example an interop report. The reason is we're counting on old implementations working this way. Stefano: Okay... Unidentified Speaker: Is this a WG item?? Dave: This is on the recharter list. Unidentified Speaker: Do we have to wait? Dave: We're treating this as if it were a WG item. Mohan Nanduri: This is a good thing for operators. ------------------------------------------------------------------ Russ White: HMAC-SHA Crypto Authenticaiton Draft. No sequence number, so vulnerable to replay. Slightly less vulnerable - wrong packets are silently discarded. - works over l2 ... All we're doing is updating from HMAC-MD5 to a newer, more secure algorithm. HMAC-MD5: although no published attacks, suspected to be vulnerable. New Proposal: TLV 10, CRYPTO_AUTH - value 2, to add a new, expandable value for example: SHA-1, SHA-256, etc. Allows easy extension with new auth algorithms. Allows for KEY-ID, which eases troubleshooting. Would like to make it a WG item. Dave: Let's take a poll. Room: NO OBJECTIONS to making the draft a WG doc. Dave: We'll take it up as part of the recharter. Dave: What's happening in OSPF? Acee: We're working on OSPF over IPSec for a while. I'm convinced that there may be a good argument for a mechanism such as this, but we need to take this up with the group. Dave: We may have a generic keychain object draft soon, that we can leverage that for both OSPF and ISIS. This will probably be in the rtgwg. Dave: As a reminder to the group, we cannot do ISIS over IPsec, since it is not IP. ------------------------------------------------------------------ Les Ginsberg Simplified Extension of LSP Space for ISIS Max size on LSP's (256 * 1492). Not a practical limit for routing, but when you add a mess of non-routing info, and you add in multi-topology info, you could exceed the space. This was addressed in RFC 3786 a few years ago, saying you could have alias system id's, and have a new full set of info for each alias. To achieve the full flexibilty, you need to use mode 2 in 3786, which is not compatible with legacy routers. This is what we're trying to address in this draft. New proposal: - Utilizes multiple system ID's and Alias System ID TLV like RFC 3786. - Defines new TLV to carry non-routing info. - Define rules for considering non-routing info for the same object when multiple TLV's are required. Some discussion on the changes from the previous draft based on comments. In the extended LSP's you MUST have: - Neighbor to the originating system, having a metric of maxmetric-1 MT support for all topologieS) - Area Address(es) - same as the Originating System - OL, ATT, P bits MUST BE ZERO - MT TLV (299) listed as necessary based on leaf node information. Normal LSP's MUST HAVE: - neighbor to the virutual IS with a metric of 0 (MT support - for all topos) - one other requirement. Extended LSPs MUST NOT HAVE - No neighbors other than to the originating system - TLV's which MAY NOT have... Extended LSP's MAY HAVE (new info): - Leaf Information (avoid if possible - because it increases the set of LSP's and cause a new SPF) New TLV's - Alias TLV (24) - IS Neighbor Attibute (23) - identical to TLV 22 - MT IS NEighbor Attirbute (223) - identical to TLV 222 Neighbor attribute TLV's do NOT establish a neighbor relationship! IS Neighbor Attribute TLV's - may appear in any LSP - handling multiple TLV's wi came context (eg link) - if no conflicts: TLV's are additive - if conflicts - Normal LSP's - Extended LSP with lowest system-id Overcomes 255 byte limit. Example of how this would work: Router A: Original LSP, advertise Max BW : Extended LSP, advertise Max BW + GMPLS Link Protection If Max BW is the same, then add GMPLS Link Protection, if conflict (such as different Max BW values, use lowest system-id tiebreaker) Advantages of new proposal: - Single Operating Mode - No Change to handling of LSP's in SPF - Backwards compatible - TLV "overflow" (>255/object) is easily accomodated. Limits: - Requries support foe extended LSP's in support of non-routing info extensions in the future - Requries new TLV for TE info has to be supported. Why? Existence of RFC 3786 may lead to deployments Alternative Solution will then be more costly/difficult. Dave: At last IETF, a poll indicated 0 implementations or deployments Les: Did do a MList poll - got one response, but only 3786 mode 1, not mode 2 so it is is compatable. ------------------------------------------------------------------ Dave Ward Recharter Items GMPLS extensions from info to proposed standard ISIS and BFD MI ISIS ISIS TE for v6 ISIS for App Server ISSI for L2 routing and discovery ISIS for IP FRR Sub-TLV for ISIS Link Attribute TLV Split LSP space into routing and non-routing info.