Agenda: ================================================ 3m - Chairs: Intro, Administrivia 13m - Les Ginsberg - GenApp 13m - Stefano Previdi - Multi-Instance IS-IS 7m - Carrying Attached Addresses in IS-IS -> Vancouver meeting 19m - Moving docs to proposed standard - BMWG, three IGP convergence drafts, need to be fixed. Chairs went to BMWG and offered to help. Any other volunteers to help BMWG should contact the chairs. 13m - Les Ginsberg - GenApp ================================================ - Application IDs to be assigned by IANA Anyone think 2^16 applications - isn't enough? There is no good reason for the routing protocol to carry - application information! DWard: Isn't that why opaque LSAs were invented? - Nonetheless, wanted/needed... - Use genapp functionality in a separate - IS-IS instance to separate routing information from application - information (which we have no good reason for carrying :-) Want to be a - WG item DWard: any opposed? (no hands) DWard: to mailing list Adrian Farrel: What is a router? What is an application? How many instances should we run if we have multiple applications? Les: Routing information is used by the IS-IS protocol itself. Adrian: So, not IP forwarding! Les: Yep. But, that horse has left the barn. Les: As for number of instances, I have no response other than to say that it needs to be in a different instance. DWard: Doc should have more clarity about what the difference is between routing and non-routing information. Dimitri Papadimitriou: What about RFC 3784 for example? Is genapp for future apps only or for old stuff too? Les: Future stuff. Not trying to turn back the clock. Robert Raszuk: But TE is a huge part of the IGP now, impacting performance. Les: Legitimate point. I would certainly not object to moving! DWard: Doc should have more clarity about this point too -- what stuff moves, what stays, etc. Had some problems with PCE in this context, no conclusion yet. We will ignore the question and continue. Dimitri: Do you have any evidence that IS-IS TE actually impacts performance? DWard: Over the last 3 years we have had several drafts offered which are truly application-specific, that's what this is really about. By application I mean stuff that has no effect on forwarding. Dimitri: Would putting PCE discovery for example into another instance make it more palatable to the IS-IS community? DWard: Going forward document will need to define a transition mechanism for moving things from one instance to another. DWard: Let the record show that nobody was opposed to making it a WG document. 13m - Stefano Previdi - Multi-Instance IS-IS ================================================ CHopps: Not sure I agree that (ethertype + mcast) is of no extra benefit. Ethertype would add an extra layer of protection against misdelivery. ???: Have you considered carrying instance ID in the PDU header given there is a reserved byte? Or how about making it the first TLV in the LSP. Stefano: You mean the CLNS header? It's been proposed but it would require we go to ITU, we preferred not to do that. Regarding position of ID TLV I tend to agree it would be convenient. Maybe this should be specified as such. But what about when you have fragments? Different implementation strategies may exist. ???: You definitely have to carry the ID in each fragment. Les: Nothing prevents an implementation from sending the TLV first, but you should be prepared to receive it however. ???: Makes it easier to parse anyway. Stefano: Sure but your parser still has to be liberal in what it accepts. ?(France Telecom): Have you had a chance to compare your draft with the multitopology draft? Stefano: MT draft shares fate and packets. Multiinstance separation is further down. ?: Do you think multiinstance performs better, better for routers? Stefano: Multiinstance is not for multi-topology, it's for fate isolation. DWard: Does anyone present think this SHOULD NOT be a WG document? (no hands) 19m - Moving docs to proposed standard - Chairs - (Eyechart showing that various IS-IS doc are informational but referenced by docs that want to be standards -- this is a problem.) - For each RFC that needs to be reissued, needs new boilerplate, nit compliance, stuff like that. - NOTE that no aspect of the document including security section needs to be updated. - Need volunteers! RFC: - Don Eastlake volunteers for 3373, 3567 - Danny McPherson: 2763 - Tony Li volunteers for 2966, 3567 - Mike Shand volunteers for 3847 - Several still need volunteers I-Ds: - Routing IPv6 w/ IS-IS: Chopps volunteers - Admin tags: Stefano volunteer - M-ISIS: Les Expired I-Ds: - Simplified Extension of LSP Space -- maybe is in RFC queue? Les volunteers to update as needed, WG chairs volunteer to check status - IPv6 Traffic Engineering -- David Macwalter volunteers - Goal is to have this DONE by Vancouver. - We have a hand process which might help move from nroff to XML, see chairs if you want help.