ietf-corpus

rfc-5786

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

R. Aggarwal, K. Kompella
date2010-03 streamIETF areartg wgospf statusPROPOSED STANDARD pages7 canonicalhttps://www.rfc-editor.org/rfc/rfc5786 doi10.17487/RFC5786 errataview
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]

updated by

updates

Extracted elements (15)

design-rationale §3

Advertising a TE link TLV for each local address (possibly with a new link type) was rejected as inefficient because the only meaningful information is the address itself, and it would require implementations to treat those TLVs specially — for instance, the TE metric sub-TLV would be mandatory yet meaningless for a local address.

routing

design-rationale §1.1

OSPFv2 stub links in the router LSA and OSPFv3 intra-prefix LSAs are insufficient to learn all local addresses of a router; for subnetted P2P interfaces the stub link ID is the subnet address, and for non-subnetted interfaces it is the neighbor address, so neither reliably identifies loopback or non-TE interface addresses needed for CSPF-computed MPLS TE LSPs.

routing, mpls

interoperability-note §1.1

Current OSPF TE implementations (prior to this document) can only populate their Traffic Engineering Database with the router ID and local addresses of TE-enabled links; loopback and non-TE interface addresses are not distributed, preventing CSPF computation of MPLS TE LSPs to those addresses. This document extends RFC 3630 to close that gap.

routing, mpls

normative-requirement §4.2 MUST NOT

A Node Attribute TLV MUST NOT carry more than one Node IPv4 Local Address sub-TLV, and MUST NOT carry more than one Node IPv6 Local Address sub-TLV.

routing

normative-requirement §6 MUST

Before any assignments can be made in sub-TLV type range 32778–65535, there MUST be a Standards Track RFC that specifies IANA Considerations covering that range.

routing, registry

normative-requirement §4.1 MUST

Each local IPv6 address MUST be represented by a combination of three fields: PrefixLength, PrefixOptions, and Address Prefix, following RFC 5340 encoding procedures.

routing, ip

normative-requirement §6 MUST NOT

Experimental sub-TLV types in the range 32768–32777 MUST NOT be mentioned by RFCs; they are for experimental use only and will not be registered with IANA.

routing, registry

normative-requirement §4.2 SHOULD NOT

Local addresses that can already be learned from TE LSAs — specifically the router address and TE interface addresses — SHOULD NOT be re-advertised in the Node IPv4 or IPv6 Local Address sub-TLVs to avoid duplication.

routing

normative-requirement §4.2 MAY

The default behavior for a router MAY be to advertise all loopback interface addresses in the Node Attribute TLV; the actual set of addresses advertised depends on local configuration.

routing

normative-requirement §4.2 MUST NOT

The Node Attribute TLV MUST NOT appear in more than one TE LSA originated by a router, and such an LSA MUST NOT include more than one Node Attribute TLV, ensuring a single authoritative advertisement per router.

routing

protocol-element §4.1

The Node Attribute TLV (type 5, variable length) is a new top-level TLV in OSPF TE LSAs that carries attributes associated with a router, including its local addresses. It contains one or more sub-TLVs; this document defines sub-TLV type 1 (Node IPv4 Local Address) and sub-TLV type 2 (Node IPv6 Local Address).

routing

registry §6

IANA assigned type value 5 to the Node Attribute TLV from the top-level types in TE LSAs registry (range 3–32767, per RFC 3630). IANA also created a sub-registry for sub-TLVs of the Node Attribute TLV: value 1 is Node IPv4 Local Address, value 2 is Node IPv6 Local Address, types 3–32767 require Standards Action, types 32768–32777 are experimental (not to be mentioned in RFCs), and types 32778–65535 are unassigned pending a future Standards Track RFC.

routing, registry

security-consideration §5

This document does not introduce any security issues beyond those already discussed in RFC 3630 (OSPF TE extensions for OSPFv2) and RFC 5329 (TE extensions for OSPFv3); no additional mitigations are required.

security, routing

wire-format §4.1

The Node IPv4 Local Address sub-TLV (type 1) encodes one or more local IPv4 addresses as a sequence of <Prefix Length, Prefix> tuples: Prefix Length is 1 byte (max 32), and Prefix is 4 bytes zero-padded. The sub-TLV length is the sum of all n IPv4 address encoding lengths in octets.

routing, ip

wire-format §4.1

The Node IPv6 Local Address sub-TLV (type 2) encodes each local IPv6 address using OSPFv3 procedures as a three-field tuple: PrefixLength (8 bits), PrefixOptions (8 bits, per RFC 5340), and Address Prefix encoded as an even multiple of 32-bit words with zero padding, consuming ceil((PrefixLength + 31) / 32) 32-bit words.

routing, ip, v6ops