1 / 7

OSPF Opaque LSA Option Update for Enhanced Validation

This draft proposes updates to enhance OSPF AS-scope (type 11) Opaque LSA validation. Issues addressed, solutions presented, and changes from RFC2370 outlined. Emphasizes ASBR treatment, validation mechanism, and integration with area-scope LSAs. Detailed process for routers originating and validating LSAs provided, including E-bit setting and routing table lookup. Future steps include WG feedback, terminology review, and potential additional changes for adoption as a WG document.

psherrie
Download Presentation

OSPF Opaque LSA Option Update for Enhanced Validation

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. Update to:The OSPF Opaque LSA Option draft-berger-ospf-rfc2370bis Lou Berger (lberger@labn.net) Igor Bryskin (ibryskin@advaoptical.com) Alex Zinin (zinin@psg.com) Original Author: Rob Coltun

  2. Draft Background • There is no way for OSPF routers to validate OSPF AS-scope (type 11) Opaque LSAs received outside of the LSA originator’s area • Issue presented / addressed indraft-bryskin-ospf-lsa-type11-validation • Presented at last IETF OSPF WG • Conclusion from last WG meeting: Rev RFC2370 2

  3. Changes In Draft From RFC2370 • Updated draft format • Adopted RFC2119 terminology • Key words "MUST", "MUST NOT", "REQUIRED", … • Requires WG review – no issues expected • Added “Routers processing opaque LSAs MAY choose to give priority to processing base OSPF LSA types over opaque LSA types.” • Added reference to draft-ietf-ospf-mib-update- • Added Inter-Area Considerations • From draft-bryskin-ospf-lsa-type11-validation • Removed reference to expired drafts 3

  4. Inter-Area Solution As presented at last IETF: • Parallels and reuses the mechanism for validation of OSPF type 5 LSAs • Validation of type-5 LSAs • AS external route (type-5) LSAs have also the AS-scope, hence there is a similar problem with their validation • The problem is addressed via use of area-scope ASBR-summary (type-4) LSAs originated by ABRs for every known ASBR • The validation of AS-scope (type-11) opaque LSAs could be achieved if ABRs treat their originators as ASBRs 4

  5. Inter-Area Solution (cont) • LSA origination changes • Routers that originate AS-scope opaque LSAs also set the E-bit in the Options field of originated OSPF Hello packets • Such Routers also set the E-bit in the Options field of the header of each LSA it injects into the network • LSA validation changes • Router MUST look up the routing table for the ASBR with the Router ID matching the Advertising Router ID found in the received LSA header. • If no entries could be found (i.e., ASBR is unreachable), the router ignores the LSA. • A router MUST discontinue using ALL Opaque LSAs originated by a router that is identified as being unreachable 5

  6. Next Steps • WG Feedback • Review of RFC2119 terminology • Any other changes needed? • Adoption as WG document 6

  7. Thank You

More Related