Domain-Wide Prefix Distribution with Two-Level IS-IS
Draft of message to be sent after approval:
From: The IESG <firstname.lastname@example.org> To: IETF-Announce <email@example.com> Cc: Internet Architecture Board <firstname.lastname@example.org>, RFC Editor <email@example.com>, isis mailing list <firstname.lastname@example.org>, isis chair <email@example.com> Subject: Protocol Action: 'Domain-wide Prefix Distribution with Two-Level IS-IS' to Proposed Standard The IESG has approved the following document: - 'Domain-wide Prefix Distribution with Two-Level IS-IS ' <draft-ietf-isis-rfc2966bis-04.txt> as a Proposed Standard This document is the product of the IS-IS for IP Internets Working Group. The IESG contact persons are Ross Callon and David Ward. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isis-rfc2966bis-04.txt
Technical Summary 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. Working Group Summary This is part of a series of seven IS-IS RFCs that were originally published as informational for historic reasons, but that are now being updated to proposed standard. There is broad consensus in the WG for this change. Document Quality This document has been widely reviewed, and is implemented and deployed. Personnel Chris Hopps and Dave Ward have jointly worked as document shepherds for this bunch of seven documents. Ross Callon is the responsible AD. RFC Editor Note Please replace section 6 (Security Considerations) as follows: OLD 6. Security Considerations This document raises no new security issues for IS-IS. NEW 6. Security Considerations This document raises no new security issues for IS-IS; for general security considerations for IS-IS see [RFC3567bis]. Please add the following informative reference in section 8.2: [RFC3567bis] Li, T. and R. Atkinson, "Intermediate System to Intermediate System (IS-IS) Cryptographic Authentication", work in progress. Also please note that this last reference is within a few days of being approved, and it probably would be preferable to hold this document until you can publish both at the same time. Please update all references to [RFC3784] with references to [draft-ietf-isis-te-bis]. If I counted right, this includes five references in the regular text, plus the entry for 3784 in the informative references section. Please note that draft-ietf-isis-te-bis is within a few days of being approved, and it probably would be preferable to hold this document until you can publish both (and actually all seven IS-IS documents being progressed) at the same time. In section 2, third paragraph, second sentence: OLD However, to prevent routing-loops, L1L2 routers must not advertise L2->L1 inter-area routes that they learn via L1 routing, back into L2. NEW However, to prevent routing-loops, L1L2 routers MUST NOT advertise L2->L1 inter-area routes that they learn via L1 routing, back into L2. In section 4, third paragraph, first sentence: OLD Implementations that follow RFC 1195 should ignore bit 8 in the default metric field when computing routes. NEW Implementations that follow RFC 1195 SHOULD ignore bit 8 in the default metric field when computing routes.