ISIS Meeting Notes: Status given (see presentation) * MIB is in RFC-ED Queue * Experimental TLV - no implementation needed for experimental * no implementations * proceed as experimental anyway? Chris Hopps: There was a request to ask the group if anyone had an issue with reviving the draft and taking it to Experimental? Bill Fenner: There's been this weird tension between wanting to do neat new things with new TLVs and wanted to be sure that what's deployed is documented. One conceivable thing to do is to restrict what's done by restricting the allocations, but that won't work b/c people will implement without allocating - so that won't work either. That's my main concern with this. We may get pushback from Ops b/c it gives the ability to put anything out there with no documentation. Chris Hopps: Shouldn't that be driven by the operators who are going to use it? Dave Ward: No known implementations - talked about it for the last few years. Asked for hands for interest in resurrecting the space (no hands). Asked for hands for no interest (again no hands). Dino: If a vendor wanted a proprietary TLV, would you recommend them using this or something else? Chris Hopps: This - it uses an enterprise code plus whatever the vendor. (Gives details on solution in draft - one TLV & then enterprise can put whatever it wants in it.) We'll take this to the list. Dave Ward presents the recharter items info from presentation. ******* Eric Gray - TRILL Routing Requirements (draft-gray-tril-routing-reqs-00.txt) (See presentation) draft-ward-l2isis-01.txt has more applicability than TRILL & so discussed here. Erik Nordmark: Reason not accepted as a WG doc yet was b/c very few people had read it. People in this group are welcome to read and provide comments. Dave Ward: If, as you are progressing this doc, if you could have a presentation here and keep us informed here, that'd be great. Erik Nordmark: Sure - the ADs pressed us when chartered that all the routing work be done in the routing working groups. Dave Ward: Are you settled on ISIS or are other protocols possible as well. Erik Nordmark: The WG hasn't officially decided yet... Kireeti: RIP Chris Hopps: Let the minutes note that Kireeti has volunteered for RIP Erik Nordmark: No way for OSPF to just form 32-bit router IDs for OSPF. That's much easier with ISIS - if we really want to be plug-n-play, then ISIS is the most likely directions. Eric Gray: There are some hack mechanisms that could be used for OSPF, like using some addresses from the 10.x space & such - but that is a hack. Dave Ward: So when the official decision is made let us know if it's ISIS & if it's not we'll continue on our merry way. -------------------- Les Ginsberg : Simplified Alternative to LSP space problem (See presentation) Dino: Quick question on mode 1. The TTL obviously won't be decremented when it goes through R' Les: It's not an actual router... Dino: Understand - but if one looks at the database, there will be an extra hop compared with the path trace. Would that confuse some network management? Mike Shand: So, Dino, you mean like pseudo-nodes? Dave Ward: This isn't really the meat of the conversation. Les is building up to say this isn't the right thing so.. Les: This hasn't really been implemented so... (presentation continues) Acee Lindem: How do you intend to assign TLVs in the extension? Les: There are no new TLVs defined by this proposal (we may need a new one for TLV 22) Alex Zinin: I think we went through a similar discussion when we did RFC 3768. The question as to whether there was enough space for the prefixes and routing info - and as people start leaking more prefixes between levels and so on, that steered us to the previous solution. Has anything changed? Les: I don't think so & I have that listed a restriction. The general reaction seems to be that we're not running out of space now, but it is possible. Acee Lindem: Another question regarding a conversation I had from the L1VPN group. If you decouple the reachability info, how do you know the info is stale when the router goes away? Les: This is handled by the reachability draft - so don't use info from a router that isn't reachable. Alex Zinin: I think you should really write this draft and discuss it on the mailing list. The longer we have the previous RFC, the more likely we'll have implementations and the harder to change direction. Les: The draft can be produced amazingly quickly. We put out an initial feeler on the list to see if there was interest or just a "go away, we've solved that problem". We heard of 1 implementation, but only for Mode 1 and haven't put any neighbors or attempted no mode 2 behavior. Other feedback was this doesn't seem like a problem. Alez Zinin: Do some real stuff? Les: Yea, so we went cautiously. Alex Zinin: I reviewed and shepherded the previous approach and I think we could have done something simpler. Les: So I can count on your support? Alex Zinin: Yes... need draft. Dave Ward: The separation of the routing and non-routing in Les's proposal allow us to go in different directions. Alex Zinin: You mean we could put more non-routing stuff into ISIS? Radia: Does this draft that doesn't exist yet just say how to do this or does it contrast it? I think it would be nice Acee Lindem: RFC 2370 doesn't trigger SPF computations (more joking about the different behavior of OSPF). Kireeti: Does the interoperability lack with RFC 3786 for mode 2 & this cause any concerns? Les: The impression from the discussion with the implementors was that it wouldn't be much work or a problem. Kireeti: That should be documented... Dave Ward: What's the interest in this before Les does more work? (a few hands raised) No one raised hands saying didn't want to see this work. We have RFC 3786 but no implementations or care. Rudiger: It's INFORMATIONAL Dave Ward: So we could obsolete it... Alex Zinin: Let's wait until we get the draft. Dave Ward: Let's just pose a hypothetical question while people are awake. Eric Gray: Could have this obsolete RFC 3786. Dave Ward: So that's what most likely would happen. Les: The intention is not to have two implementations out there. Alex Zinin: When we see the draft, have the discussion, and agree then RFC 3786 can go historical. Stewart Bryant: Immediately once there's the agreement. Dave Ward: right