cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements
Join Customer Connection to register!
3896
Views
5
Helpful
1
Replies
KATTUBAVA E.S
Beginner

OSPF Opaque LSA-9 & LSA-11

Hi,

RFC 5250 says the following regarding Opaque LSA, however I could see cisco routers just using LSA-10 for MPLS TE application for both Intra and Inter-Area TE tunnels. How can we generate LSA-9 and LSA-11 using cisco routers?

thanks

-bava

  The flooding scope associated with each Opaque link-state type is
   defined as follows.

   o  Link-state type-9 denotes a link-local scope.  Type-9 Opaque LSAs
      are not flooded beyond the local (sub)network.

   o  Link-state type-10 denotes an area-local scope.  Type-10 Opaque
      LSAs are not flooded beyond the borders of their associated area.

   o  Link-state type-11 denotes that the LSA is flooded throughout the
      Autonomous System (AS).  The flooding scope of type-11 LSAs are
      equivalent to the flooding scope of AS-External (type-5) LSAs.
1 REPLY 1
Peter Paluch
Hall of Fame Cisco Employee

Hi bava,

I do not think that what you request is possible - or necessary.

OSPFv2 Opaque LSAs exist in various flooding scopes to accomodate various applications and their needs. However, not all applications make use of all Opaque LSA types because some flooding scopes are not applicable for them.

Traffic Engineering extensions to OSPFv2 are one of those applications for which only area-wide flooding scope makes sense. If you have a close look at the nature of Traffic Engineering information carried by OSPF you will see that this information is extremely closely tied to the topology of a single area, in some ways duplicating the information present in LSA-1 and LSA-2:

https://tools.ietf.org/html/rfc3630

This information is basically tied to individual routers and their links. If this information leaked out from the very area these routers and links live, it would basically break the isolation between areas. After all, the RFC 3630 that defines TE extensions for OSPFv2 only defines them for intra-area application, and inter-area TE is not discussed there.

Cisco's implementation of inter-area TE tunnels also does not expect that the TE information about routers and links in one area is visible in a different area. This is evidenced by the fact that for inter-area TE tunnels, the dynamic path-option is not supported, and you need to define an explicit path with ABRs as loose next-hops.

Feel welcome to ask further!

Best regards,
Peter