Open Shortest Path First WG (ospf) Monday, November 17th from 09:00-11:30 ====================================== SCRIBE: Paul Wells CHAIR(s): Abhay Roy Acee Lindem o Administriva -------------- - Mailing list: ospf@ietf.org * Subscribe/Unsubscribe: ospf-request@ietf.org with "subscribe" or "unsubscribe" in the body of the message * Archive: http://www.ietf.org/mail-archive/web/ospf/current/index.html Scribe: Paul Wells o Document Status - Acee/Abhay ------------------------------ Slides: http://www3.ietf.org/proceedings/08nov/slides/ospf-0.ppt Work completed since Philadelphia (there was no OSPF meeting in Dublin): RFC 5185 - OSPF Multi-Area Adjacency Acee: we now have multiple implementations. RFC 5187 - OSPFv3 Graceful Restart RFC 5250 - OSPF Opaque LSA Option Acee: Added condition of reachability for an opaque LSA to be valid. RFC 5340 - OSPF for IPv6 Acee: This was a respin of RFC 2740 - the text was cleaned up and some cases clarified. RFC 5243 - OSPF Database Exchange Summary List Optimization RFC 5329 - Traffic Engineering Extensions to OSPF version 3 Acee: Lots of work has been published - we need to skip more meetings :-) A number of comments have come in rather late in the process. Please try to comment on drafts before last call. IESG review: OSPF Link-Local Signaling (Standards Track) - draft-ietf-ospf-lls-05.txt Acee: This draft now includes OSPFv3 and is used by Manet drafts. Expert review: Management Information Base for OSPFv3 (Standards Track) - draft-ietf-ospf-ospfv3-mib-12.txt Acee: This draft is crawling to the finish line. The MIB doctor review is complete and the authors need to update. One variable has been added from the new RFC 5340. Dave Ward: This draft has been in process for 6 years. Nothing has changed in the last 12 months. We either need to finish it or move it to dead state. Acee: Will dock the author's pay. Dave: Acee should take this over. Acee: Should be possible to complete this quickly, but it is labor intensive. WG Finished - Waiting on WG Chairs or ADs: Extensions to OSPF to Support Mobile Ad Hoc Networking (Experimental) - draft-ietf-ospf-manet-or-01.txt MANET Extension of OSPF using CDS Flooding (Experimental) - draft-ietf-ospf-manet-mdr-03.txt OSPF MPR Extension for Ad Hoc Networks (Experimental) - draft-ietf-ospf-manet-mpr-02.txt Acee: We've decided to review all three drafts as experimental. One of them may go forward. Close to WG Last Call: Support of address families in OSPFv3 - draft-ietf-ospf-af-alt-07.txt (Standards Track). Dynamic Hostname Exchange Mechanism for OSPF (Standards Track) - draft-ietf-ospf-dynamic-hostname-01.txt Acee: This is a simple draft, will last call. Advertising a Router's Local Addresses in OSPF TE Extensions (Standards Track) - draft-ietf-ospf-te-node-addr-04.txt . Need author revision . Requested by CCAMP Co-Chair Acee: This will die if not refreshed. Need Better Review/Discussion: OSPF Version 2 MIB for Multi-Topology Routing (Standards Track) - draft-ietf-ospf-mt-mib-01.txt Acee: We need an implementation of this. OSPF HMAC-SHA Cryptographic Authentication (Standards Track) - draft-ietf-ospf-hmac-sha-03.txt Acee: This was near last call, we will bring back to WG for additional work. Non-WG Documents: OSPFv2 Multi-Instance (Standards Track) - draft-acee-ospf-multi-instance-02.txt (presented later in this session) OSPF Transport Instance Extensions (Standards Track) - draft-acee-ospf-transport-instance-01.txt (presented later in this session) Non-WG Documents - Lost Momentum: Authentication/Confidentiality for OSPFv2 (Standards Track) - draft-gupta-ospf-ospfv2-sec-00.txt OSPFv3 MTR - draft-ietf-ospf-mt-ospfv3-03.txt Acee: We need some interest from implementers for this to go forward. o OSPFv3 as a PE-CE routing protocol - Padma Pillay-Esnault ----------------------------------------------------------- slides: http://www3.ietf.org/proceedings/08nov/slides/ospf-1.ppt draft-ietf-l3vpn-ospfv3-pece-01.txt . OSPFv2 as pe-ce: RFC 4577. . Motivations for OSPFv3 the same as OSPFv2. . OSPFv3 as a PE-CE protocol has similar requirements as specified in RFC 4577. It has consistent behavior and format with OSPFv2 where applicable Differences between RFC 4577 and this Draft . New BGP extended community . Support for multiple OSPFv3 instances . Assign domain-id per vrf or per instance . Support multiple OSPFv3 instances across sham link BGP OSPFv3 route extended community . Allocated from v6 address specific bgp extended communities Changes from version -00 . Add support for multiple address families from af-alt draft . Added clarifying text: . med . instance id has link-local significance . sham link definition . Removed section 5.1 Way ahead . Ensure synchronization with draft-ietf-ospf-af-alt . Explore connectivity between v2 and v3 PEs . Comments? Acee: Send comments to both the OSPF and L3VPN working groups. RFC 4577 got late addition of DN bit for external and nssa LSAs. Do we still need the tag method to prevent loops? o OSPF LSA Correlation - Mukul Goyal ------------------------------------ slides: http://www3.ietf.org/proceedings/08nov/slides/ospf-2.ppt draft-goyal-ospf-lsacorr-00 Change in scheduling route calculations . Topology change causes a number of LSAs to be generated . A new LSA triggers a routing table calculation . Commercial routers use hold time schemes to limit the number of routing table calculations, e.g. exponential backoff. . Hold time causes extra delay in convergence LSA correlation . Instead of using new LSA arrival - correlate LSAs to identify topology change . Identification topology change serves as the trigger for a routing table calculation How to identify a topology change? . Link down - either end breaks adjacency . Link up - both ends establish adjacency . Node down - not adjacent to any node . Node up - adjacent to all neighbors Identifying link/node down events . Link down could be part of node down . Link down: both ends link generate new LSAs . Node down: down node will not generate new LSA . To tell which wait for new LSAs from both ends of link . But - will delay link down events - the most common type This can be overcome (see slides) Identifying link/node up events . Examine router LSA Different link types in OSPFv2 and corresponding link states in LSA Avoid multiple SPFs for multiple concurrent topology changes Robert Raszuk: Node down all peers - what about max metric? Will SPF run? Abhay Roy: Cost changes? Mukul: We will run SPF. Acee: In OSPF max-metric does not make link unreachable (unlike isis). Acee: Local optimizations are prone to bugs - OSPF is more I/O bound - more bang for buck by only running changed area than doing correlation - would not do this - would look at previous LSA - did bi-directional connectivity change? If not skip SPF. Not a big fan of local optimizations. Mukul: There must be a fear of too frequent SPF runs - otherwise why have hold timers? So why not be more clever? Acee: Old implementations were more affected. Mike Shand: Compare work (cpu) involved in LSA correlation vs. SPF? Mukul: LSA correlation is trivial. Mike: Do you have simulation results? Mukul: Yes - Two types: First, single topology change for router with lots of neighbors. Mike: Are the results published? Mukul: Yes - can provide pointer. Mukul: Second type, large RIB - LSA correlation allows use of use smaller delay. o OSPF Multi-Instance Transport Instance Update - Acee ------------------------------------------------------ slides: http://www3.ietf.org/proceedings/08nov/slides/ospf-3.ppt OSPF Multi-Instance Draft Review draft-acee-ospf-multi-instance-02.txt . Extends multi-instance function of OSPFv3 to OSPFv2 . Backward Compatible - Will be dropped due to authentication type mismatch by implementations not understanding. Acee: Fewer concerns now about backward compatibility after talking to implementers. . Now asking for WG acceptance pending verification on the list OSPF Transport Instance Draft Review draft-acee-ospf-transport-instance-01.txt . Provides framework for Instance(s) devoted to non-routing information . New version makes parent-check instance relationship "For Future Study" . Asking for WG acceptance pending verification on the list Dave Ward: The Alto WG is looking at peer-to-peer using routing information. It would be worth looking at application layer traffic optimization work. Acee: Use OSPF to carry application data. We get requests to use OSPF from other WGs - give applications their own instance. Igor Bryskin: Any existing implementations of multi-instance? Dimitri: Definition of routing information - where is boundary? Acee: MPLS/TE will be grandfathered in. Dimitri: How much usage is left? Acee: Won't configure if not used. Already draft in isis (genapp). . Doing this now because of application demand and because WG backlog clearing. Igor: Lots of apps? Can you name them? Acee: Pseudowire endpoint discovery - IPSec vpn discovery. We won't ask TE to move to new instance. Dimitri: Need to be more formalized. What is proposal trying to do? Priority for flooding? Objectives need to be part of document. Acee: Will be in discussion - not in draft. Won't mandate implementation details. Can add objectives, e.g. isolation. Dimitri: Isolation yes - still fate sharing - may defeat objective. Acee: Run on same node - some interference. Dimitri: Could we isolate processing of opaques within one instance? Acee: Yes - db exchange. Dimitri: Would need new definition of sequencing in current RFC. Acee: This proposal same as isis - simpler approach - harder to do within instances. Dave: Want to preserve existing uses. Use this for new applications that don't affect routing. Lots of apps (see Alto) - proximity info - need to protect TE and IP routing. Things need a place to go. Acee: Thinking about mess in single instance implementation to prioritize routing over non-routing. Igor: Advantage of multi-instances is multiple topologies. Moving application (TE) to new instance is not helpful - makes sense when there are distinct topologies. Dimitri: Do not believe goal is wrong - need to consider if this is the best way to achieve it. Need to discuss more. Acee: Asking for WG acceptance on list - will add discussion on transport use. o Support for address families in OSPFv3 - Abhay ------------------------------------------------ slides: http://www3.ietf.org/proceedings/08nov/slides/ospf-4.ppt draft-ietf-ospf-af-alt-07.txt Abhay: Draft has been stable for a while. A simple idea with two known implementations. Were ready for last call - question came up about link MTU use - new draft clarifies this. Added M6 bit to define MTU use. We will WG last call after this IETF meeting. o OSPFv2 Stronger Authentication Algorithms - Steve Blake for Randall Atkinson ------------------------------------------------------------------------------ slides: http://www3.ietf.org/proceedings/08nov/slides/ospf-5.pdf History: cleartext -> md5 MD5 is still secure when used for authentication. US Department of Defense (DOD) wants only approved algorithms. MD5 is not approved, wants SHA-2 instead. There is a current I-D to add SHA-2 as an optional authentication method. (see slides for details) DOD would like to see SHA-2 used in an alternative mode. (see slides) This mode is already standard for RIPv2 (RFC 4822) and has been accepted by the ISIS WG. Proposal: OSPF WG should adopt the same cryptographic mode for SHA-2 authentication as RIP and ISIS. Acee: Authors of the I-D are not present - they need to consolidate. Acee: Confusion about header/trailer use. Too many authors on draft. Does anyone think going to new proposal a bad idea? - no hands were raised - Steve: Randall just wants change to draft - he doesn't need to be an author. Acee: Will follow up on list for work items. - end of meeting -