OSPF WG Minutes - 03/29/2011 Co-Chairs - Acee Lindem and Abhay Roy Scribe: Lyndon Ong * WG - Status - Acee presented the agenda and WG status. - No new RFCs since Beijing, a few active drafts. - Transport Instance is referenced in some CCAMP drafts, want to complete this work. - Work on OSPFv3 authentication trailer very close to WG LC. - OSPFv3 PE/CE L3VPN in WG LC in vpn group, - rfc5787bis close to CCAMP WG approval. - Many WDM-related drafts in CCAMP. - RFC 3137bis, IPv4-embedded IPv6 - likely WG drafts. * Draft-retana - RFC 3137bis - Alvaro Retana - Advertise non-stub links set to LSInfinity - explicltly added support for OSPFv3 since the last meeting Acee: commented that there is the R-bit in v3, can we use it here? Alvaro: - here we still allow transit. Discussion taken to the list. Gregory Cauchie: Same comment, R-bit can be used instead of setting LSInfinity. Alvaro: - not inventing a new method, just updating old document. Acee: Any opposed to making this a WG draft? None. * Authentication trailer for OSPFv3 - Acee - Agreed as WG draft in Beijing. - Since then clarified headers with LLS and incorporated LLS block into authenticated data. - Also noted checksum omitted if authentication trailer is used. Other changes as well. - Everyone should read this and comment ASAP, this will go to WG Last Call. * Area ID extension - Wenhu Lu - Current need for inter-area LSPs, selection of Border Nodes/ABR-LSRs. - Solutions include global TED, crankback and BRPC, but first is too big, latter two involve knowing the ABRs. - RFC 5088 provides a way to discover PCEs, not LSRs. - RFC 3630 supports finding intra-area LSPs. Propose to add Area ID TLV (possibly multiple) as part of RFC 3630 LSA to advertise connecting TE-enabled areas. - Can automate crankback, support BRPC. Backwards compatible. Russ White: What about networks with multiple areas using the same Area ID or an area that splits into multiple flooding domains? Method not sufficient, may need router ID as well. Julien Meuric: Problem statement is not clear. Wenhu: How do you act without this information? Julien: Use endpoint reachability. Wenhu: Reachability does not give you bandwidth, color. Julien: How will Area ID help? Wenhu: Hand off data to use in the next area. Need offline discussion. Dimitri Papdimitriou: Implicit assumption here that the source has no reachability information outside its domain (AS-external information). Wenhu: Reachability information is already there for the domain, this tells you a particular router is an exit router. Dimitri: Is this for source path computation or distributed as in PCE? Wenhu: To pass computation on. Dimitri: Should clarify draft that you are advertising "Reachable Areas" associated with LSR. Acee: Draft should include the primary use case for review. * TE Express path - Spencer Giacalone - Objective: distribute performance info to set up express LSPs. - Application - financial, computer automated trading - Highly sensitive to latency and packet drops. - Sensitive to microseconds. - Cost is not sufficient as a metric - multiple performance metrics, variable over time. Need current value at LSP compute time. - Proposal is a way to distribute performance data, independent of measurement protocol or routing application. Aimed at MPLS, so not so concerned with stability or oscillations. - Extension to RFC 3630 to add nominal (steady state) and anomalous (trigger) sub-TLVs, different schedules. Within these categories, defined five delay sub-TLVs. - Example: nominal TLV used for path computation, anomalous TLV sent on violation, triggers failover. Overlapping work in CCAMP needs to be discussed. About 1/3 people had read the draft. Acee: Suggests positioning this work vs. CCAMP work, seems like different applications. Notes preference for straight microseconds instead of floating point. Still lot of discussion about best encoding of latency. * Fast notification - Sri Kinni - Changes to the way the information is organized since the last time - Notes improvements in failure detection and forwarding architecture have made flooding a bigger component of delay, especially, hop-by-hop processing. - FN transmits notification without control plane involvement at intermediate hops. - Jump starts computation, no ack as flooding still continues and compensates for lost FN. Open issues on format, authentication and timing of computation. Manav Bhatia: Would you authenticate FN and flood? Sri: No flooding. Manav: Susceptible to DOS attack? Sri: Could have an option for this but would cause added delay. Manav: Can't do this in hardware. Sri: No different from dataplane forwarding. Manav: No, different priority. Remote Question: How much time will be saved? Sri: Different depending on network topology. Questioner: Suspect time reduction is less than 100ms, is this important? Sri: Could be a lot more than that. Dimitri: Could be that normal flooding will reach faster than FN. Are trees global across area? Sri: Yes. Argument is that control plane flooding will always be more processing and slower. Dimitri: What happens if normal flooding gets there faster? Jeff Tantsura: Need to precompute failure scenarios. Abhay: When do you install routes? Sri: Not until after flooding reaches you, but you can precompute your routing table before this. Sri and Jeff: Also note that redundant FN trees will avoid loss of FN messages due to failure. Main discussions taking place in Routing WG. * Security extensions for Manual Keying - Manav Bhatia - RFC 6039 analyzes vulnerabilities in OSPFv2 - Vulnerable to replay, IP header not protected. This draft fixes these issues by extending the authentication sequence number space (split 64-bit) and adding session ID and nonce, and by including source IP address in authentication. - Want OSPF people to review, hope to eliminate session ID and nonce if sequence number method works. Acee: In favor of the new solution. Manav: Wants to make sure it defends against other attacks. Also notes wrapping would only take place after a very long period. Wenhu: If people don't want this type authentication, do they still need to use this? Manav: Yes, could go back to 32 bit. This is a separate Auth Type. Wenhu: More than configuration required. Manav: This is something you would use in all your routers, not just a single one. Wenhu: What determines sequence number? Manav: Could be anything, although must put part of it in non-volatile memory. Wenhu: Any better approach? Manav: SNMPv3 already maintains a variable in non-volatile memory, could use this. Acee: For NSR, one could just increment the top 32 bits. Wenhu: For NSR, you don't need this. Manav: Could use the same restart counter across all routing protocols. Brian Weis – Depending on platform, NVRAM is more fragile than challenge/nounce approaches, prefer challenge/nouce approach as you don't depend on anything external (differing opinions on how complex the challenge/nouce approach). Acee: Hello packet is 3x larger with challenge/nounce approach. Acee: Please read - candidate for WG document. * MANET - Single Hop MANET Interface - Alvaro Retana - Update to 5820, experimental RFC for MANET. - Supports single hop broadcast network, direct connectivity between all nodes, different metrics may exist between neighbors. - Simplification as Smart Peering used to reduce adjacencies. - Redefines Router Priority field for use in Smart Peering. Emmanuel Baccelli: Why don't you just use designated router if everything is one hop? Alvaro: Different costs between neighbors, also mobility that causes metrics to change. Single type of interface deployed everywhere is cheaper. Emmanuel: What does reduction of adjacencies buy you? Alvaro: Only need to create and synch adjacency with a few routers rather than a hundred. Category remains experimental. Acee: Seems like a reasonable extension, poll if anyone is opposed to this update. None. * Incremental Link State Database Synchronization - Alvaro Retana - Opaque LSAs use incremental synchronization to avoid impacting router convergence. - Incremental synchronization allows prioritization of LSAs, including potentially different opaque LSAs. - Then sync using important LSAs first, then later do final sync using RFC 4811, OOB resynchronization with remaining LSAs. - Describes how this works with Graceful Restart. Complements rather than replaces use of multiple instances. - Category informational. - Poll indicates generally people like it. Acee: Further discussion on the list. Dimitri: How do we insure that neighbors are capable of doing the second stage, that IP routing has converged? Alvaro: This does not change handling of IP routing. Dimitri: This adds new new stages to my draft. This avoids by exchanging states, but doesn’t guarantee that non-opaque entries are empty. Need to ensure that non-opaque entries have been processed. Wenhu: Thinks this is good idea, but is it possible to have a smaller routing LSA group? Alvaro: If you don't send all the routing information, sure, depends on what you send. But intention is the first update is all routing information, otherwise difficult to decide how to phase. Note some opaque LSAs do contain routing information and would be included in the first stage. Wenhu: Do you use the same routing interface? Alvaro: Yes, RFC 4811 discusses this. Dimitri: More on the opaque LSAs – how do you distinguish between important and less important opaque LSAs? Needs more discussion. Alvaro: Yes, decision is outside the proposal itself. This is a local decision. Dimitri: Not a complete solution without knowing if it is workable to make such a decision. Abhay: If you know for sure something is less important, this can be put in the second phase, everything else should be in first phase.