ietf-corpus

rfc-5302

Domain-Wide Prefix Distribution with Two-Level IS-IS

T. Li, H. Smit, T. Przygienda
date2008-10 streamIETF areartg wgisis statusPROPOSED STANDARD pages16 canonicalhttps://www.rfc-editor.org/rfc/rfc5302 doi10.17487/RFC5302 errataview
This document describes extensions to the Intermediate System to Intermediate System (IS-IS) protocol to support optimal routing within a two-level domain. The IS-IS protocol is specified in ISO 10589, with extensions for supporting IPv4 (Internet Protocol) specified in RFC 1195. This document replaces RFC 2966. This document extends the semantics presented in RFC 1195 so that a routing domain running with both level 1 and level 2 Intermediate Systems (IS) (routers) can distribute IP prefixes between level 1 and level 2, and vice versa. This distribution requires certain restrictions to ensure that persistent forwarding loops do not form. The goal of this domain-wide prefix distribution is to increase the granularity of the routing information within the domain. [STANDARDS-TRACK]

obsoletes

updates

Extracted elements (20)

design-rationale §1.1

Domain-wide prefix distribution is motivated by three needs: (1) optimal route computation when prefix summarization loses information, (2) accurate IGP metrics for BGP shortest-exit routing, and (3) accurate IS-IS metrics for BGP MED values across a multi-area domain. RFC 1195 summarization causes suboptimal routing because L2 routers lack intra-area topology detail.

routing, bgp

design-rationale §1.2

Domain-wide prefix distribution trades scalability for optimality: it increases memory consumption, transmission requirements, and SPF computation throughout the domain, though it does not affect the first aspect of IS-IS scalability (area-based LSP containment). Administrators should provision and monitor networks accordingly.

routing

design-rationale §3.2

IS-IS cannot rely on metrics alone for route selection because inter-area routes can only be advertised with a maximum metric of 63, and this maximum does not mean infinity (unlike RIP hop count 16). Introducing an infinity value would cause counting-to-infinity behavior via multiple L1L2 routers, degrading network stability.

routing

interoperability-note §4

Older RFC 1195 implementations that do not recognize the up/down bit will treat L2->L1 inter-area routes as L1 intra-area routes and re-advertise them into L2, causing routing loops. It is therefore RECOMMENDED that L2->L1 advertisement be disabled by default and manually enabled only when all L1L2 routers in an area understand the up/down bit.

routing

interoperability-note §4

RFC 1195-compliant implementations that do not accept TLV 130 in L1 LSPs will be unable to compute external L1 routes, potentially causing routing loops between L1-only routers that understand external L1 routes and those that rely on the default route to the nearest L1L2 router.

routing

interoperability-note §5

RFC 5305 defines new TLVs (135 for IP prefixes, new link TLV) with wider metric space and sub-TLV extensibility, which subsumes the up/down functionality defined here. However, RFC 5305 requires a network-wide upgrade, whereas this document's solution requires only upgrading L1L2 routers in selected areas.

routing

normative-requirement §2.1 MUST

IP routes advertised in 'IP External Reachability Information' (TLV 130) with the external metric-type MUST be given less preference than the same IP routes advertised with the internal metric-type, regardless of the metric values.

routing

normative-requirement §3.3 RECOMMENDED

It is RECOMMENDED that the default configuration of L1L2 routers not advertise any L2 routes into L1. Implementations SHOULD force the network administrator to manually configure L1L2 routers to advertise any L2 routes into L1.

routing

normative-requirement §2 MUST NOT

L1L2 routers MUST NOT advertise L2->L1 inter-area routes (those with the up/down bit set, learned via L1 routing) back into L2. This restriction prevents persistent forwarding loops.

routing

normative-requirement §2 MUST

L1L2 routers MUST set the up/down bit to one for prefixes derived from L2 routing that are advertised into L1 LSPs. The bit MUST be set to zero for all other IP prefixes in L1 or L2 LSPs.

routing

normative-requirement §3.3 SHOULD

L1L2 routers SHOULD only advertise in their L2 LSP those L1 routes that they use for forwarding themselves. They SHOULD NOT unconditionally advertise into L2 all prefixes from LSPs in the L1 database.

routing

normative-requirement §3.3 MUST

The combination of 'IP Internal Reachability Information' (TLV 128) with external metric-type SHOULD NOT be used when building an LSP. Upon receipt of an IP prefix with this combination, routers MUST ignore this prefix.

routing

normative-requirement §3.3 MUST NOT

The up/down bit MUST NOT be set in L2 LSPs under the current two-level hierarchy. However, implementations are RECOMMENDED to ignore the up/down bit in L2 LSPs to allow simpler migration if IS-IS is ever extended with more than two levels of hierarchy.

routing

normative-requirement §2.2 SHOULD

When an L1L2 router advertises an L1 route into L2, where that L1 route was learned via TLV 130 ('IP External Reachability Information'), it SHOULD advertise the prefix in its L2 LSP within TLV 130. L1 routes learned via TLV 128 SHOULD still be advertised within TLV 128.

routing

normative-requirement §2.1 MUST

When computing IP routes, routers MUST give equal preference to IP routes advertised in TLV 128 ('IP Internal Reachability Information') and TLV 130 ('IP External Reachability Information'), consistent with RFC 1195 paragraph 3.10.2 item 2c. This document does not alter this rule.

routing

protocol-element §3.1

Eight distinct IP advertisement types are defined for IS-IS LSPs, combining: LSP level (L1 or L2), TLV type (128=internal or 130=external route-type), metric-type bit (internal or external), and up/down bit. The combination of TLV 128 with external metric-type is invalid.

routing

protocol-element §3.1

L1->L2 inter-area routes are advertised in L2 LSPs in TLV 128 with the up/down bit set to zero and internal metric-type; they are indistinguishable from L2 intra-area routes. L2->L1 inter-area routes are advertised in L1 LSPs in TLV 128 with the up/down bit set to one.

routing

protocol-element §3.2

Six levels of route preference are defined: (1) L1 intra-area/external with internal metric; (2) L2 intra-area, L2 external, L1->L2 inter-area routes with internal metric; (3) L2->L1 inter-area routes with internal metric; (4) L1 external with external metric; (5) L2 external and L1->L2 inter-area external with external metric; (6) L2->L1 inter-area external with external metric.

routing

security-consideration §6

This document raises no new security issues for IS-IS. General security considerations for IS-IS, including cryptographic authentication, are addressed in RFC 5304.

routing, security

wire-format §2

This document redefines the high-order bit (bit 8) of the default Metric field in TLVs 128 and 130 as the 'up/down bit'. Previously reserved and set to zero, this bit now signals L2->L1 inter-area routes. It is a single bit within the 1-byte default metric sub-field of the 4-byte TOS metric field.

routing