UpdatedPROPOSED STANDARDIETF stream

RFC 5786: Advertising a Router's Local Addresses in OSPF Traffic Engineering (TE) Extensions

Still current, but amended. Parts of this document are changed or extended by RFC 6827, RFC 8687. Read both.

In plain English — editorial summary, not part of the RFC

OSPF Traffic Engineering (TE) extensions are used to advertise TE Link State Advertisements (LSAs) containing information about TE-enabled links. The only addresses belonging to a router that are advertised in TE LSAs are the local addresses corresponding to TE-enabled links, and the local address corresponding to the Router ID. In order to allow other routers in a network to compute Multiprotocol Label Switching (MPLS) Traffic Engineered Label Switched Paths (TE LSPs) to a given router's local addresses, those addresses must also be advertised by OSPF TE. This document describes procedures that enhance OSPF TE to advertise a router's local addresses. [STANDARDS-TRACK]

Document record

Document ID
RFC5786
Published
March 2010
Authors
R. Aggarwal; K. Kompella
Status
PROPOSED STANDARD
Stream
IETF
Area
rtg
Pages
7
Also known as
Updates:
RFC 3630
Updated by:
RFC 6827, RFC 8687

Referenced by

2 later RFCs formally update or obsolete part of this document.

Related documents

Ranked automatically by shared keywords, IETF area and stream — not by editorial selection.

Also filed under

About this page

The document record above — title, authors, date, status, stream, area, relationships, DOI and errata — is imported verbatim from the public RFC Editor index. The “in plain English” section is editorial: written by The metasystema editorial team, not part of the RFC. Where the two differ, the RFC text governs.

Last checked against the RFC Editor index on . RFCs are never revised after publication; changes are issued as new documents.

Data sources · Editorial policy · Report a correction · What is an RFC?

canonical URL: /rfc/5786-advertising-a-router-s-local-addresses-in-ospf-traffic-engineering-te-extensions