Notes for RTGWG Session – Monday, March 28, 2011 1300 CEDT – Prague Agenda Bashing & Current Draft Statuses - Alia Atlas Announcement of note well. Review of status presented LFA Applicability - draft-ietf-rtgwg-lfa-applicability - Clarence Filsfils Described differences in latest version – editorial nits and better explanation of failure effects. Added explanation of capacity planning with LFA. Document will go to WG last call after IETF. Multicast Only Fast Reroute - draft-karan-mofrr - Clarence Filsfils Problem: fast recovery from network outages (<50ms). Aimed at being an easy solution for common cases; not applicable to all cases. No planning for extra bandwidth; no IGP convergence dependency. Discussion of application to Two-Plane. Network designs. Q from John Scudder – Draft says intended status is informational. Is that intended? Author agrees to accept chairs’ advice on intended status. Arun asks were the work belongs? Here, PIM? Clarence responds suggesting that it belongs here since there are no changes to the protocol changes to PIM. Chairs agree to talk to other chairs and ADs about the correct location for the work. Composite Link Framework - draft-so-yong-rtgwg-cl-framework-03 - Ning So Changes made to align with the requirements draft evolution. Signaling extensions to LDP support to address problems found by discussion Added section on Management plane impact John Scudder asked for objections, noting that given the requirements work already done by the WG, this is likely to be adopted as a working group document. Review of the scope of the protocol extensions needed to support this work. The presenter noted that there are many small impacts on many protocols. Composite Link Discussion Curtis Villamizer suggested taking an inventory of existing mechanisms to address the needs. Lou Berger suggested that CCAMP will need to discuss the protocol changes once there are actual drafts with proposals. John Scudder pointed out that the common approach is to present such material twice, once in RTGWG for the collective work and once in the protocol WG. Acee Lindem agreeing that more information is needed before it can be determined where to do the work. Agreement that Last call will probably need to be in multiple places. OSPF TE Express Path - draft-giacalone-ospf-te-express-path - Spencer Giacolone Driven by a need for low latency, very high grade SLA, network services. Financial data networks, for example. Traditional metric techniques are hard to use. Overview of solution: OSPF extensions to distribute performance information. The draft is aimed at TE, and aims at distributing average (steady state) values. Control plane specifics to ensure stability are important but separate. Discussion of details of encoding. Details of precision and general issues of extensibility and stability. Lou Berger raised another draft (delay-metric draft in ccamp) sthat should be compared, and maybe combined with this work. Wenhu Lu asked about how the information is used, in parciular whether this is driven by client requests, of more pushed from CSPF? If pushed, how does CSPF know whom to notify. Alia Atlas compared this to link failure notifications. Agreed that triggering has to be relevant to affected LSPs. Fast Notification Framework - draft-lu-fast-notification-framework - Wenhu Lu Summary of changes presented. Text modified to clarify goals of work. Dicussion of open issues. Transport of Fast Notification Messages - draft-lu-fn-transport-00 - Jeff Tantsura Presentation of a generic mechanism to carry notifications needing rapid dissemination. Description of necessary properties; using a pair of redundant trees to meet goals. Two possible encapsulations mentioned. Description of authentication: per link or per area. IP Fast-Reroute with Fast Notification - draft-csaszar-ipfrr-fn-00 - Andras Csaszar Description of using fast notification to enable IP FRR with rapid response and good coverage. NS-2 had something like this (simplified) many years ago. Walk through of the behavior and its results. Including issues when only some nodes support the capability. Stewart Bryant (also Channeling Mike Shand): How does this differ from the earlier presented methods of remote fast-reroute? A rough answer was provided. Doesn’t the presence of many legacy nodes cause serious micro-loops? Yes. This assumes that most of the nodes have been upgraded, and only a few are using old behavior. Debate of likely impact. How does this scale in terms of computation and FIB loading? Answer that the authors have some computations in the drafts. Hannes finds the idea appealing, wonders whether this should include support for ordered FIB update? Andras responded that with the fast path forwarding, the micro-loop issue is significantly decreased, so there may not be need for ordered FIB. Hannes pointed out the link up is still uncovered. (Mike Shand via Stewart) comments that FIB update time is what drives the micro-loop FIB ordering issues. Discussion ensued. Hannes asked about cancellation, for example with a micro-flap. General question raised / discussed as to whether this piece of the puzzle (fast propagation of notification) is important to solve? Definitional argument as to whether non-local repair can be local fast re-route. In particular, when the speed of light delay across the area is longer than the target response time, does this help? Network diameters in the range of 11 to 15 hops were in the data collected earlier, and need to be handled. Eric Osborne asked if this could be handled more generally with an OSPF fast flood LSA. John Scudder called for conversation on the mailing list, with the hope of either adopting or dispensing with this work by the next meeting. He asked for an executive summary to the mailing list. New Protocol for on-demand dynamic route optimizations between tunnel endpoints – draft-templin-intarea-vet-24, section 5.14 – Fred Templin This is work based on Internet area tunnel work. When one has many devices using a tunneled infrastructure, one can overload hub routers, or have very large number of routing adjacencies which are hard to handle. Outline of a set of (10) requirements. ICMP Router Redirects address something similar, but has serious drawbacks when checked against the requirements. So they have built a custom redirection solution: predirection. The proposal handles asymmetry and legacy easily. Fred is hoping that the draft he will be submitting will be considered by the working group. Jeff asks about whether the NBMA can ensure transitive reachability. If the source being redirected can not send packets directly to the target to which it is being directed, how is this detected and coped with? History tells us this happens.