1 / 8

OSPF Protocol Extension

OSPF Protocol Extension. Acee Lindem/Cisco Systems. OSPF Extension Chronology. RFC 1247, RFC 1583, RFC 2178, and RFC 2328 – Evolution of base OSPFv2 protocol Area Hierarchy with full link state topology within an area 5 Basic LSA Types 32 bit aligned fields

nodin
Download Presentation

OSPF Protocol Extension

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. OSPF Protocol Extension Acee Lindem/Cisco Systems OSPF WG – IETF 62

  2. OSPF Extension Chronology • RFC 1247, RFC 1583, RFC 2178, and RFC 2328 – Evolution of base OSPFv2 protocol • Area Hierarchy with full link state topology within an area • 5 Basic LSA Types • 32 bit aligned fields • RFC 1584 - MOSPF adds Multicast trees and Type 6 LSAs • RFC 1583 Adds NSSAs and Type 7 LSAs OSPF WG – IETF 62

  3. OSPF Extension Chronology • RFC 2370 – Adds Opaque LSAs with flooding scope built into types. Backward compatible introduction of new LSAs. • RFC 2740 – OSPFv3 • Generalized flooding of unknown LSAs • LSID no longer denotes route prefix • Separation of intra-area topology and prefix information • RFC 3623 – OSPFv2 Graceful Restart – Uses link scoped opaque LSA. • RFC 3630 – OSPFv2 Traffic Engineering Uses area scoped LSAs • OSPFv2 MTR – Reuses TOS routing metrics OSPF WG – IETF 62

  4. Future OSPF Expansion Options • Option #1 – Continue adding new LSA types for OSPFv3 and new opaque types for OSPFv2. • Option #2 – Go to TLV based approach with everything in one or two advertisements (ala ISIS). • Option #3 – Evolve to TLV based approach based on existing LSA types – draft-mirtorabi-mt-ospfv3-01.txt OSPF WG – IETF 62

  5. Options #1 Advantages • Advertisements contain only what changes – although this is already skewing with OSPFv2 MTR. • Potentially smaller LSAs • Maintains status quo – we don’t change the way we are moving. OSPF WG – IETF 62

  6. Option #3 Advantages • No synchronization issues between LSAs. Fewer lookups and less searching • Flexible extension while still maintaining reasonable LSA granularity • Fewer LSAs to manage – Less header overhead • Unified approach for protocol extension • Most important :^) – Other IGPs will no longer be able to say we’re inflexible OSPF WG – IETF 62

  7. OSPF WG Vision – Single IP IGP Enterprise/ISP/Wireless Networks OSPFv3 MANET Multi-AF/MTR TLV Extensions OSPFv3 Base OSPF WG – IETF 62

  8. Given Option #3 – Questions?? • What about OSPFv2 in the near future? • Could extend like OSPFv2 using opaque LSAs and TLVs and gain the same benefits • Trade-off of requirements versus duplication of effort • How do we avoid protocol bloat? OSPF WG – IETF 62

More Related