One document matched: draft-swallow-isis-detailed-reach-00.txt
Network Working Group Clarence Filsfils
Internet Draft Cisco Systems, Inc.
Category: Standards Track
Expiration Date: May 2008
Stefano Previdi
Cisco Systems, Inc.
George Swallow
Cisco Systems, Inc.
November 2007
IS-IS Detailed IP Reachability Extension
draft-swallow-isis-detailed-reach-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Abstract
This document defines a means for IS-IS to carry detailed host
reachability information along with summarized IP reachability.
In particular it defines a new sub-TLV of the extended IP
reachability TLV.
Swallow, et al. Standards Track [Page 1]
Internet Draft draft-swallow-isis-detailed-reach-00.txt November 2007
Contents
1 Introduction .............................................. 3
1.1 Conventions ............................................... 3
1.2 Terminology ............................................... 3
2 Background ................................................ 3
3 Overview .................................................. 4
4 Detailed Reachability Sub-TLV ............................. 5
4.1 Backward Compatibility .................................... 6
5 Semantics of detailed reachability ........................ 6
6 Open issues ............................................... 6
7 Security Considerations ................................... 7
8 IANA Considerations ....................................... 7
9 References ................................................ 7
9.1 Normative References ...................................... 7
9.2 Informative References .................................... 8
10 Authors' Addresses ........................................ 8
Swallow, et al. Standards Track [Page 2]
Internet Draft draft-swallow-isis-detailed-reach-00.txt November 2007
1. Introduction
The IS-IS protocol is specified in ISO-10589 [1], with extensions for
supporting IPv4 specified in RFC1195 [2]. The extended IP
reachability TLV is specified in RFC3784 [3]. This document defines
a sub-TLV of that TLV to allow detailed host reachability information
to be carried along with summarized IP reachability.
1.1. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [KEYWORDS].
1.2. Terminology
ABR Area border router
IGP Interior gateway protocol
RIB Routing information base
VPN Virtual private network
2. Background
IS-IS advertises routing/reachability information in link-state
packets within a domain. Currently no distinction is made between
routing and reachability. In the case of a host-route (/32 addresses
in the case of IPv4) this is not a problem as there can be no
ambiguity between routing and reachability. If a host is advertised
as reachable, then there is (except during a convergence period or in
very unusual circumstances) a routed path to that address. However,
when shorter prefixes are advertised as reachable, reachability to a
specific host address is hidden.
When reachability is summarized as it often is between levels,
detailed reachability information is lost. Such summarization is
critical to the scaling and convergence of the forwarding plane.
However, various control plane elements require host reachability
information (usually to PE loopback addresses) either for correct
action or to speed convergence. This level of detail very often is
not needed in the forwarding plane. But the current all-or-nothing
behavior of the IGPs leaves a network operator with a choice of
missing the benefits of summarization for IGP scalability or loosing
the benefits of detailed reachability information.
Swallow, et al. Standards Track [Page 3]
Internet Draft draft-swallow-isis-detailed-reach-00.txt November 2007
Among the control plane elements that could benefit from detailed
host-reachability information are BGP next-hop tracking and PIM.
The Border Gateway Protocol (BGP) advertises routes that are external
to the domain by associating them with a BGP next-hop address that is
known within the domain. Often multiple next-hops are available to
reach a particular prefix. If a prefix becomes unreachable, then BGP
will withdraw the route. Such withdrawals take time. In particular
if the advertising router goes down the withdrawal may be delayed
until the BGP TCP session times out.
In order to speed convergence routers employ a technique called next-
hop tracking. In next-hop tracking the reachability of the BGP next-
hop is tracked. If a next-hop becomes unreachable, BGP route
selection is run. External routes that are reachable through a known
alternative next-hop are then installed.
Currently if next-hop tracking is to be performed, the above
mentioned host-routes cannot be summarized. The proposed extension
allows the IGP routes to be summarized while distributing the
detailed reachability information needed for next-hop tracking.
PIM depends on the IGP reachability to the source of an (S, G) state
to determine its RPF interface. When PIM installs an (S, G) state
for the first time, it registers with the RIB for being notified of
any route change to S. Later on, if the route to S changes, RIB
immediately sends a notification to PIM.
3. Overview
In IS-IS IP reachability information may be carried in the extended
IP reachability TLV. The TLV carries an IP prefix and a prefix
length. This enables routes to be summarized to cover 2^n routes
where n is the difference between 32 and the prefix length. A
consequence of this summarization is that detailed reachability is
hidden.
This document defines a means to carry detailed reachability
information along with a summarized IP prefix. Host reachability
information is carried via a bit vector of 2^n bits. For example, if
an area that had 10.0.1.0/25 assigned as its address range and had
routes with loopbacks as follows
10.0.1.1 - 10.0.1.27
10.0.1.46
10.0.1.74 - 10.0.1.87
Swallow, et al. Standards Track [Page 4]
Internet Draft draft-swallow-isis-detailed-reach-00.txt November 2007
then the bit mask encoding would advertise a summary route to
10.0.1.0/25 with an associated 128-bit vector (shown in network
order) like this:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4. Detailed Reachability Sub-TLV
The detailed reachability sub-TLV is defined as a sub-TLV of the
extended IP reachability TLV. Its type is sub-TLV type [to be
assigned]. The sub-TLV length is the minimum number of octets
required to contain a bit vector with a length equal to the number of
IP addresses covered by the prefix contained in the parent extended
IP reachability TLV. If L stands for the sub-TLV length and p stands
for the prefix length then L = ceiling(2^(32-P)/8). The maximum
length of the value field of any sub-TLV is 247 octets. Since the
bit-vectors are always powers of 2 in length, the maximum bit-vector
that will fit is 128 octets. This is sufficient to handle a prefix
of 22 bits. Shorter prefixes cannot be expressed directly. Instead
they may be expressed by advertising as many 22 bit prefixes as are
contained within the longer prefix.
The value field encodes the bit vector where the high-order bit of
the first octet corresponds to zero, the low-order bit to seven, the
high-order bit of the second octet to eight and so forth. Each of
these values taken as a binary number and used as the low-order bit
of a 32 bit address formed with the prefix as the high-order bits
indicates a particular host route. A bit value of one indicates that
the associated host is reachable. A bit value of zero indicates that
the associated host is not reachable.
Swallow, et al. Standards Track [Page 5]
Internet Draft draft-swallow-isis-detailed-reach-00.txt November 2007
4.1. Backward Compatibility
As defined in RFC 3784, a sub-TLV which is not understood, is to be
ignored. Thus a router which does not understand the new sub-TLV
will behave as if it had simply received the summary route.
5. Semantics of detailed reachability
As stated above, detailed reachability is determined by the setting
of the bit associated with a specific host. When a router receives
the same summary route from two or more different routers the
following considerations apply.
If some of the advertisements contain the detailed reachability sub-
TLV while others do not, then detailed reachability MUST be
determined based solely on those advertisements containing the
detailed reachability sub-TLV.
If the advertisements contain differing bit vectors, then the router
SHOULD base reachability on the logical OR of the bits. In some
situations where aggressive recovery from failures is needed,
reachability MAY be based on the logical AND of the bits.
[Note this section is far from complete - a full description of how
bit-vectors are to be combined will involve considerations of metric
values and partition repair. See the open issues section below.]
6. Open issues
A number of issues remain open which, with input from the community,
will be refined in future versions of this draft.
o The IPv4 encoding defined in this draft allows for a minimum
prefix length of 22 bits due to the limitations of the sub-TLV
length. Shorter prefixes may be handled by advertising multiple
22 bit-prefixes. Is this sufficient for the community?
o The section on combining bit-vectors needs to be discussed in
greater detail. That discussion needs to include metrics and
partition repair.
Swallow, et al. Standards Track [Page 6]
Internet Draft draft-swallow-isis-detailed-reach-00.txt November 2007
o Beyond its other uses, the bit-vector opens the possibility of
automatic partition detection and repair. Two means of partition
repair have been discussed among the authors. These discussions
are preliminary and a full proposal will be put forward in a
future draft.
One potential means of partition repair consists of an L1L2
router auto-generating host routes for those hosts seen by that
router but not by all of the L1L2 routers serving the same area.
The other consists of building tunnels between the set of L1L2
routers serving an area and "shunting" packets destined to hosts
that are not seen by an L1L2 to a L1L2 router that is (via its
bit-vector) advertising reachability to that host.
7. Security Considerations
The detailed reachability sub-TLV does not change the information
that IS-IS can share with other routers, nor does it change the set
of routers to which the information is sent. It does RECOMMEND that
a router treat the information differently, delivering the detailed
reachability to the control plane while using the summary to scale
the forwarding plane. These changes however are not mandated. Thus
this extension to IS-IS poses no new security threats.
8. IANA Considerations
[to be written]
9. References
9.1. Normative References
[1] ISO, "Intermediate System to Intermediate System Intra-Domain
Routeing Exchange Protocol for use in Conjunction with the
Protocol for Providing the Connectionless-mode Network Service
(ISO 8473)", International Standard 10589:2002, Second Edition
[2] Callon, R.W., "Use of OSI IS-IS for routing in TCP/IP and dual
environments", RFC 1195, December 1990
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Swallow, et al. Standards Track [Page 7]
Internet Draft draft-swallow-isis-detailed-reach-00.txt November 2007
Requirement Levels", BCP 14, RFC 2119, March 1997.
9.2. Informative References
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual
Private Networks (VPNs)", RFC 4364, February 2006.
10. Authors' Addresses
Clarence Filsfils
Cisco Systems, Inc.
Email: cfilsfil@cisco.com
Stefano Previdi
Cisco Systems, Inc.
Email: sprevidi@cisco.com
George Swallow
Cisco Systems, Inc.
Email: swallow@cisco.com
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
Swallow, et al. Standards Track [Page 8]
Internet Draft draft-swallow-isis-detailed-reach-00.txt November 2007
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Full Copyright Notice
Copyright (C) The IETF Trust (2007). This document is subject to the
rights, licenses and restrictions contained in BCP 78, and except as
set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Swallow, et al. Standards Track [Page 9]
| PAFTECH AB 2003-2026 | 2026-04-23 16:14:33 |