draft-ietf-mpls-nodeid-subobject-02.txt   draft-ietf-mpls-nodeid-subobject-03.txt 
Jean Philippe Vasseur (Editor) Jean Philippe Vasseur (Editor)
Zafar Ali Zafar Ali
Siva Sivabalan Siva Sivabalan Formatted:
Cisco Systems, Inc. Cisco Systems, Inc.
IETF Internet Draft IETF Internet Draft
Expires: July, 2004 Expires: July, 2005
January, 2004 January, 2005
draft-ietf-mpls-nodeid-subobject-02.txt draft-ietf-mpls-nodeid-subobject-03.txt
Definition of an RRO node-id subobject Definition of an RRO node-id subobject
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with all By submitting this Internet-Draft, I certify that any applicable patent
provisions of Section 10 of RFC2026. Internet-Drafts are or other IPR claims of which I am aware have been disclosed, and any of
which I become aware will be disclosed, in accordance with RFC 3668.
Working documents of the Internet Engineering Task Force (IETF), its Working documents of the Internet Engineering Task Force (IETF), its
areas, and its working groups. Note that other groups may also areas, and its working groups. Note that other groups may also
distribute working documents as Internet-Drafts. distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress." or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
skipping to change at line 45 skipping to change at line 47
Abstract Abstract
In the context of MPLS TE Fast Reroute, the Merge Point (MP) address is In the context of MPLS TE Fast Reroute, the Merge Point (MP) address is
required at the Point of Local Repair (PLR) in order to select a backup required at the Point of Local Repair (PLR) in order to select a backup
tunnel intersecting a fast reroutable Traffic Engineering LSP on a tunnel intersecting a fast reroutable Traffic Engineering LSP on a
downstream LSR. However, existing protocol mechanisms are not downstream LSR. However, existing protocol mechanisms are not
sufficient to find an MP address in multi-areas or multi-domain routing sufficient to find an MP address in multi-areas or multi-domain routing
networks. Hence, the current MPLS Fast Reroute mechanism cannot be used networks. Hence, the current MPLS Fast Reroute mechanism cannot be used
to protect inter-area or inter-AS TE LSPs from a failure of an ABR to protect inter-area or inter-AS TE LSPs from a failure of an ABR
(Area Border Router) or ASBR (Autonomous System Border Router) (Area Border Router) or ASBR (Autonomous System Border Router)
respectively. This document specifies the use of existing RRO IPv4 and respectively. Such functionality has been listed as a clear requirement
IPv6 subobjects (with a new flag defined) to define the node-id in [INTER-AREA-TE-REQS] and [INTER-AS-TE-REQS]. This document specifies
subobject in order to solve this issue. Note that the MPLS Fast reroute the use of existing RRO IPv4 and IPv6 subobjects (with a new flag
mechanism mentioned in this document refers to the "Facility backup" defined) to define the node-id subobject in order to solve this issue.
MPLS TE Fast Reroute method. Note that the MPLS Fast reroute mechanism mentioned in this document
refers to the "Facility backup" MPLS TE Fast Reroute method.
Table of content
1. Terminology .................................................. 2
2. Introduction ................................................. 3
3. Signaling node-ids in RROs ................................... 5
4. Finding Merge Point .......................................... 6
5. Security Considerations ...................................... 6
6. Intellectual Property Considerations ......................... 6
7. Acknowledgments .............................................. 7
Conventions used in this document Conventions used in this document
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 [i]. document are to be interpreted as described in RFC-2119 [i].
1. Terminology 1. Terminology
LSR - Label Switch Router LSR - Label Switch Router
skipping to change at line 73 skipping to change at line 86
PCS - Path Computation Server (may be any kind of LSR (ABR, ...) PCS - Path Computation Server (may be any kind of LSR (ABR, ...)
or a centralized path computation server or a centralized path computation server
PCC - Path Computation Client (any head-end LSR) requesting a path PCC - Path Computation Client (any head-end LSR) requesting a path
computation of the Path Computation Server. computation of the Path Computation Server.
Local Repair - Techniques used to repair LSP tunnels quickly Local Repair - Techniques used to repair LSP tunnels quickly
when a node or link along the LSPs path fails. when a node or link along the LSPs path fails.
Protected LSP - An LSP is said to be protected at a given hop if Protected LSP - An LSP is said to be protected at a given hop if
Vasseur, Ali and Sivabalan 2
it has one or multiple associated backup tunnels it has one or multiple associated backup tunnels
originating at that hop. originating at that hop.
Bypass Tunnel - An LSP that is used to protect a set of LSPs Bypass Tunnel - An LSP that is used to protect a set of LSPs
passing over a common facility. passing over a common facility.
Backup Tunnel - The LSP that is used to backup up one of the many Backup Tunnel - The LSP that is used to backup up one of the many
LSPs in many-to-one backup. LSPs in many-to-one backup.
PLR - Point of Local Repair. The head-end of a backup tunnel or PLR - Point of Local Repair. The head-end of a backup tunnel or
a detour LSP. a detour LSP.
Vasseur, Ali and Sivabalan 2
MP - Merge Point. The LSR where detour or backup tunnels meet MP - Merge Point. The LSR where detour or backup tunnels meet
the protected LSP. In case of one-to-one backup, this is where the protected LSP. In case of one-to-one backup, this is where
multiple detours converge. A MP may also be a PLR. multiple detours converge. A MP may also be a PLR.
NHOP Bypass Tunnel - Next-Hop Bypass Tunnel. A backup tunnel
which bypasses a single link of the protected LSP.
NNHOP Bypass Tunnel - Next-Next-Hop Bypass Tunnel. A backup
tunnel which bypasses a single node of the protected LSP.
Reroutable LSP - Any LSP for with the "Local protection desired" Reroutable LSP - Any LSP for with the "Local protection desired"
bit is set in the Flag field of the bit is set in the Flag field of the
SESSION_ATTRIBUTE object of its Path messages. SESSION_ATTRIBUTE object of its Path messages.
CSPF - Constraint-based Shortest Path First.
Inter-AS MPLS TE LSP: TE LSP whose Head-end LSR and Tail-end LSR do Inter-AS MPLS TE LSP: TE LSP whose Head-end LSR and Tail-end LSR do
not reside within the same Autonomous System (AS) or both Head-end not reside within the same Autonomous System (AS) or both Head-end
LSR and Tail-end LSR are in the same AS but the TE tunnel LSR and Tail-end LSR are in the same AS but the TE tunnel
transiting path may be across different ASes transiting path may be across different ASes
Interconnect or ASBR Routers: Routers used to connect to another AS of Interconnect or ASBR Routers: Routers used to connect to another AS of
a different or the same Service Provider via one or more Inter-AS a different or the same Service Provider via one or more Inter-AS
links. links.
2. Introduction 2. Introduction
MPLS Fast Reroute (FRR) ([FAST-REROUTE]) is a fast recovery local MPLS Fast Reroute (FRR) ([FAST-REROUTE]) is a fast recovery local
protection technique used to protect Traffic Engineering LSPs from protection technique used to protect Traffic Engineering LSPs from
link/SRLG/node failure. One or more backup tunnels are pre- link/SRLG/node failure. One or more backup tunnels are pre-established
established to protect against the failure of a link/node/SRLG. In case to protect against the failure of a link/node/SRLG. In case of failure,
of failure, every protected TE LSP traversing the failed resource is every protected TE LSP traversing the failed resource is rerouted onto
rerouted onto the appropriate backup tunnels in 10s of msecs. the appropriate backup tunnels in 10s of msecs.
There are a couple of requirements on the backup tunnel path. At least, There are a couple of requirements on the backup tunnel path. At least,
a backup tunnel should not pass through the element it protects. a backup tunnel should not pass through the element it protects.
Additionally, a primary tunnel and its associated backup tunnel should Additionally, a primary tunnel and its associated backup tunnel should
intersect at least at two points (nodes): Point of Local Repair (PLR) intersect at least at two points (nodes): Point of Local Repair (PLR)
and Merge Point (MP). The former should be the head-end LSR of the and Merge Point (MP). The former should be the head-end LSR of the
backup tunnel, and the latter should be the tail-end LSR of the backup backup tunnel, and the latter should be the tail-end LSR of the backup
tunnel. The PLR is where FRR is triggered when link/node/SRLG failure tunnel. The PLR is where FRR is triggered when link/node/SRLG failure
happens. happens.
There are different methods for computing paths for backup tunnels at a There are different methods for computing paths for backup tunnels at a
given PLR. Specifically, a user can statically configure one or more given PLR. Specifically, a user can statically configure one or more
backup tunnels at the PLR, with explicit path or the PLR can be backup tunnels at the PLR, with explicit path or the PLR can be
Vasseur, Ali and Sivabalan 3
configured to automatically compute a backup path or to send a path configured to automatically compute a backup path or to send a path
computation request to a PCS (which can be an LSR or an off-line tool). computation request to a PCS (which can be an LSR or an off-line tool).
Consider the following scenario: Consider the following scenario (figure 1)
Vasseur, Ali and Sivabalan 3
Assumptions: Assumptions:
- A multi-area network made of three areas: 0, 1 and 2. - A multi-area network made of three areas: 0, 1 and 2.
- A fast reroutable TE LSP T1 (TE LSP signaled with the "local - A fast reroutable TE LSP T1 (TE LSP signaled with the "local
Protection desired" bit set in the SESSION-ATTRIBUTE object or the FRR Protection desired" bit set in the SESSION-ATTRIBUTE object or the FRR
object) from R0 to R3 object) from R0 to R3
- A backup tunnel B1 from R1 to R2, not traversing ABR1, and following - A backup tunnel B1 from R1 to R2, not traversing ABR1, and following
the R1-ABR3-R2 path. R1 reroutes any protected TE LSP traversing ABR1 the R1-ABR3-R2 path. R1 reroutes any protected TE LSP traversing ABR1
onto the backup tunnel B1 in case of ABR1's failure. onto the backup tunnel B1 in case of ABR1's failure.
<--- area 1 --><---area 0---><---area 2---> <--- area 1 --><---area 0---><---area 2--->
R0-----R1-ABR1--R2------ABR2--------R3 R0-----R1-ABR1--R2------ABR2--------R3 Formatted:
\ / \ /
\ ABR3 / \ ABR3 /
Figure 1: Use of Fast Reroute to protect against an ABR failure with
MPLS Traffic Engineering Fast Reroute
When T1 is first signaled, the PLR R1 needs to dynamically select an When T1 is first signaled, the PLR R1 needs to dynamically select an
appropriate backup tunnel intersecting T1 on a downstream LSR. However, appropriate backup tunnel intersecting T1 on a downstream LSR. However,
existing protocol mechanisms are not sufficient to unambiguously find existing protocol mechanisms are not sufficient to unambiguously find
the MP address in a network with inter-area or inter-AS traffic the MP address in a network with inter-area or inter-AS traffic
engineering (although the example above was given in the context of engineering (although the example above was given in the context of
multi-area networks, a similar reasoning applies to TE LSP spanning multi-area networks, a similar reasoning applies to TE LSP spanning
multiple ASes). This document addresses these limitations. multiple ASes). This document addresses these limitations.
R1 needs to ensure the following: R1 needs to ensure the following:
skipping to change at line 183 skipping to change at line 192
A PLR can make sure that condition (1) is met by examining the Record A PLR can make sure that condition (1) is met by examining the Record
Route Object (RRO) of the primary tunnel to see if any of the addresses Route Object (RRO) of the primary tunnel to see if any of the addresses
specified in the RRO is attached to the tail-end of the backup tunnel. specified in the RRO is attached to the tail-end of the backup tunnel.
As per [RSVP-TE], the addresses specified in the RRO IPv4 or IPv6 As per [RSVP-TE], the addresses specified in the RRO IPv4 or IPv6
subobjects sent in Resv messages can be node-ids and/or interface subobjects sent in Resv messages can be node-ids and/or interface
addresses . Hence, in Figure 1, router R2 may specify interface addresses . Hence, in Figure 1, router R2 may specify interface
addresses in the RROs for T1 and B1. Note that these interface addresses in the RROs for T1 and B1. Note that these interface
addresses are different in this example. addresses are different in this example.
Vasseur, Ali and Sivabalan 4
The problem of finding the MP using the interface addresses or node-ids The problem of finding the MP using the interface addresses or node-ids
can be easily solved in a single area (OSPF_)/level (IS-IS). can be easily solved in a single area (OSPF_)/level (IS-IS).
Specifically, in the case of single area/level, the PLR has the Specifically, in the case of single area/level, the PLR has the
knowledge of all the interfaces attached to the tail-end of the backup knowledge of all the interfaces attached to the tail-end of the backup
tunnel. This information is available in PLR's IGP topology database. tunnel. This information is available in PLR's IGP topology database.
Thus, the PLR can determine whether a backup tunnel intersecting a Thus, the PLR can determine whether a backup tunnel intersecting a
protected TE LSP on a downstream node exists and can also find the MP protected TE LSP on a downstream node exists and can also find the MP
Vasseur, Ali and Sivabalan 4
address regardless of how the addresses contained in the RRO IPv4 or address regardless of how the addresses contained in the RRO IPv4 or
IPv6 subobjects are specified (i.e., whether using the interface IPv6 subobjects are specified (i.e., whether using the interface
addresses or the node IDs). However, such routing information is not addresses or the node IDs). However, such routing information is not
available in multi-area and inter-AS traffic engineering environments. available in multi-area and inter-AS traffic engineering environments.
Hence, unambiguously making sure that condition (1) above is met with Hence, unambiguously making sure that condition (1) above is met with
inter-area TE and inter-AS traffic-engineering TE LSPs is not possible inter-area TE and inter-AS traffic-engineering TE LSPs is not possible
with existing mechanisms. with existing mechanisms.
In this document, we define extensions to and describe the use of RSVP In this document, we define extensions to and describe the use of RSVP
[RSVP, RSVP-TE] to solve the above-mentioned problem. [RSVP, RSVP-TE] to solve the above-mentioned problem.
3. Signaling node-ids in RROs 3. Signaling node-ids in RROs
As mentioned above, the limitation that we need to address is the As mentioned above, the limitation that we need to address is the
generality of the contents of the RRO IPv4 and IPv6 subobjects, as generality of the contents of the RRO IPv4 and IPv6 subobjects, as
defined in [RSVP-TE].[RFC3209] defines the IPv4 and IPv6 RRO subobjects defined in [RSVP-TE].[RSVP-TE] defines the IPv4 and IPv6 RRO subobjects
along with two flags (namely the ôLocal Protection Availableö and along with two flags (namely the ôLocal Protection Availableö and
ôLocal protection in useö bits). Moreover, other bits have been ôLocal protection in useö bits). Moreover, other bits have been
specified in [FAST-REROUTE] and [SOFT-PREEMPTION]. specified in [FAST-REROUTE] and [SOFT-PREEMPTION].
In this document, we define the following new flag: In this document, we define the following new flag:
Node-id: 0x20 Node-id: 0x20
When set, this indicates that the address specified in the When set, this indicates that the address specified in the
RRO's IPv4 or IPv6 subobject is a node-id address, which refers RRO's IPv4 or IPv6 subobject is a node-id address, which refers
skipping to change at line 231 skipping to change at line 239
the same address consistently. In other words, once an address the same address consistently. In other words, once an address
is used in RRO's IPv4 or IPv6 subobject, it should always be is used in RRO's IPv4 or IPv6 subobject, it should always be
used for the lifetime of the LSP. used for the lifetime of the LSP.
An IPv4 or IPv6 RRO subobject with the node-id flag set is also called An IPv4 or IPv6 RRO subobject with the node-id flag set is also called
a node-id subobject. The problem of finding a MP address in a network a node-id subobject. The problem of finding a MP address in a network
with inter-area or inter-AS traffic engineering is solved by inserting with inter-area or inter-AS traffic engineering is solved by inserting
a node-id subobject (an RRO "IPv4" and "IPv6" sub-object with the 0x20 a node-id subobject (an RRO "IPv4" and "IPv6" sub-object with the 0x20
flag set). flag set).
An implementation MAY either decide to support of one the following An implementation may either decide to:
options:
Option 1: add the node-id subobject in an RSVP Resv message and, when 1) Add the node-id subobject in an RSVP Resv message and, when
required, also add another IPv4/IPv6 subobject to record interface required, also add another IPv4/IPv6 subobject to record interface
address. address.
Vasseur, Ali and Sivabalan 5
Example: a fast reroutable TE LSP would have in the RRO object carried Example: a fast reroutable TE LSP would have in the RRO object carried
in Resv message two subobjects: a node-id subobject and a label in Resv message two subobjects: a node-id subobject and a label
subobject. If recording the interface address is required, then an subobject. If recording the interface address is required, then an
additional IPv4/IPv6 subobject is added. additional IPv4/IPv6 subobject is added.
Vasseur, Ali and Sivabalan 5 2) Add an IPv4/IPv6 subobject recording the interface address and, when
required, add a node-id subobject in the RRO object.
Option 2: add an IPv4/IPv6 subobject recording the interface address
and, when required, add a node-id subobject in the RRO object.
Example: an inter-area/inter-AS fast reroutable TE LSP would have in Example: an inter-area/inter-AS fast reroutable TE LSP would have in
the RRO object carried in Resv message three subobjects: an IPv4/IPv6 the RRO object carried in Resv message three subobjects: an IPv4/IPv6
subobject recording interface address, a label subobject and a node-id subobject recording interface address, a label subobject and a node-id
subobject. subobject.
Note also, that the node-id subobject may have other application than Note also, that the node-id subobject may have other application than
Fast Reroute backup tunnel selection. Moreover, it is RECOMMENDED that Fast Reroute backup tunnel selection. Moreover, it is RECOMMENDED that
an LSR recording a node-id address in an IPv4/IPv6 RRO sub-object also an LSR recording a node-id address in an IPv4/IPv6 RRO sub-object also
set the Node-id flag. set the Node-id flag.
skipping to change at line 291 skipping to change at line 298
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to pertain intellectual property or other rights that might be claimed to pertain
to the implementation or use of the technology described in this to the implementation or use of the technology described in this
document or the extent to which any license under such rights might or document or the extent to which any license under such rights might or
might not be available; neither does it represent that it has made any might not be available; neither does it represent that it has made any
effort to identify any such rights. Information on the IETF's effort to identify any such rights. Information on the IETF's
procedures with respect to rights in standards-track and standards- procedures with respect to rights in standards-track and standards-
related documentation can be found in BCP-11. Copies of claims of related documentation can be found in BCP-11. Copies of claims of
rights made available for publication and any assurances of licenses to rights made available for publication 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
Vasseur, Ali and Sivabalan 6 Vasseur, Ali and Sivabalan 6
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
implementors or users of this specification can be obtained from the implementors or users of this specification can be obtained from the
IETF Secretariat. IETF Secretariat.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary rights copyrights, patents or patent applications, or other proprietary rights
which may cover technology that may be required to practice this which may cover technology that may be required to practice this
standard. Please address the information to the IETF Executive standard. Please address the information to the IETF Executive
Director. Director.
The IETF has been notified of intellectual property rights claimed in The IETF has been notified of intellectual property rights claimed in
skipping to change at line 317 skipping to change at line 324
For more information consult the online list of claimed rights. For more information consult the online list of claimed rights.
7. Acknowledgments 7. Acknowledgments
We would like to acknowledge input and helpful comments from Carol We would like to acknowledge input and helpful comments from Carol
Iturralde, Anca Zamfir, Reshad Rahman, Rob Goguen, Philip Matthews and Iturralde, Anca Zamfir, Reshad Rahman, Rob Goguen, Philip Matthews and
Adrian Farrel. Adrian Farrel.
Normative References Normative References
[RFC2119]Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3667]Bradner, S., "IETF Rights in Contributions", BCP 78, RFC 3667,
February 2004.
[RFC3668]Bradner, S., Ed., "Intellectual Property Rights in IETF
Technology", BCP 79, RFC 3668, February 2004.
[RSVP] Braden, et al, "Resource ReSerVation Protocol (RSVP) - Version [RSVP] Braden, et al, "Resource ReSerVation Protocol (RSVP) - Version
1, Functional Specification", RFC 2205, September 1997. 1, Functional Specification", RFC 2205, September 1997.
[RSVP-TE] Awduche, et al, "Extensions to RSVP for LSP Tunnels", RFC [RSVP-TE] Awduche, et al, "Extensions to RSVP for LSP Tunnels", RFC
3209, December 2001. 3209, December 2001.
Informative references
[FAST-REROUTE] Ping Pan, et al, "Fast Reroute Extensions to RSVP-TE for [FAST-REROUTE] Ping Pan, et al, "Fast Reroute Extensions to RSVP-TE for
LSP Tunnels", draft-ietf-mpls-rsvp-lsp-fastreroute-03.txt, June 2003. LSP Tunnels", draft-ietf-mpls-rsvp-lsp-fastreroute-07.txt. Work in
progress.
[OSPF-TE] Katz et al., ôTraffic Engineering (TE) Extensions to OSPF [OSPF-TE] Katz et al., ôTraffic Engineering (TE) Extensions to OSPF
Version 2ö, RFC3630. Version 2ö, RFC3630.
[ISIS-TE] Smit et al., IS-IS extensions for Traffic Engineering, [ISIS-TE] Smit et al., ôIntermediate System to Intermediate System (IS-
draft-ietf-isis-traffic-05.txt, work in progress. IS) - Extensions for Traffic Engineering (TE)IS-IS extensions for
Traffic Engineeringö, RFC3784.
Informative references
[INTER-AS-TE-REQS] Zhang et al, "MPLS Inter-AS Traffic Engineering Vasseur, Ali and Sivabalan 7
requirements", draft-tewg-interas-te-req-05.txt, work in progress.
[INTER-AS-TE] Vasseur and Zhang, "MPLS Inter-AS Traffic Engineering", [INTER-AREA-TE-REQS] Le Roux, Vasseur, Boyle et al., ôRequirements for
draft-vasseur-mpls-inter-as-te-01.txt, work in progress. Inter-Area MPLS Traffic Engineeringö, draft-ietf-tewg-interarea-mpls-te-
req-03.txt. Work in progress.
[MULTI-AREA-TE] Kompella et al,"Multi-area MPLS Traffic Engineering", [INTER-AS-TE-REQS] Zhang, Vasseur et al, "MPLS Inter-AS Traffic
draft-kompella-mpls-multiarea-te-03.txt, work in progress. Engineering requirements", draft-tewg-interas-te-req-09.txt. Work in
progress.
[LOOSE-PATH-REOPT] Vasseur, JP., Ikejiri, Y., "Reoptimization of MPLS [INTER-DOMAIN-SIG] Ayyangar and Vasseur, "Inter domain GMPLS Traffic
Engineering - RSVP-TE extensionsö, draft-ayyangar-ccamp-inter-domain-
rsvp-te-01.txt. Work in progress.
Vasseur, Ali and Sivabalan 7 [LOOSE-PATH-REOPT] Vasseur et al. "Reoptimization of MPLS
Traffic Engineering loosely routed LSP", <draft-ietf-ccamp-loose-path-
reopt-00.txt>. Work in progress.
Traffic Engineering loosely routed explicit LSP path", <draft-vasseur- [SOFT-PREEMPTION] Meyer, Maddux, Vasseur, Villamizar and Birjandi. ôMPLS
mpls-loose-path-reopt-02.txt>, Internet Draft, work in progress. Traffic Engineering Soft preemptionö, draft-ietf-mpls-soft-preemption-
03.txt. Work in progress.
Authors' Address: Authors' Addresses:
Jean Philippe Vasseur Jean Philippe Vasseur
Cisco Systems, Inc. Cisco Systems, Inc.
300 Beaver Brook Road 300 Beaver Brook Road
Boxborough , MA - 01719 Boxborough , MA - 01719
USA USA
Email: jpv@cisco.com Email: jpv@cisco.com
Zafar Ali Zafar Ali
Cisco Systems, Inc. Cisco Systems, Inc.
skipping to change at line 375 skipping to change at line 399
Siva Sivabalan Siva Sivabalan
Cisco Systems, Inc. Cisco Systems, Inc.
2000 Innovation Drive 2000 Innovation Drive
Kanata, Ontario, K2K 3E8 Kanata, Ontario, K2K 3E8
Canada Canada
msiva@cisco.com msiva@cisco.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2004). All Rights Copyright (C) The Internet Society (2004). This document is subject
Reserved. 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 translations of it may be copied and
furnished to others, and derivative works that comment on
or otherwise explain it or assist in its implementation may
be prepared, copied, published and distributed, in whole or
in part, without restriction of any kind, provided that the
above copyright notice and this paragraph are included on
all such copies and derivative works. However, this
document itself may not be modified in any way, such as by
removing the copyright notice or references to the Internet
Society or other Internet organizations, except as needed
for the purpose of developing Internet standards in which
case the procedures for copyrights defined in the Internet
Standards process must be followed, or as required to
translate it into languages other than English.
The limited permissions granted above are perpetual and This document and the information contained herein are provided on an
will not be revoked by the Internet Society or its "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
successors or assigns. This document and the information
contained herein is provided on an "AS IS" basis and THE
INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE
Vasseur, Ali and Sivabalan 8 Vasseur, Ali and Sivabalan 8
DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT
NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
PURPOSE. INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Vasseur, Ali and Sivabalan 9 Vasseur, Ali and Sivabalan 9
 End of changes. 

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