ISIS Working Group - Atlanta Chairs: Chris Hopps and Dave Ward Scribe: Acee Lindem acee.lindem@ericsson.com - Note Well: IPR declarations - Document Status: See Slides 1 New RFC, 2 in queue, 3 in WG - Multi-Instance ISIS Extension - Les Ginsberg * See slides for details of last draft revision * Now in RFC Editor Queue - ISIS TE Metric Extensinos * New metric for latency, loss, and bandwidth * See Slides Himanshu Shah: Is the link delay per link pair or link? Les Ginsberg: Per Link Himanshu: How are the measurements obtained? Les: Outside scope of draft. Himanshu: Described problem with link delay determination. Acee: TWAP protocol may be used. Dave Lamparter: Draft still has problems with A-bit specification. Les: Known and will be fixed. Dave: How is A-bit used? Les: It simply means the value is outside a configured limit. Don Fedyk: Some of the metrics could change very frequently. Would like to see a discussion of dampening, stability, or scaling. Les: Shares concern since the text is very general. Don: Not comfortable with current language. Need some hard numbers in a particular use case. Les: Will take back to authors. Chris: In interest of time, would like to limit discussion. Jeff Tansura: Should dampen advertisement to significant changes. Nabil Bitar: The measurements will vary by Class of Service yet there is only a single set of Sub-TLVs. Dave: Suggests splitting into two drafts with rapidly varying metrics in one and more stable in other. Curtis Villamizar: Clarified that Nabil meant DSCP or traffic class. Believes that usage of these metrics for TE or routing could result in instability if not done right. Huaimo Chen: What is the difference between existing TE bandwidth and the new ones? George Swallow: Existing TE measures allocated bandwidth and this is actual link bandwidth. Robert Raszuk: Will this go into BGP to send to ALTO servers? Les: Will not speculate. Kiretti Kompella: Can you prove that these metric can be measured and used for calculation without melting network? Lou Berger: Suggest people look at McDysan's MPLS draft on problem statement for information. Lou Berger: Leave out use cases that are not covered. Samita Chakrabarti: Should a measurement frequency TLV be added. Chris: This should really be discussed on the list. Les: Delighted with interest. Curtis: Interest doesn't imply interest in moving the draft forward. This topic is being presented in no less than 4 WGs. - Interface Address TLV - Donald Eastlake * Associates addresses with interfaces - See slides for details. * Suppport many address families and options in a single TLV. Don Fedyk: Is this taking ISIS in the wrong direction by putting this information into the protocol? Donald: Can use GENAPP or another instance. Don: Fast or slow portion? Donald: Both could be fast. You could have different stuff. Peter Lothberg: Multi-instances for more space? Don: Yes Les: Where is this advertised? Donald: LSPs Les: Why needed beyond link? Donald: Needed in data center applications. Can reduce the number of broadcast domains. George Swallow: Is this for VM movement? Donald: VM movement would actually change this TLV in LSPs. George: Has anyone looked at scaling? Donald: None yet. Chris: New draft - needs discussion on the list. Acee: GENAPP and Multi-Instance provide partioning of advertised information. It is up to the implementation to prioritize what is important. - IS-IS Extended Sequence Number TLV - Uma Chunduri * Solves replay attack issue * See slides for details Uma: Comments addressed in this revision. Les: Would like the ESN removed from LSPs. There are other ways to recover from LSP replay. Chris Hopps: Feedback from others than Les? Uma: Les and Mike. Chris: Sees LSP replay as a small attack vector. Believes it is a hard sell. Agrees with Les. Uma: Different deployments may use different timeouts. Can happen. Chris: Only happens when router goes down. Uma: Has backup slide with example. Also in KARP draft analyzing ISIS threats. Chris: Window for attack is small and the router is only vulnerable after it is restarted. [Post meeting correction: window is actually anytime after restart until the old sequence numbers are exceeeded.] John Scudder: If easy to deploy, the LSP ESN should be retained. However, if it makes network diagnose more difficult, it should be dropped. I believes it is not worth the benefit. Huaimo: Can this be proved mathemetically secure? Uma: No mathematics. ESN can prevent reply attacks. Chris: Sequence number for replay attack protection well-known. Wants more discussion on the list. Need one more call for comments. People are comfortable with IIH but not necessarily LSP ESN.