OSPF Routing with Cross-Address Family Traffic Engineering Tunnels
updates
- rfc-5786 — Advertising a Router's Local Addresses in OSPF Traffic Engineering (TE) Extensions
Extracted elements (15)
Common MPLS TE LSPs shared across IPv4 and IPv6 traffic halve the number of LSPs in the network, reducing scalability and management concerns, and allow operators to group traffic by business characteristics or class of service independent of network protocol.
Using the same Router ID across OSPFv2 and OSPFv3 instances was considered as a solution for X-AF mapping but rejected because it relies on correct configuration, provides no mechanism to detect misalignment, and misaligned Router IDs can cause traffic delivery to the wrong tail-end router, leading to suboptimal routing or traffic loops.
RFC 6827 (ASON routing for OSPFv2) updates RFC 5786 by defining use of the Local TE Router ID sub-TLV; if this sub-TLV is present in the Node Attribute TLV, the RFC 6827 procedures apply regardless of whether any X-AF information is also advertised.
An implementation MAY advertise other local X-AF addresses beyond those listed in the X-AF instance's Router Address TLV and additional local address sub-TLVs.
An OSPF instance performing X-AF advertisement SHOULD include additional local addresses advertised by the X-AF OSPF instance in its Node Local Address sub-TLVs.
Both the head-end and tail-end tunnel endpoints MUST be upgraded before the tail end begins advertising X-AF information to ensure the head end can correctly interpret and use the advertised addresses.
Each OSPF instance advertising X-AF information MUST advertise the IP address listed in the Router Address TLV of the X-AF instance that maintains the TE database.
On Area Border Routers (ABRs), each advertised X-AF IP address MUST be advertised into at most one area to ensure unambiguous area association for computed MPLS TE tunnels.
Only routers that serve as endpoints (head-end or tail-end) for one or more TE tunnels MUST be upgraded to support the X-AF procedures; other routers in the network do not need to support X-AF.
When OSPFv2 and OSPFv3 ABRs coincide (the same set of areas for all interfaces), X-AF addresses MUST be advertised into the same area in both instances so that other ABRs can correctly associate computed MPLS TE tunnels with the appropriate area.
OSPFv3 advertises the Node IPv4 Local Address sub-TLV (from RFC 5786) to carry the router's local IPv4 addresses into the OSPFv3 TE database, enabling IPv4-destined LSP tail-end identification via an OSPFv3-maintained TE infrastructure.
The X-AF routing calculation walks all MPLS TE tunnels headed by the computing router; for each X-AF tunnel, it searches all connected areas' LSDBs for a matching destination IP in a Node Local Address sub-TLV, then marks the tunnel as belonging to the area and tail-end router that advertised the matching address, assigning the intra-area SPF cost as the IGP cost of the tunnel.
To implement X-AF routing, OSPFv2 advertises the Node IPv6 Local Address sub-TLV (from RFC 5786) to carry the router's local IPv6 addresses into the OSPFv2 TE database, enabling IPv6-destined LSP tail-end identification via an OSPFv2-maintained TE infrastructure.
Advertising X-AF Local Address sub-TLVs introduces no new security threats beyond those already present in OSPFv2 (RFC 2328), OSPFv3 (RFC 5340), and RFC 5786, because the advertisement of these sub-TLVs in any OSPF instance is not precluded by RFC 5786.
Generating incorrect X-AF sub-TLV information or tampering with it may cause TE traffic to be delivered to the wrong tail-end router, leading to suboptimal routing, traffic loops, or exposure of traffic to attacker inspection or modification; these threats parallel those in RFC 3630 and RFC 5329.