draft-ietf-isis-ext-lsp-frags-02.txt   rfc3786.txt 
Network Working Group Amir Hermelin Network Working Group A. Hermelin
Internet Draft Charlotte's Web Networks Request for Comments: 3786 Montilio Inc.
Expiration Date: February 2003 Category: Informational S. Previdi
Stefano Previdi M. Shand
Mike Shand
Cisco Systems Cisco Systems
May 2004
Extending the Number of IS-IS LSP Fragments Beyond the 256 Limit Extending the Number of
Intermediate System to Intermediate System (IS-IS)
draft-ietf-isis-ext-lsp-frags-02.txt Link State PDU (LSP) Fragments Beyond the 256 Limit
Status
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Status of this Memo
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 This memo provides information for the Internet community. It does
and may be updated, replaced, or obsoleted by other documents at any not specify an Internet standard of any kind. Distribution of this
time. It is inappropriate to use Internet-Drafts as reference memo is unlimited.
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at Copyright Notice
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at Copyright (C) The Internet Society (2004). All Rights Reserved.
http://www.ietf.org/shadow.html.
Abstract Abstract
This document describes a mechanism that allows a system to originate This document describes a mechanism that allows a system to originate
more than 256 LSP fragments, a limit set by the original Intermediate more than 256 Link State PDU (LSP) fragments, a limit set by the
System to Intermediate System (IS-IS) Routing protocol, as described original Intermediate System to Intermediate System (IS-IS) Routing
in ISO 10589. This mechanism can be used in IP-only, OSI-only, and protocol, as described in ISO/IEC 10589. This mechanism can be used
dual routers. in IP-only, OSI-only, and dual routers.
Table of Contents
1. Introduction ................................................. 2
1.1. Keywords ............................................... 2
1.2. Definitions of Commonly Used Terms ..................... 2
1.3. Operation Modes ........................................ 3
1.4. Overview ............................................... 4
2. IS Alias ID TLV (IS-A) ....................................... 5
3. Generating LSPs .............................................. 6
3.1. Both Operation Modes ................................... 6
3.2. Operation Mode 1 Additives ............................. 8
4. Purging Extended LSP Fragments ............................... 10
5. Modifications to LSP handling in SPF ......................... 10
6. Forming Adjacencies .......................................... 11
7. Interoperating between extension-capable and non-capable ISs . 11
8. Security Considerations ...................................... 12
9. Acknowledgements ............................................. 12
10. References ................................................... 12
11. Authors' Addresses ........................................... 13
12. Full Copyright Statement ..................................... 14
1. Introduction 1. Introduction
In the IS-IS protocol, a system floods its link-state information in In the Intermediate System to Intermediate System (IS-IS) protocol, a
Link State Protocol Data Units, or LSPs for short. These logical system floods its link-state information in Link State PDU (LSP) Data
LSPs can become quite large, therefore the protocol specifies a means Units, or LSPs for short. These logical LSPs can become quite large,
of fragmenting this information into multiple LSP fragments. The therefore the protocol specifies a means of fragmenting this
number of fragments a system can generate is limited by ISO 10589 information into multiple LSP fragments. The number of fragments a
[ISIS-ISO] to 256 fragments, where each fragment's size is also system can generate is limited by ISO/IEC 10589 [ISIS-ISO] to 256
limited. Hence, there is a limit on the amount of link-state fragments, where each fragment's size is also limited. Hence, there
information a system can generate. is a limit on the amount of link-state information a system can
generate.
A number of factors can contribute to exceeding this limit: A number of factors can contribute to exceeding this limit:
- Introduction of new TLVs and sub-TLVs to be included in LSPs. - Introduction of new TLVs and sub-TLVs to be included in LSPs.
- The use of LSPs to propagate various types of information (such - The use of LSPs to propagate various types of information (such as
as traffic-engineering information). traffic-engineering information).
- The increasing number of destinations and AS topologies. - The increasing number of destinations and AS topologies.
- Finer granularity routing, and the ability to inject external - Finer granularity routing, and the ability to inject external
routes into areas [DOMAIN-WIDE]. routes into areas [DOMAIN-WIDE].
- Other emerging technologies, such as optical, IPv6, etc. - Other emerging technologies, such as optical, IPv6, etc.
This document describes mechanisms to relax the limit on the number This document describes mechanisms to relax the limit on the number
of LSP fragments. of LSP fragments.
1.1 Keywords 1.1. Keywords
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [BCP14]. document are to be interpreted as described in BCP 14, RFC 2119
[BCP14].
1.2 Definitions of Commonly Used Terms 1.2. Definitions of Commonly Used Terms
This section provides definitions for terms that are used throughout This section provides definitions for terms that are used throughout
the text. the text.
Originating System Originating System
A router physically running the IS-IS protocol. As this A router physically running the IS-IS protocol. As this
document describes methods allowing a single IS-IS process to document describes methods allowing a single IS-IS process to
advertise its LSPs as multiple "virtual" routers, the advertise its LSPs as multiple "virtual" routers, the
Originating System represents the single "physical" IS-IS Originating System represents the single "physical" IS-IS
process. process.
skipping to change at page 3, line 11 skipping to change at page 3, line 16
The system-id of an Originating System. The system-id of an Originating System.
Additional system-id Additional system-id
An Additional system-id that is assigned by the network An Additional system-id that is assigned by the network
administrator. Each Additional system-id allows generation of administrator. Each Additional system-id allows generation of
256 additional, or extended, LSP fragments. The Additional 256 additional, or extended, LSP fragments. The Additional
system-id, like the Normal system-id, must be unique throughout system-id, like the Normal system-id, must be unique throughout
the routing domain. the routing domain.
Virtual System Virtual System
The system, identified by an Additional system-id, advertised as The system, identified by an Additional system-id, advertised
originating the extended LSP fragments. These fragments specify as originating the extended LSP fragments. These fragments
the Additional system-id in their LSP IDs. specify the Additional system-id in their LSP IDs.
Original LSP Original LSP
An LSP using the Normal system-id in its LSP ID. An LSP using the Normal system-id in its LSP ID.
Extended LSP Extended LSP
An LSP using an Additional system-id in its LSP ID. An LSP using an Additional system-id in its LSP ID.
LSP set LSP set
Logical LSP. This term is used only to resolve the ambiguity Logical LSP. This term is used only to resolve the ambiguity
between a logical LSP and an LSP fragment, both of which are between a logical LSP and an LSP fragment, both of which are
sometimes termed "LSP". sometimes termed "LSP".
Extended LSP set Extended LSP set
A group of LSP fragments using an Additional system-id, and A group of LSP fragments using an Additional system-id, and
originated by the Originating System. originated by the Originating System.
Extension-capable IS Extension-capable IS
An IS implementing the mechanisms described in this document. An IS implementing the mechanisms described in this document.
1.3 Operation Modes 1.3. Operation Modes
Two administrative operation modes are provided: Two administrative operation modes are provided:
- Operation Mode 1 provides behavior that allows implementations - Operation Mode 1 provides behavior that allows implementations
that don't support this extension, to correctly process the that don't support this extension, to correctly process the
extended fragment information, without any modifications. This extended fragment information, without any modifications. This
mode has some restrictions on what may be advertised in the mode has some restrictions on what may be advertised in the
extended LSP fragments. Namely, only leaf information may be extended LSP fragments. Namely, only leaf information may be
advertised in the extended LSPs. advertised in the extended LSPs.
- Operation Mode 2 extends the previous mode and relaxes its - Operation Mode 2 extends the previous mode and relaxes its
advertisement restrictions. Any link-state information may be advertisement restrictions. Any link-state information may be
advertised in the extended LSPs. However, it mandates a change advertised in the extended LSPs. However, it mandates a change to
to the way LSPs are considered during the SPF algorithm, in a way the way LSPs are considered during the SPF algorithm, in a way
that isn't compatible with previous implementations. that is not compatible with previous implementations.
These modes are configured on a per-level and area basis. That is, These modes are configured on a per-level and area basis. That is,
all LSPs considered in the same SPF instance MUST use the same Mode. all LSPs considered in the same SPF instance MUST use the same Mode.
There is no restriction that an L1/L2 IS operates in the same mode, There is no restriction that an L1/L2 IS operates in the same mode,
for both its L1 and L2 instances. It can use Mode 1 for its L1 LSPs, for both its L1 and L2 instances. It can use Mode 1 for its L1 LSPs,
and Mode 2 for its L2 LSPs, or vice versa. and Mode 2 for its L2 LSPs, or vice versa.
Mode 1 has the only advantage of being backwards compatible with Mode 1 has the only advantage of being backwards compatible with
older implementations. It does have restrictions which are considered older implementations. It does have restrictions which are
drawbacks. Therefore, routers should operate in Mode 1 only if considered drawbacks. Therefore, routers should operate in Mode 1
backwards compatibility is desired. Otherwise, it is recommended to only if backwards compatibility is desired. Otherwise, it is
run in Mode 2. recommended to run in Mode 2.
Routers MAY implement Operational Mode 2 without supporting running Routers MAY implement Operational Mode 2 without supporting running
in Operational Mode 1. They will still interoperate correctly with in Operational Mode 1. They will still interoperate correctly with
routers that support both modes. routers that support both modes.
1.4 Overview 1.4. Overview
Using Additional system-ids assigned by the administrator, the Using Additional system-ids assigned by the administrator, the
Originating System can advertise the excess link-state information in Originating System can advertise the excess link-state information in
extended LSPs under these Additional system-ids. It would do so as extended LSPs under these Additional system-ids. It would do so as
if other routers, or "Virtual Systems", were advertising this if other routers, or "Virtual Systems", were advertising this
information. These extended LSPs will also have the specified limit information. These extended LSPs will also have the specified limit
on their LSP fragments; however, the Originating System may generate on their LSP fragments; however, the Originating System may generate
extended LSPs under numerous Virtual Systems. extended LSPs under numerous Virtual Systems.
For Operation Mode 1, 0-cost adjacencies are advertised from the For Operation Mode 1, 0-cost adjacencies are advertised from the
skipping to change at page 4, line 48 skipping to change at page 5, line 5
For both modes, each LSP (set) created by a node will contain in its For both modes, each LSP (set) created by a node will contain in its
fragment-0 a new TLV (IS Alias ID TLV) that contains the Normal fragment-0 a new TLV (IS Alias ID TLV) that contains the Normal
system-id and PN Number of the Original LSP created by the router. system-id and PN Number of the Original LSP created by the router.
Extension-capable ISs can then use this information and store the Extension-capable ISs can then use this information and store the
original and extended LSPs as one logical LSP. original and extended LSPs as one logical LSP.
The only sections that deal only with Mode 1 additions are 3.2, The only sections that deal only with Mode 1 additions are 3.2,
3.2.1, and 3.2.2. All other sections relate to both modes. 3.2.1, and 3.2.2. All other sections relate to both modes.
2.0 IS Alias ID TLV (IS-A) 2. IS Alias ID TLV (IS-A)
The proposed IS-A TLV allows extension-capable ISs to recognize all The proposed IS-A TLV allows extension-capable ISs to recognize all
LSPs of an Originating System, and combine the original and extended LSPs of an Originating System, and combine the original and extended
LSPs for the purpose of SPF computation. It identifies the Normal LSPs for the purpose of SPF computation. It identifies the Normal
system-id of the Originating System. system-id of the Originating System.
The proposed IS Alias ID TLV is type 24, and its format is as The proposed IS Alias ID TLV is type 24, and its format is as
follows: follows:
x CODE - 24. x CODE - 24.
skipping to change at page 5, line 33 skipping to change at page 5, line 36
+-------------------+ +-------------------+
| Sub-TLVs length | 1 | Sub-TLVs length | 1
+-------------------+ +-------------------+
| | 0-247 | | 0-247
: Sub-TLVs : : Sub-TLVs :
: : : :
| | | |
+-------------------+ +-------------------+
Normal system-id Normal system-id
The Normal system-id of the LSP set, as described in section 1.2 of The Normal system-id of the LSP set, as described in section 1.2
this document. of this document.
Pseudonode number Pseudonode number
The Pseudonode number of the LSP set. LSPs with the same Normal The Pseudonode number of the LSP set. LSPs with the same Normal
system-id and Pseudonode number are considered in SPF as one system-id and Pseudonode number are considered in SPF as one
logical LSP, as described in section 5 of this document. logical LSP, as described in section 5 of this document.
Sub-Tlvs length Sub-TLVs length
Total length of all sub-TLVs. Total length of all sub-TLVs.
Sub-TLVs Sub-TLVs
A series of tuples with the following format: A series of tuples with the following format:
No. of Octets No. of Octets
+-------------------+ +-------------------+
| Sub-type | 1 | Sub-type | 1
+-------------------+ +-------------------+
| Length | 1 | Length | 1
skipping to change at page 6, line 38 skipping to change at page 6, line 38
For an explanation on sub-TLV handling, see [ISIS-TE]. For an explanation on sub-TLV handling, see [ISIS-TE].
Without sub-TLVs, this structure consumes 8 octets per LSP set. This Without sub-TLVs, this structure consumes 8 octets per LSP set. This
TLV MUST be included in fragment 0 of every LSP set belonging to an TLV MUST be included in fragment 0 of every LSP set belonging to an
Originating System running in either Mode 1 or Mode 2. Currently, Originating System running in either Mode 1 or Mode 2. Currently,
there are no sub-TLVs defined. there are no sub-TLVs defined.
For a complete list of used IS-IS TLV numbers, see [ISIS-CODES]. For a complete list of used IS-IS TLV numbers, see [ISIS-CODES].
3.0 Generating LSPs 3. Generating LSPs
3.1 Both Operation Modes 3.1. Both Operation Modes
Under both modes, the Originating System MUST include information Under both modes, the Originating System MUST include information
binding the Original LSP and the Extended ones. It can do this since binding the Original LSP and the Extended ones. It can do this since
it is trivially an extension-capable IS. This is to ensure other it is trivially an extension-capable IS. This is to ensure other
extension-capable routers correctly process the extra information in extension-capable routers correctly process the extra information in
their SPF calculation. This binding is advertised via a new IS Alias their SPF calculation. This binding is advertised via a new IS Alias
ID TLV, which is advertised in all fragment 0 of Original and ID TLV, which is advertised in all fragment 0 of Original and
Extended LSPs. Extended LSPs.
+---------------------------------------------+ +---------------------------------------------+
skipping to change at page 7, line 17 skipping to change at page 7, line 17
| system-id = S | | system-id = S |
| is-alias-id = S | | is-alias-id = S |
+---------------------------------------------+ +---------------------------------------------+
+-------------------+ +-------------------+ +-------------------+ +-------------------+
| Virtual System | | Virtual System | | Virtual System | | Virtual System |
| system-id = S' | | system-id = S''| | system-id = S' | | system-id = S''|
| is-alias-id = S | | is-alias-id = S | | is-alias-id = S | | is-alias-id = S |
+-------------------+ +-------------------+ +-------------------+ +-------------------+
Figure 1. Advertising binding between all of a system's LSPs (both Figure 1. Advertising binding between all of a system's LSPs
modes). S' and S'' are configured as Additional system-ids. (both modes). S' and S'' are configured as Additional
system-ids.
When new extended LSP fragments are generated, these fragments should When new extended LSP fragments are generated, these fragments should
be generated as specified in ISO 10589 [ISIS-ISO]. Furthermore, a be generated as specified in ISO/IEC 10589 [ISIS-ISO]. Furthermore,
system SHOULD treat its extended LSPs the same as it treats its a system SHOULD treat its extended LSPs the same as it treats its
original LSPs, with the exceptions noted in the following sections. original LSPs, with the exceptions noted in the following sections.
Specifically, creating, flooding, renewing, purging and all other Specifically, creating, flooding, renewing, purging and all other
operations are similar for both Original and Extended LSPs, unless operations are similar for both Original and Extended LSPs, unless
stated otherwise. The Extended LSPs will use one of the Additional stated otherwise. The Extended LSPs will use one of the Additional
system-ids configured for the router, in their LSP ID. system-ids configured for the router, in their LSP ID.
Extended LSPs fragment zero should be regarded in the same special Extended LSPs fragment zero should be regarded in the same special
manner as specified in 10589 for LSPs with number zero, and should manner as specified in ISO/IEC 10589 for LSPs with number zero, and
include the same type of extra information as specified in 10589 and should include the same type of extra information as specified in
RFC 1195 [ISIS-IP]. So, for example, when a system reissues its LSP ISO/IEC 10589 and RFC 1195 [ISIS-IP]. So, for example, when a system
fragemnt zero due to an area address change, it should reissue all reissues its LSP fragment zero due to an area address change, it
extended LSPs fragment zero as well. should reissue all extended LSPs fragment zero as well.
An extended LSP fragment zero MUST be generated for every extended An extended LSP fragment zero MUST be generated for every extended
LSP set, to allow a router's SPF calculation to consider those LSP set, to allow a router's SPF calculation to consider those
fragments in that set. See section 5 for details. fragments in that set. See section 5 for details.
3.1.1 The Attached Bits 3.1.1. The Attached Bits
The Attached (ATT) bits SHOULD be set to zero for all four metric The Attached (ATT) bits SHOULD be set to zero for all four metric
types, on all Extended LSPs. This is due to the following: if a types, on all Extended LSPs. This is due to the following: if a
Virtual System is reachable, so is its Originating System. It is Virtual System is reachable, so is its Originating System. It is
preferable, then, that an L1 IS chooses the Originating System and preferable, then, that an L1 IS chooses the Originating System and
not the Virtual System as its nearest L2 exit point, as connectivity not the Virtual System as its nearest L2 exit point, as connectivity
to the Virtual System has a higher probability of being lost (as a to the Virtual System has a higher probability of being lost (as a
result of the extended LSP no longer being advertised). This could result of the extended LSP no longer being advertised). This could
cause unnecessary computations on some implementations. cause unnecessary computations on some implementations.
3.1.2 The Partition Repair Bit 3.1.2. The Partition Repair Bit
The Partition Repair (P) bit SHOULD be set to zero on all extended The Partition Repair (P) bit SHOULD be set to zero on all extended
LSPs. This is for the same reasons as for the Attached bits. LSPs. This is for the same reasons as for the Attached bits.
3.1.3 ES Neighbors TLV 3.1.3. ES Neighbors TLV
ISO 10589 [ISIS-ISO] section 7.3.7 specifies inserting an ES Neighbor ISO/IEC 10589 [ISIS-ISO] section 7.3.7 specifies inserting an ES
TLV in L1 LSPs, with the system ID of the router. RFC 1195 [ISIS-IP] Neighbor TLV in L1 LSPs, with the system ID of the router. RFC 1195
relieves IP-only routers of this requirement. However, for routers [ISIS-IP] relieves IP-only routers of this requirement. However, for
that do insert this ESN TLV in L1 LSPs (whether IP-only or OSI- routers that do insert this ESN TLV in L1 LSPs (whether IP-only or
capable), then in an extended LSP, the ESN TLV should include the OSI-capable), then in an extended LSP, the ESN TLV should include the
relevant Additional system-id. Furthermore, OSI-capable routers relevant Additional system-id. Furthermore, OSI-capable routers
should accept packets destined for this Additional system-id. should accept packets destined for this Additional system-id.
3.1.4 Overload Bit 3.1.4. Overload Bit
The overload bit should be set consistently across all LSPs, original The overload bit should be set consistently across all LSPs, original
and extended, belonging to an Originating System, and should reflect and extended, belonging to an Originating System, and should reflect
the Originating System's overload state. the Originating System's overload state.
3.1.5 Other Fields and TLVs 3.1.5. Other Fields and TLVs
Other fields and TLVs not mentioned above remain the same, both for Other fields and TLVs not mentioned above remain the same, both for
original and extended LSPs. original and extended LSPs.
3.2 Operation Mode 1 Additions 3.2. Operation Mode 1 Additions
The following additions apply only to routers generating LSPs in Mode The following additions apply only to routers generating LSPs in Mode
1. Routers, which are configured to operate in Operation Mode 2, 1. Routers, which are configured to operate in Operation Mode 2,
SHOULD NOT apply these additions to their advertisements. SHOULD NOT apply these additions to their advertisements.
Under Operation Mode 1, adjacencies from the Originating System to Under Operation Mode 1, adjacencies from the Originating System to
its Virtual Systems are advertised using the standard neighbor TLVs. its Virtual Systems are advertised using the standard neighbor TLVs.
The metric for these connections MUST be zero, since the cost of The metric for these connections MUST be zero, since the cost of
reaching a Virtual System is the same as the cost of reaching its reaching a Virtual System is the same as the cost of reaching its
Originating System. Originating System.
skipping to change at page 9, line 22 skipping to change at page 9, line 20
| /\ | /\ | /\ | /\
cost=0 | |cost=max-1 cost=0 | |cost=max-1 cost=0 | |cost=max-1 cost=0 | |cost=max-1
| | | | | | | |
\/ | \/ | \/ | \/ |
+-------------------+ +-------------------+ +-------------------+ +-------------------+
| Virtual System | | Virtual System | | Virtual System | | Virtual System |
| system-id = S' | | system-id = S''| | system-id = S' | | system-id = S''|
| is-alias-id = S | | is-alias-id = S | | is-alias-id = S | | is-alias-id = S |
+-------------------+ +-------------------+ +-------------------+ +-------------------+
Figure 2. Advertising connections to Virtual Systems under Operation Figure 2. Advertising connections to Virtual Systems under
Mode 1. S' and S'' are configured as Additional system-ids. Operation Mode 1. S' and S'' are configured as
Additional system-ids.
Under Operation Mode 1, only "leaf" information, i.e. information Under Operation Mode 1, only "leaf" information, i.e., information
that serves only as leaves in a shortest path tree, can be advertised that serves only as leaves in a shortest path tree, can be advertised
in extended LSPs. in extended LSPs.
When an Extended LSP belonging to Additional system-id S' is first When an Extended LSP belonging to Additional system-id S' is first
created, the Original LSP MUST specify S' as a neighbor, with metric created, the Original LSP MUST specify S' as a neighbor, with metric
set to zero. This in order to consider the cost of reaching the set to zero. This is in order to consider the cost of reaching the
Virtual System S' the same as the cost of reaching its Originating Virtual System S' the same as the cost of reaching its Originating
System. Furthermore, the Extended LSP MUST specify the Normal System. Furthermore, the Extended LSP MUST specify the Normal
system-id as a neighbor. The metric SHOULD be set to MaxLinkMetric - system-id as a neighbor. The metric SHOULD be set to MaxLinkMetric -
1 (this is only for uniformity purpose, any metric greater than zero 1 (this is only for uniformity purpose, any metric greater than zero
is ok). This in order to satisfy the two-way connectivity check on is acceptable). This in order to satisfy the two-way connectivity
other routers. Where relevant, this adjacency SHOULD be considered check on other routers. Where relevant, this adjacency SHOULD be
as point-to-point. considered as point-to-point.
Note, that the restriction specified in ISO 10589 section 7.2.5 Note, that the restriction specified in ISO/IEC 10589 section 7.2.5
holds: if an LSP Number zero of the Originating System is not holds: if an LSP Number zero of the Originating System is not
present, none of that system's neighbor entries would be processed present, none of that system's neighbor entries would be processed
during SPF, hence none of its extended LSPs would be processed as during SPF, hence none of its extended LSPs would be processed as
well. well.
3.2.1 IS Neighbors TLV (Mode 1 Only) 3.2.1. IS Neighbors TLV (Mode 1 Only)
An Extended LSP must specify only the Originating System as a An Extended LSP must specify only the Originating System as a
neighbor, with the metric set to (MaxLinkMetric - 1). Where neighbor, with the metric set to (MaxLinkMetric - 1). Where
relevant, this adjacency should be considered as point-to-point. relevant, this adjacency should be considered as point-to-point.
Other neighbors MUST NOT be specified in an Extended LSP, because Other neighbors MUST NOT be specified in an Extended LSP, because
those other neighbors would only specify the Originating System and those other neighbors would only specify the Originating System and
not the Virtual System, and hence would not satisfy the bi- not the Virtual System, and hence would not satisfy the bi-
directionality check in the SPF computation. directionality check in the SPF computation.
3.2.2 Originating System in the Overload State in (Mode 1 Only) 3.2.2. Originating System in the Overload State in (Mode 1 Only)
If the Originating System is in the overload state, information in If the Originating System is in the overload state, information in
the extended LSPs will not be processed by other routers in their SPF the extended LSPs will not be processed by other routers in their SPF
computation. This is because in Mode 1, extended LSPs are reachable computation. This is because in Mode 1, extended LSPs are reachable
only through adjacencies from the Original LSP. If this LSP has set only through adjacencies from the Original LSP. If this LSP has set
its OL bit, adjacencies will not be processed in the SPF computation. its OL bit, adjacencies will not be processed in the SPF computation.
This side effect should be taken into consideration when operating in This side effect should be taken into consideration when operating in
Mode 1. Mode 1.
4. Purging Extended LSP Fragments 4. Purging Extended LSP Fragments
ISO 10589 [ISIS-ISO] section 7.3.4.4 note 21 suggests that an ISO/IEC 10589 [ISIS-ISO] section 7.3.4.4 note 25 suggests that an
implementation keeps the number of LSP fragments within a certain implementation keeps the number of LSP fragments within a certain
limit based on the optimal (minimal) number of fragments needed. limit based on the optimal (minimal) number of fragments needed.
Section 7.3.4.6 also recommends that an IS purge its empty LSPs to Section 7.3.4.6 also recommends that an IS purge its empty LSPs to
conserve resources. These recommendations hold for the extended LSP conserve resources. These recommendations hold for the extended LSP
fragments as well. However, an extended LSP fragment zero should not fragments as well. However, an extended LSP fragment zero should not
be purged until all of the fragments in its set (i.e. belonging to a be purged until all of the fragments in its set (i.e., belonging to a
particular Additional system-id), are empty as well. This is to particular Additional system-id), are empty as well. This is to
ensure implementations consider the fragments in their SPF ensure implementations consider the fragments in their SPF
computations, as specified in section 7.2.5. computations, as specified in section 7.2.5.
In Operational Mode 1, when all the extended LSP fragments of a In Operational Mode 1, when all the extended LSP fragments of a
particular Additional system-id S' have been purged, the Originating particular Additional system-id S' have been purged, the Originating
System SHOULD remove the neighbor information to S' from its original System SHOULD remove the neighbor information to S' from its original
LSPs. LSPs.
5. Modifications to LSP handling in SPF 5. Modifications to LSP handling in SPF
This section describes modifications to the way extension-capable ISs This section describes modifications to the way extension-capable ISs
handle LSPs for the SPF computation. handle LSPs for the SPF computation.
When considering LSPs of an extension-capable IS (identified by the When considering LSPs of an extension-capable IS (identified by the
inclusion of the IS Alias ID TLV), the original and extended LSPs are inclusion of the IS Alias ID TLV), the original and extended LSPs are
combined to form one large logical LSP. If the LSP belongs to an IS combined to form one large logical LSP. If the LSP belongs to an IS
running Operational Mode 1, there might be adjacencies between the running Operational Mode 1, there might be adjacencies between the
original and extended LSPs. These are trivially ignored (since when original and extended LSPs. These are trivially ignored (since when
processing them the large logical LSP is already on PATHS), and processing them the large logical LSP is already on PATHS), and does
doesn't complicate the SPF. Furthermore, this check should already not complicate the SPF. Furthermore, this check should already be
be implemented (this scenario could occur on error, without this implemented (this scenario could occur on error, without this
extension). extension).
If LSP fragment 0 of the Original LSP set is missing or its If LSP fragment 0 of the Original LSP set is missing or its
RemainingLifetime is zero, all of the LSPs generated by that RemainingLifetime is zero, all of the LSPs generated by that
Originating System (Extended as well) MUST NOT be considered in the Originating System (Extended as well) MUST NOT be considered in the
SPF. That is, the large logical LSP isn't considered in the SPF. SPF. That is, the large logical LSP is not considered in the SPF.
The original LSP fragments are identified when the is-alias-id value The original LSP fragments are identified when the is-alias-id value
is the same as the system-id of those LSPs. If an LSP fragment 0 of is the same as the system-id of those LSPs. If an LSP fragment 0 of
an extended LSP set is missing or its RemainingLifetime is zero, only an extended LSP set is missing or its RemainingLifetime is zero, only
that LSP set MUST NOT be considered in the SPF. These rules are that LSP set MUST NOT be considered in the SPF. These rules are
present to ensure consistent SPF results on Mode 1 and Mode 2 LSPs. present to ensure consistent SPF results on Mode 1 and Mode 2 LSPs.
Note, that the above behavior is consistent with how previous Note, that the above behavior is consistent with how previous
implementations will interpret Mode 1 LSPs. implementations will interpret Mode 1 LSPs.
6. Forming Adjacencies 6. Forming Adjacencies
skipping to change at page 11, line 40 skipping to change at page 11, line 35
regardless of the Operational Mode. Of course, in Mode 1 this means regardless of the Operational Mode. Of course, in Mode 1 this means
that only the Normal system-id will be used when sending hellos. that only the Normal system-id will be used when sending hellos.
7. Interoperating between extension-capable and non-extension-capable 7. Interoperating between extension-capable and non-extension-capable
ISs. ISs.
In order to correctly advertise link-state information under In order to correctly advertise link-state information under
Operation Mode 2, all ISs in an area must be extension-capable. Operation Mode 2, all ISs in an area must be extension-capable.
However, it is possible to not upgrade every router in the network, However, it is possible to not upgrade every router in the network,
if the extended information is not routing information, but rather if the extended information is not routing information, but rather
data that is of use to only a subset of routers (e.g. optical data that is of use to only a subset of routers (e.g., optical
switches using ISIS could carry optical-specific information in switches using IS-IS could carry optical-specific information in
extended LSPs) extended LSPs)
If a live network contains routers exceeding the 256 fragment limit, If a live network contains routers exceeding the 256 fragment limit,
and for some reason the upgrade has to be done incrementally, it is and for some reason the upgrade has to be done incrementally, it is
possible to transition the network, using the following steps: possible to transition the network, using the following steps:
- Upgrade the routers, one-by-one, to run this extension in - Upgrade the routers, one-by-one, to run this extension in
Operation Mode 1. The other non-extension-capable routers will Operation Mode 1. The other non-extension-capable routers will
interoperate correctly. interoperate correctly.
- When all routers are extension-capable, configure them one-by-one - When all routers are extension-capable, configure them one-by-one
to run in Operation Mode 2. All extension-capable routers to run in Operation Mode 2. All extension-capable routers
interoperate correctly, regardless of what mode they're run in. interoperate correctly, regardless of what mode they are run in.
Implementations SHOULD support a configuration parameter controlling Implementations SHOULD support a configuration parameter controlling
the LSP origination behavior. The default value of this parameter the LSP origination behavior. The default value of this parameter
SHOULD correspond to the behavior described in [ISIS-ISO], i.e. SHOULD correspond to the behavior described in [ISIS-ISO], i.e.,
neither of the two modes described in this document should be enabled neither of the two modes described in this document should be enabled
without explicit configuration when the router software is upgraded without explicit configuration when the router software is upgraded
with this extension. with this extension.
8. Security Considerations 8. Security Considerations
This document raises no new security issues for IS-IS. This document raises no new security issues for IS-IS.
9. Acknowledgments 9. Acknowledgments
The authors would like to thank Tony Li and Radia Perlman for helpful The authors would like to thank Tony Li and Radia Perlman for helpful
comments and suggestions on the subject. comments and suggestions on the subject.
10. References 10. References
10.1 Normative References 10.1. Normative References
[ISIS-ISO] ISO 10589, "Intermediate System to Intermediate System [ISIS-ISO] "Intermediate System to Intermediate System Intra-
Intra-Domain Routeing Exchange Protocol for use in Conjunction with Domain Routeing Exchange Protocol for use in
the Protocol for Providing the Connectionless-mode Network Service Conjunction with the Protocol for Providing the
(ISO 8473)" Connectionless-mode Network Service (ISO 8473)",
ISO/IEC 10589:2002, Second Edition.
[ISIS-IP] RFC 1195, "Use of OSI IS-IS for routing in TCP/IP and dual [ISIS-IP] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
environments", R.W. Callon, Dec. 1990 dual environments", RFC 1195, December 1990.
[ISIS-TE] Work in progress, "IS-IS extensions for Traffic [ISIS-TE] Smit, H. and T. Li, "Intermediate System to
Engineering", T. Li, H. Smit Intermediate System (IS-IS) Extensions for Traffic
Engineering (TE)", RFC 3784, May 2004.
[BCP14] RFC 2119, "Key words for use in RFCs to Indicate Requirement [BCP14] Bradner, S., "Key words for use in RFCs to Indicate
Levels", S. Bradner, March 1997 Requirement Levels", BCP 14, RFC 2119, March 1997.
10.2 Informative References 10.2. Informative References
[DOMAIN-WIDE] RFC 2966, "Domain-wide Prefix Distribution with Two- [DOMAIN-WIDE] Li, T., Przygienda, T. and H. Smit, "Domain-wide Prefix
Level IS-IS", T. Li, T. Przygienda, H. Smit, October 2000 Distribution with Two-Level IS-IS", RFC 2966, October
2000.
[ISIS-CODES] Work in progress, "Reserved TLV Codepoints in ISIS", T. [ISIS-CODES] Przygienda, T., "Reserved Type, Length and Value (TLV)
Przygienda Codepoints in Intermediate System to Intermediate
System", RFC 3359, August 2002.
11. Authors' Addresses 11. Authors' Addresses
Amir Hermelin Email: amir@cwnt.com Amir Hermelin
Charlotte's Web Networks, Inc. Phone: +972 4 9592203 Montilio Inc.
2 Ha'mada St. Fax: +972 4 9593325 1 Maskit St.
POB 650 POB 12253
Yokneam, 20692 Herzelia, 46733
ISRAEL ISRAEL
Mike Shand, Email: mshand@cisco.com Phone: +972 9 9511944
Cisco Systems, Phone: +44 020 8824 8690 Fax: +972 9 9542430
4, The Square, EMail: amir@montilio.com
Stockley Park,
UXBRIDGE, Stefano Previdi
Middlesex, Cisco Systems, Inc.
UB11 1BN, Via Del Serafico 200
00142 Roma
Italy
Phone: +39 06 5164 4491
EMail: sprevidi@cisco.com
Mike Shand
Cisco Systems
250, Longwater Avenue,
Green Park,
Reading,
RG2 6GB,
UK UK
Stefano Previdi email: sprevidi@cisco.com Phone: +44 20 8824 8690
Cisco Systems, Inc. Phone: +32 2 7046590 EMail: mshand@cisco.com
De Kleetlaan 6A
1831 Diegem 12. Full Copyright Statement
Belgium
Copyright (C) The Internet Society (2004). 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 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.
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.
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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 

This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/