draft-ietf-mpls-nodeid-subobject-00.txt   draft-ietf-mpls-nodeid-subobject-01.txt 
draft-ietf-mpls-nodeid-subobject-00.txt February 2003
Jean Philippe Vasseur Jean Philippe Vasseur
Zafar Ali Zafar Ali
Siva Sivabalan Siva Sivabalan
Cisco Systems, Inc. Cisco Systems, Inc.
IETF Internet Draft IETF Internet Draft
Expires: August, 2003 Expires: November, 2003
February, 2003 May, 2003
draft-ietf-mpls-nodeid-subobject-00.txt draft-ietf-mpls-nodeid-subobject-01.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 This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026. Internet-Drafts are provisions of Section 10 of RFC2026. Internet-Drafts are
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.
skipping to change at line 37 skipping to change at line 34
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
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Vasseur, Ali and Sivabalan 1 Vasseur, Ali and Sivabalan 1
draft-ietf-mpls-nodeid-subobject-00.txt February 2003
Abstract Abstract
In the context of MPLS TE Fast Reroute ([FAST-REROUTE]), the Merge In the context of MPLS TE Fast Reroute ([FAST-REROUTE]), the Merge
Point (MP) address is required at the Point of Local Repair (PLR) in Point (MP) address is required at the Point of Local Repair (PLR) in
order to select a backup tunnel intersecting a protected Traffic order to select a backup tunnel intersecting a fast reroutable Traffic
Engineering LSP on a downstream LSR. However, existing protocol Engineering LSP on a downstream LSR. However, existing protocol
mechanisms are not sufficient to find MP address multi-areas or multi- mechanisms are not sufficient to find an MP address in multi-areas or
domain routing network. Hence, the current MPLS Fast Reroute mechanism multi-domain routing networks. Hence, the current MPLS Fast Reroute
cannot be used to protect inter-area or inter-AS TE LSPs from a failure mechanism cannot be used to protect inter-area or inter-AS TE LSPs from
of an ABR (Area Border Router) or ASBR (Autonomous System Border a failure of an ABR (Area Border Router) or ASBR (Autonomous System
Router) respectively. This document specifies the use of existing RRO Border Router) respectively. This document specifies the use of
IPv4 and IPv6 subobjects (with a new flag defined) to define the node- existing RRO IPv4 and IPv6 subobjects (with a new flag defined) to
id subobject in order to solve this issue. define the node-id subobject in order to solve this issue. Note that
the MPLS Fast reroute mechanism mentioned in this draft refers to the
"Facility backup" MPLS TE Fast Reroute method.
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 87 skipping to change at line 84
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.
MP - Merge Point. The LSR where detour or backup tunnels meet
Vasseur, Ali and Sivabalan 2 Vasseur, Ali and Sivabalan 2
draft-ietf-mpls-nodeid-subobject-00.txt February 2003 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 NHOP Bypass Tunnel - Next-Hop Bypass Tunnel. A backup tunnel
which bypasses a single link of the protected LSP. which bypasses a single link of the protected LSP.
NNHOP Bypass Tunnel - Next-Next-Hop Bypass Tunnel. A backup NNHOP Bypass Tunnel - Next-Next-Hop Bypass Tunnel. A backup
tunnel which bypasses a single node of the protected LSP. 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. CSPF - Constraint-based Shortest Path First.
Inter-AS MPLS TE: 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 TE LSPs (called backup LSPs) are link/SRLG/node failure. One or more backup tunnels are pre-
pre-established to protect against the failure of a link/node/SRLG. In established to protect against the failure of a link/node/SRLG. In case
case of failure, every protected TE LSP traversing the failed resource of failure, every protected TE LSP traversing the failed resource is
is rerouted onto the appropriate backup tunnels in 10s of msecs. rerouted onto 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 a backup tunnel should intersect at Additionally, a primary tunnel and its associated backup tunnel should
least at two points (nodes): Point of Local Repair (PLR) and Merge intersect at least at two points (nodes): Point of Local Repair (PLR)
Point (MP). The former should be the head-end LSR of the backup tunnel, and Merge Point (MP). The former should be the head-end LSR of the
and the latter should be the tail-end LSR of the backup tunnel. The PLR backup tunnel, and the latter should be the tail-end LSR of the backup
is where FRR is triggered when link/node/SRLG failure happens. tunnel. The PLR is where FRR is triggered when link/node/SRLG failure
Furthermore, the MP address is also required to send RSVP Refresh happens.
messages of the rerouted TE LSPs when the FRR is active.
There are different methods for computing paths for backup tunnels. There are different methods for computing paths for backup tunnels at a
Specifically, a users can statically configures one or more backup given PLR. Specifically, a user can statically configure one or more
tunnels at the PLR, with explicit path or the PLR can be configured to backup tunnels at the PLR, with explicit path or the PLR can be
automatically compute a backup path or to send a path computation configured to automatically compute a backup path or to send a path
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
Vasseur, Ali and Sivabalan 3 Vasseur, Ali and Sivabalan 3
draft-ietf-mpls-nodeid-subobject-00.txt February 2003 Consider the following scenario:
Asumptions: 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 protected TE LSP T1 (TE LSP signaled with the "local Protection - A fast reroutable TE LSP T1 (TE LSP signaled with the "local
desired" bit set in the SESSION-ATTRIBUTE object or the FRR object) Protection desired" bit set in the SESSION-ATTRIBUTE object or the FRR
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
<span class="insert">A</span> backup tunnel B1 from R1 to R2, not traversing ABR1, and following
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
\ / \ /
\ ABR3 / \ ABR3 /
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
MP address in a network with inter-area or inter-AS traffic engineering the MP address in a network with inter-area or inter-AS traffic
(although the example above was given in the context of multi-area engineering (although the example above was given in the context of
networks, a similar reasoning applies to TE LSP spanning multiple multi-area networks, a similar reasoning applies to TE LSP spanning
ASes). This draft addresses these limitations. multiple ASes). This draft addresses these limitations.
R1 needs to ensure the following: R1 needs to ensure the following:
1. Backup tunnel intersects with the primary tunnel at the MP (and 1. Backup tunnel intersects with the primary tunnel at the MP (and
thus has a valid MP address), e.g., in Figure 1, R1 needs to thus has a valid MP address), e.g., in Figure 1, R1 needs to
determine that T1 and B1 share the same MP node R2, determine that T1 and B1 share the same MP node R2,
2. Backup tunnel satisfies the primary LSP's request with respect to 2. Backup tunnel satisfies the primary LSP's request with respect to
the bandwidth protection request (i.e., bandwidth guaranteed for the bandwidth protection request (i.e., bandwidth guaranteed for
the primary tunnel during failure), and the type of protection the primary tunnel during failure), and the type of protection
(preferably, protecting against a node failure versus a link (preferably, protecting against a node failure versus a link
failure), as specified in [FAST-REROUTE]. failure), as specified in [FAST-REROUTE].
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 subobjects As per [RSVP-TE], the addresses specified in the RRO IPv4 or IPv6
can be node-ids and/or interface addresses, with specific subobjects sent in Resv messages can be node-ids and/or interface
recommendation to use the interface address of the outgoing Path addresses . Hence, in Figure 1, router R2 may specify interface
messages. Hence, in Figure 1, router R2 is more likely to specify addresses in the RROs for T1 and B1. Note that these interface
interface addresses in the RROs for T1 and B1. Note that these addresses are different in this example.
interface addresses are different in this example.
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 TE. Specifically, in the case of can be easily solved in a single area (OSPF_)/level (IS-IS).
single area TE, the PLR has the knowledge of all the interfaces Specifically, in the case of single area/level, the PLR has the
attached to the tail-end of the backup tunnel. This information is knowledge of all the interfaces attached to the tail-end of the backup
available in PLR's IGP topology database. Thus, the PLR can determine tunnel. This information is available in PLR's IGP topology database.
whether a backup tunnel intersecting a protected TE LSP on a downstream Thus, the PLR can determine whether a backup tunnel intersecting a
node exists and can also find the MP address regardless of how the
Vasseur, Ali and Sivabalan 4 Vasseur, Ali and Sivabalan 4
draft-ietf-mpls-nodeid-subobject-00.txt February 2003 protected TE LSP on a downstream node exists and can also find the MP
address regardless of how the addresses contained in the RRO IPv4 or
addresses contained in the RRO IPv4 or IPv6 subobjects are specified IPv6 subobjects are specified (i.e., whether using the interface
(i.e., whether using the interface addresses or the node IDs). However, addresses or the node IDs). However, such routing information is not
such routing information is not available in a multi-area and inter-AS available in multi-area and inter-AS trafficengineering environments.
traffic-engineering environments. Hence, unambiguously making sure that Hence, unambiguously making sure that condition (1) above is met with
condition (1) above is met with inter-area TE and inter-AS traffic- inter-area TE and inter-AS traffic-engineering TE LSPs is not possible
engineering TE LSPs is not possible with existing mechanisms. with existing mechanisms.
In this draft, we define extensions to and describe the use of RSVP In this draft, 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]. defined in [RSVP-TE].
skipping to change at line 251 skipping to change at line 241
this whenever the desired bandwidth is guaranteed; the PLR this whenever the desired bandwidth is guaranteed; the PLR
MUST set this flag when the desired bandwidth is guaranteed MUST set this flag when the desired bandwidth is guaranteed
and the "bandwidth protection desired" flag was set in the and the "bandwidth protection desired" flag was set in the
SESSION_ATTRIBUTE object. If the requested bandwidth is not SESSION_ATTRIBUTE object. If the requested bandwidth is not
guaranteed, the PLR MUST NOT set this flag. guaranteed, the PLR MUST NOT set this flag.
Node protection: 0x08 Node protection: 0x08
The PLR will set this when the protected LSP has a backup path The PLR will set this when the protected LSP has a backup path
which provides protection against a failure of the next LSR which provides protection against a failure of the next LSR
along the protected LSP. The PLR may set this whenever node
protection is provided by the protected LSP's backup path; the
Vasseur, Ali and Sivabalan 5 Vasseur, Ali and Sivabalan 5
along the protected LSP. The PLR may set this whenever node
draft-ietf-mpls-nodeid-subobject-00.txt February 2003 protection is provided by the protected LSP's backup path; the
PLR MUST set this flag when the node protection is provided PLR MUST set this flag when the node protection is provided
and the "node protection desired" flag was set in the and the "node protection desired" flag was set in the
SESSION_ATTRIBUTE object. If node protection is not provided, SESSION_ATTRIBUTE object. If node protection is not provided,
the PLR MUST NOT set this flag. Thus, if a PLR could only the PLR MUST NOT set this flag. Thus, if a PLR could only
setup a link-protection backup path, the "Local protection setup a link-protection backup path, the "Local protection
available" bit will be set but the "Node protection" bit will available" bit will be set but the "Node protection" bit will
be cleared. be cleared.
An additional flag is specified: Preemption pending: 0x10
The preempting node sets this flag if a pending preemption is
in progress for the TE LSP. This indicates to the HE of this
LSP that it must be re-routed as soon as possible using a make
before break.
Node-id: 0x10 In this document, we define the following new flag:
When set, this indicates that the address specified in the RRO Node-id: 0x20
IPv4 or IPv6 subobject is a node-id address, which refers to
the "Router Address" as defined in [OSPF-TE], or "Traffic
Engineering Router ID" as defined in [ISIS-TE]. A node MUST use
the same address consistently.
An IPv4 or IPv6 RRO subobject with the node-is flag set is also called When set, this indicates that the address specified in the
a node-id subobject. RRO's IPv4 or IPv6 subobject is a node-id address, which refers
to the "Router Address" as defined in [OSPF-TE], or "Traffic
Engineering Router ID" as defined in [ISIS-TE]. A node MUST use
the same address consistently. In other words, once an address
is used in RRO's IPv4 or IPv6 subobject, it should always be
used for the lifetime of the LSP.
The problem of finding MP address in a network with inter-area or An IPv4 or IPv6 RRO subobject with the node-id flag set is also called
inter-AS traffic engineering is solved by adding a node-id subobject a node-id subobject. The problem of finding a MP address in a network
(an RRO "IPv4" and "IPv6" sub-object with the 0x10 flag set). 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
flag set).
Any Head-end LSR of a protected TE LSP MUST include an RRO object, as An implementation MAY either decide to support of one the following
defined in [FAST-REROUTE]. In addition, any LSR compliant with this options:
draft must systematically include a node-id IPv4 or IPv6 subobject in
the RRO object for each protected TE LSP (in addition to the sub-
objects required by MPLS TE Fast Reroute as defined in [FAST-REROUTE]).
A node MAY decide to include its node-id subobject in the RRO object
only for the TE LSP whose IPv4 or IPv6 address source address
(specified in the SENDER-TEMPLATE object of the RSVP Path message) does
not belong to its local area/AS.
4. Processing RRO with node-id subobjects Option 1: add the node-id subobject in an RSVP Resv message and, when
required, also add another IPv4/IPv6 subobject to record interface
address.
The node-id subobject is added into the RECORD_ROUTE object after the Example: a fast reroutable TE LSP would have in the RRO object carried
Label Record subobject. A node MUST not push a node-id subobject in Resv message two subobjects: a node-id subobject and a label
without also pushing an IPv4 or IPv6 subobjects, as defined in [FAST- subobject. If recording the interface address is required, then an
REROUTE]. A node may push both IPv4 node-id and IPv6 node-id sub- additional IPv4/IPv6 subobject is added.
objects, but that MUST be done on consistent basis.
4.1. Finding Merge Point Option 2: add an IPv4/IPv6 subobject recording the interface address
and, when required, add a node-id subobject in the RRO object.
A PLR can find the MP and suitable backup tunnel by simply comparing Example: an inter-area/inter-AS fast reroutable TE LSP would have in
the node-id of the backup tunnel's tail-end with Node IDs included in the RRO object carried in Resv message three subobjects: an IPv4/IPv6
the RRO of the primary tunnel. When both IPv4 node-id and IPv6 node-id
Vasseur, Ali and Sivabalan 6 Vasseur, Ali and Sivabalan 6
draft-ietf-mpls-nodeid-subobject-00.txt February 2003 subobject recording interface address, a label subobject and a node-id
subobject.
sub-objects are present, a PLR may use any or both of them in finding
the MP address.
4.2. Processing at the border nodes Note also, that the node-id subobject may have other application than
Fast Reroute backup tunnel selection.
In a network with inter-AS traffic engineering, there may be some 4. Finding Merge Point
concerns about leaking the RRO information, including node-id
subobjects, outside the autonomous system (see [INTER-AS-TE-REQS]). In
such cases, before forwarding the RRO object outside of an AS, the ASBR
may filter some/all node-id subobjects pertaining to the downstream
nodes in the AS. The RRO node-id subobjects filtration can be based on
a local policy configured on the ASBR.
How an ASBR handles/filters the contents of the RRO objects is outside Two cases should be considered:
of the scope of this draft.
5. Backward Compatibility Note - case 1: the backup tunnel destination is the MP's node-id. Then a PLR
can find the MP and suitable backup tunnel by simply comparing the
backup tunnel's destination address with the node-id included in the
RRO of the primary tunnel.
- case 2: the backup tunnel terminates at an address different than the
MP's node-id. Then a node-id subobject MUST also be included in the RRO
object of the backup tunnel. A PLR can find the MP and suitable backup
tunnel by simply comparing the node-ids present in the RRO objects of
both the primary and backup tunnels.
To remain compatible with the nodes that do not support the RRO IPv4 or When both IPv4 node-id and IPv6 node-id sub-objects are present, a PLR
IPv6 node-id subobjects, a node can safely ignore these objects. The may use any or both of them in finding the MP address.
implication of this limitation will be that these nodes could not be MP
in a network with inter-area or inter-AS traffic engineering.
6. Security Considerations 5. Security Considerations
This document does not introduce new security issues. The security This document does not introduce new security issues. The security
considerations pertaining to the original RSVP protocol [RSVP] remain considerations pertaining to the original RSVP protocol [RSVP] remain
relevant. relevant.
7. Intellectual Property Considerations 6. Intellectual Property Considerations
Cisco Systems may have intellectual property rights claimed in regard Cisco Systems may have intellectual property rights claimed in regard
to some of the specification contained in this document to some of the specification contained in this document
8. 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, and Reshad Rahman. Iturralde, Anca Zamfir, Reshad Rahman, Rob Goguen and Philip Matthews.
References References
[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.
Vasseur, Ali and Sivabalan 7 Vasseur, Ali and Sivabalan 7
draft-ietf-mpls-nodeid-subobject-00.txt February 2003
[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-01.txt, May 2003. LSP Tunnels", draft-ietf-mpls-rsvp-lsp-fastreroute-02.txt, May 2003.
[OSPF-TE] Katz, D., Yeung, D., Kompella, K., "Traffic Engineering [OSPF-TE] Katz, D., Yeung, D., Kompella, K., "Traffic Engineering
Extensions to OSPF Version 2", draft-katz-yeung-ospf-traffic- Extensions to OSPF Version 2", draft-katz-yeung-ospf-traffic-
09.txt(work in progress). 09.txt(work in progress).
[ISIS-TE] Li, T., Smit, H., "IS-IS extensions for Traffic Engineering", [ISIS-TE] Li, T., Smit, H., "IS-IS extensions for Traffic Engineering",
draft-ietf-isis-traffic-04.txt (work in progress) draft-ietf-isis-traffic-04.txt (work in progress)
[MULTI-AREA-TE] Kompella at all,"Multi-area MPLS Traffic Engineering", [MULTI-AREA-TE] Kompella at all,"Multi-area MPLS Traffic Engineering",
draft-kompella-mpls-multiarea-te-03.txt, June 2002. draft-kompella-mpls-multiarea-te-03.txt, June 2002.
[LOOSE-PATH-REOPT] Vasseur and Ikejiri, "Reoptimization of an explicit [LOOSE-PATH-REOPT] Vasseur and Ikejiri, "Reoptimization of an explicit
loosely routed MPLS TE paths", draft-vasseur-mpls-loose-path-reopt- loosely routed MPLS TE paths", draft-vasseur-mpls-loose-path-reopt-
00.txt, February 2003, Work in Progress. 01.txt, February 2003, Work in Progress.
[ABR-ASBR-FRR] Vasseur, Ali and Sivabalan, "Support of MPLS TE Fast
Reroute protection of ABR/ASBR LSRs", draft-vasseur-mpls-abr-asbr-frr
00.txt, February 2003, Work in progress.
[INTER-AS-TE-REQS] Zhang et al, "MPLS Inter-AS Traffic Engineering [INTER-AS-TE-REQS] Zhang et al, "MPLS Inter-AS Traffic Engineering
requirements", draft-tewg-interas-te-req-01.txt (work in progress). requirements", draft-tewg-interas-te-req-02.txt (work in progress).
[INTER-AS-TE] Vasseur and Zhang, "MPLS Inter-AS Traffic Engineering", [INTER-AS-TE] Vasseur and Zhang, "MPLS Inter-AS Traffic Engineering",
draft-vasseur-mpls-inter-as-te-00.txt, February 2003, work in progress. draft-vasseur-mpls-inter-as-te-00.txt, February 2003, work in progress.
Authors' Address: Authors' Address:
Jean Philippe Vasseur Jean Philippe Vasseur
Cisco Systems, Inc. Cisco Systems, Inc.
300 Apollo Drive 300 Beaver Brook Road
Chelmsford, MA 01824 Boxborough , MA - 01719
USA USA
Email: jpv@cisco.com Email: jpv@cisco.com
Zafar Ali Zafar Ali
Cisco Systems, Inc. Cisco Systems, Inc.
100 South Main St. #200 100 South Main St. #200
Ann Arbor, MI 48104 Ann Arbor, MI 48104
USA USA
zali@cisco.com zali@cisco.com
 End of changes. 

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