1. Expedited Flooding for Restoration in Shared-Mesh Transport Networks -draft-rabbat-expedited-flooding-00 -Richard Rabbat (FLA) -Vishal Sharma (Metanoia, Inc.) -Zafar Ali (Cisco) Observations –This work complementary to P&R team output –Captures all private and ML discussions and resolutions -Highlights time-bounded notification requirements for transport networks -Discusses mitigating factors to ensure no network meltdowns

2. Expedited Flooding Describes types of failure –Fiber cut –Transponder failure –Node failure Applies whether one adapts a link-state routing protocol behaviour or implements a new flooding mechanism Reasoning behind using an expedited flooding protocol –Points out the advantages of flooding –Discusses approach to avoid network meltdowns Sending message on first try happens immediately Retry attempts in the case of failure force a delay (using OSPF hold down timer or timers associated with new mechanism)

3. Comparison of Flooding and Signaling- Based Notification FLOODING Completeness. The notification reaches all edge nodes Overhead. The number of messages-per-node is deterministic and independent on the network state. Timely delivery. The notification delay is always minimal, as the flooding path towards any destination is the shortest-delay one SIGNALING Notification reaches only the edge nodes heading impacted LSPs. The number of messages-per- node depends on the network state, can be as large as N (# N of impacted LSPs) Delivery is not time-constrained. The notification delay depends on the actual LSP path and length.

4. Expedited Flooding Next Steps –We have received a lot of feedback on flooding-based notification –Need to advance draft to WG document since fits in charter