RFC 5786-2010
Advertising a Router’s Local Addresses in OSPF Traffic Engineering (TE) Extensions (Updates: 3630)

Standard No.
RFC 5786-2010
Release Date
2010
Published By
IETF - Internet Engineering Task Force
Latest
RFC 5786-2010
Scope
Introduction Motivation In some cases@ it is desirable to set up constrained shortest path first (CSPF) computed Multiprotocol Label Switching (MPLS) Traffic Engineered Label Switched Paths (TE LSPs) to local addresses of a router that are not currently advertised in the TE LSAs@ i.e.@ loopback and non-TE interface addresses. For instance@ in a network carrying VPN and non-VPN traffic@ it is often desirable to use different MPLS TE LSPs for the VPN traffic and the non-VPN traffic. In this case@ one loopback address may be used as the BGP next-hop for VPN traffic while another may be used as the BGP next-hop for non-VPN traffic. It is also possible that different BGP sessions are used for VPN and non-VPN services. Hence@ two separate MPLS TE LSPs are desirable -- one to each loopback address. However@ current routers in an OSPF network can only use CSPF to compute MPLS TE LSPs to the router ID or the local addresses of a remote router's TE-enabled links. This restriction arises because OSPF TE extensions [RFC3630@ RFC5329] only advertise the router ID and the local addresses of TE-enabled links of a given router. Other routers in the network can populate their traffic engineering database (TED) with these local addresses belonging to the advertising router. However@ they cannot populate the TED with the advertising router's other local addresses@ i.e.@ loopback and non-TE interface addresses. OSPFv2 stub links in the router LSA [RFC2328] provide stub reachability information to the router but are not sufficient to learn all the local addresses of a router. In particular for a subnetted point-to-point (P2P) interface the stub@ link ID is the subnet address. While for a non-subnetted interface@ the stub link ID is the neighbor address. Intra-prefix LSAs in OSPFv3 [RFC5340] are also not sufficient to learn the local addresses. For the above reasons@ this document defines an enhancement to OSPF TE extensions to advertise the local addresses of a node.

RFC 5786-2010 history

  • 2010 RFC 5786-2010 Advertising a Router’s Local Addresses in OSPF Traffic Engineering (TE) Extensions (Updates: 3630)



Copyright ©2024 All Rights Reserved