draft-ietf-ccamp-inter-domain-pd-path-comp-04.txt   draft-ietf-ccamp-inter-domain-pd-path-comp-05.txt 
Networking Working Group JP. Vasseur, Ed. Networking Working Group JP. Vasseur, Ed.
Internet-Draft Cisco Systems, Inc Internet-Draft Cisco Systems, Inc
Intended status: Standards Track A. Ayyangar, Ed. Intended status: Standards Track A. Ayyangar, Ed.
Expires: August 10, 2007 Nuova Systems Expires: October 2007 Nuova Systems
R. Zhang R. Zhang
BT Infonet BT Infonet
February 6, 2007
A Per-domain path computation method for establishing Inter-domain A Per-domain path computation method for establishing Inter-domain
Traffic Engineering (TE) Label Switched Paths (LSPs) Traffic Engineering (TE) Label Switched Paths (LSPs)
draft-ietf-ccamp-inter-domain-pd-path-comp-04
draft-ietf-ccamp-inter-domain-pd-path-comp-05
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 38 skipping to change at page 1, line 36
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 time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material 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.
This Internet-Draft will expire on August 10, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract Abstract
This document specifies a per-domain path computation technique for This document specifies a per-domain path computation technique for
establishing inter-domain Traffic Engineering (TE) Multiprotocol establishing inter-domain Traffic Engineering (TE) Multiprotocol
Label Switching (MPLS) and Generalized MPLS (GMPLS) Label Switched Label Switching (MPLS) and Generalized MPLS (GMPLS) Label Switched
Paths (LSPs). In this document a domain refers to a collection of Paths (LSPs). In this document a domain refers to a collection of
network elements within a common sphere of address management or path network elements within a common sphere of address management or path
computational responsibility such as IGP areas and Autonomous computational responsibility such as IGP areas and Autonomous
Systems. Per-domain computation applies where the full path of an Systems.
inter-domain TE LSP cannot be or is not determined at the ingress
node of the TE LSP, and is not signaled across domain boundaries. Per-domain computation applies where the full path of an inter-domain
This is most likely to arise owing to TE visibility limitations. The TE LSP cannot be or is not determined at the ingress node of the TE
signaling message indicates the destination and nodes up to the next LSP, and is not signaled across domain boundaries. This is most
domain boundary. It may also indicate further domain boundaries or likely to arise owing to TE visibility limitations. The signaling
domain identifiers. The path through each domain, possibly including message indicates the destination and nodes up to the next domain
the choice of exit point from the domain, must be determined within boundary. It may also indicate further domain boundaries or domain
identifiers. The path through each domain, possibly including the
choice of exit point from the domain, must be determined within
the domain. the domain.
Requirements Language Requirements Language
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 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
Table of Contents Table of Contents
skipping to change at page 5, line 42 skipping to change at page 5, line 42
for path computation are not precluded either. Note also that a for path computation are not precluded either. Note also that a
Service Provider may elect to use different inter-domain path Service Provider may elect to use different inter-domain path
computation techniques for different TE LSP types. computation techniques for different TE LSP types.
3. General assumptions 3. General assumptions
3.1. Common assumptions 3.1. Common assumptions
- Each domain in all the examples below is assumed to be capable of - Each domain in all the examples below is assumed to be capable of
doing Traffic Engineering (i.e. running OSPF-TE or ISIS-TE and doing Traffic Engineering (i.e. running OSPF-TE or ISIS-TE and
RSVP-TE). A domain may itself comprise multiple other domains. E.g. RSVP-TE). A domain may itself comprise multiple other domains.
An AS may itself be composed of several other sub-AS(es) (BGP E.g., An AS may itself be composed of several other sub-AS(es) (BGP
confederations) or areas/levels. In this case, the path computation confederations) or areas/levels. In this case, the path
technique described for inter-area and inter-AS MPLS Traffic computation technique described for inter-area and inter-AS MPLS
Engineering just recursively applies. Traffic Engineering just recursively applies.
- The inter-domain TE LSPs are signaled using RSVP-TE ([RFC3209] and - The inter-domain TE LSPs are signaled using RSVP-TE ([RFC3209] and
[RFC3473]). [RFC3473]).
- The path (ERO) for an inter-domain TE LSP may be signaled as a set - The path (ERO) for an inter-domain TE LSP may be signaled as a set
of (loose and/or strict) hops. of (loose and/or strict) hops.
- The hops may identify: - The hops may identify:
* The complete strict path end-to-end across different domains * The complete strict path end-to-end across different domains
* The complete strict path in the source domain followed by boundary * The complete strict path in the source domain followed by
LSRs (or domain identifiers, e.g. AS numbers) boundary LSRs (or domain identifiers, e.g. AS numbers)
* The complete list of boundary LSRs along the path * The complete list of boundary LSRs along the path
* The current boundary LSR and the LSP destination. * The current boundary LSR and the LSP destination.
The set of (loose or strict) hops can either be statically configured The set of (loose or strict) hops can either be statically
on the Head-end LSR or dynamically computed. A per-domain path configured on the Head-end LSR or dynamically computed. A
computation method is defined in this document with an optional Auto- per-domain path computation method is defined in this document with
discovery mechanism based on IGP, BGP, policy routing information an optional Auto-discovery mechanism based on IGP, BGP, policy
yielding the next-hop boundary node (domain exit point, such as ABR/ routing information yielding the next-hop boundary node (domain
ASBR) along the path as the TE LSP is being signaled, along with exit point, such as ABR/ASBR) along the path as the TE LSP is being
potential crankback mechanisms. Alternatively the domain exit points signaled, along with potential crankback mechanisms. Alternatively
may be statically configured on the Head-end LSR in which case next- the domain exit points may be statically configured on the Head-end
hop boundary node auto-discovery would not be required. LSR in which case next-hop boundary node auto-discovery would not
be required.
- Boundary LSRs are assumed to be capable of performing local path - Boundary LSRs are assumed to be capable of performing local path
computation for expansion of a loose next-hop in the signaled ERO if computation for expansion of a loose next-hop in the signaled ERO
the path is not signaled by the Head-end LSR as a set of strict hops if the path is not signaled by the Head-end LSR as a set of strict
or if the strict hop is an abstract node (e.g. an AS). In any case, hops or if the strict hop is an abstract node (e.g. an AS). In any
no topology or resource information needs to be distributed between case, no topology or resource information needs to be distributed
domains (as mandated per [RFC4105] and [RFC4216]), which is critical between domains (as mandated per [RFC4105] and [RFC4216]), which is
to preserve IGP/BGP scalability and confidentiality in the case of TE critical to preserve IGP/BGP scalability and confidentiality in the
LSPs spanning multiple routing domains. case of TE LSPs spanning multiple routing domains.
- The paths for the intra-domain Hierarchical LSPs (H-LSP) or - The paths for the intra-domain Hierarchical LSPs (H-LSP) or
Stitched LSPs (S-LSP) or for a contiguous TE LSP within the domain Stitched LSPs (S-LSP) or for a contiguous TE LSP within the domain
may be pre-configured or computed dynamically based on the arriving may be pre-configured or computed dynamically based on the arriving
inter-domain LSP setup request (depending on the requirements of the inter-domain LSP setup request (depending on the requirements of
transit domain). Note that this capability is explicitly specified the transit domain). Note that this capability is explicitly
as a requirement in [RFC4216]. When the paths for the H-LSPs/S-LSP specified as a requirement in [RFC4216]. When the paths for the
are pre-configured, the constraints as well as other parameters like H-LSPs/S-LSP are pre-configured, the constraints as well as other
local protection scheme for the intra-domain H-LSP/S-LSP are also parameters like local protection scheme for the intra-domain
pre-configured. H-LSP/S-LSP are also pre-configured.
- While certain constraints like bandwidth can be used across - While certain constraints like bandwidth can be used across
different domains, certain other TE constraints like resource different domains, certain other TE constraints like resource
affinity, color, metric, etc. as listed in [RFC2702] may need to be affinity, color, metric, etc. as listed in [RFC2702] may need to be
translated at domain boundaries. If required, it is assumed that, at translated at domain boundaries. If required, it is assumed that,
the domain boundary LSRs, there will exist some sort of local mapping at the domain boundary LSRs, there will exist some sort of local
based on policy agreement in order to translate such constraints mapping based on policy agreement in order to translate such
across domain boundaries. It is expected that such an assumption constraints across domain boundaries. It is expected that such an
particularly applies to inter-AS TE: for example, the local mapping assumption particularly applies to inter-AS TE: for example, the
would be similar to the Inter-AS TE Agreement Enforcement Polices local mapping would be similar to the Inter-AS TE Agreement
stated in [RFC4216]. Enforcement Polices stated in [RFC4216].
- The procedures defined in this document are applicable to any node - The procedures defined in this document are applicable to any node
(not just boundary node) that receives a Path message with an ERO (not just boundary node) that receives a Path message with an ERO
that constains a loose hop or an abstract node that is not a simple that constains a loose hop or an abstract node that is not a simple
abstract node (that is, an abstract node that identifies more than abstract node (that is, an abstract node that identifies more than
one LSR). one LSR).
3.2. Example of topology for the inter-area TE case 3.2. Example of topology for the inter-area TE case
The following example will be used for the inter-area TE case in this The following example will be used for the inter-area TE case in this
skipping to change at page 7, line 49 skipping to change at page 7, line 49
Notes: Notes:
- The terminology used in the example above corresponds to OSPF but - The terminology used in the example above corresponds to OSPF but
the path computation technique proposed in this document equally the path computation technique proposed in this document equally
applies to the case of an IS-IS multi-level network. applies to the case of an IS-IS multi-level network.
- Just a few routers in each area are depicted in the diagram above - Just a few routers in each area are depicted in the diagram above
for the sake of simplicity. for the sake of simplicity.
- The example depicted in Figure 1 shows the case where the Head-end - The example depicted in Figure 1 shows the case where the Head-end
and Tail-end areas are connected by means of area 0. The case of an and Tail-end areas are connected by means of area 0. The case of
inter-area TE LSP between two IGP areas that does not transit through an inter-area TE LSP between two IGP areas that does not transit
area 0 is not precluded. through area 0 is not precluded.
3.3. Example of topology for the inter-AS TE case 3.3. Example of topology for the inter-AS TE case
We consider the following general case, built on a superset of the We consider the following general case, built on a superset of the
various scenarios defined in [RFC4216]: various scenarios defined in [RFC4216]:
<-- AS 1 ---> <------- AS 2 -----><--- AS 3 ----> <-- AS 1 ---> <------- AS 2 -----><--- AS 3 ---->
<---BGP---> <---BGP--> <---BGP---> <---BGP-->
CE1---R0---X1-ASBR1-----ASBR4--R3---ASBR7----ASBR9----R6 CE1---R0---X1-ASBR1-----ASBR4--R3---ASBR7----ASBR9----R6
skipping to change at page 8, line 47 skipping to change at page 8, line 48
- The ASBRs in different ASs are BGP peers. There is usually no IGP - The ASBRs in different ASs are BGP peers. There is usually no IGP
running on the single hop links interconnecting the ASBRs and also running on the single hop links interconnecting the ASBRs and also
referred to as inter-ASBR links. referred to as inter-ASBR links.
- Each AS runs an IGP (IS-IS or OSPF) with the required IGP TE - Each AS runs an IGP (IS-IS or OSPF) with the required IGP TE
extensions (see [RFC3630], [RFC3784], [RFC4203] and [RFC4205]). In extensions (see [RFC3630], [RFC3784], [RFC4203] and [RFC4205]). In
other words, the ASes are TE enabled, other words, the ASes are TE enabled,
- Each AS can be made of several IGP areas. The path computation - Each AS can be made of several IGP areas. The path computation
technique described in this document applies to the case of a single technique described in this document applies to the case of a
AS made of multiple IGP areas, multiples ASs made of a single IGP single AS made of multiple IGP areas, multiples ASs made of a
areas or any combination of the above. For the sake of simplicity, single IGP areas or any combination of the above. For the sake of
each routing domain will be considered as single area in this simplicity, each routing domain will be considered as single area
document. The case of an Inter-AS TE LSP spanning multiple ASs where in this document. The case of an Inter-AS TE LSP spanning multiple
some of those ASs are themselves made of multiple IGP areas can be ASs where some of those ASs are themselves made of multiple IGP
easily derived from the examples above: the per-domain path areas can be easily derived from the examples above: the per-domain
computation technique described in this document is applied path computation technique described in this document is applied
recursively in this case. recursively in this case.
- An inter-AS TE LSP T1 originated at R0 in AS1 and terminating at R6 - An inter-AS TE LSP T1 originated at R0 in AS1 and terminating at R6
in AS3. in AS3.
4. Per-domain path computation procedures 4. Per-domain path computation procedures
The mechanisms for inter-domain TE LSP computation as described in The mechanisms for inter-domain TE LSP computation as described in
this document can be used regardless of the nature of the inter- this document can be used regardless of the nature of the inter-
domain TE LSP (contiguous, stitched or nested). domain TE LSP (contiguous, stitched or nested).
skipping to change at page 10, line 32 skipping to change at page 10, line 32
ERO SHOULD perform an ERO expansion (unless not allowed by policy) ERO SHOULD perform an ERO expansion (unless not allowed by policy)
after having computed the path to the next loose hop (ABR/ASBR) after having computed the path to the next loose hop (ABR/ASBR)
that obeys the set of required constraints. If no path satisfying that obeys the set of required constraints. If no path satisfying
the set of constraints can be found, then this SHOULD be treated the set of constraints can be found, then this SHOULD be treated
as a path computation and signaling failure and an RSVP PathErr as a path computation and signaling failure and an RSVP PathErr
message SHOULD be sent for the inter-domain TE LSP based on message SHOULD be sent for the inter-domain TE LSP based on
section 4.3.4 of [RFC3209]. section 4.3.4 of [RFC3209].
o Case of stitched or nested LSP o Case of stitched or nested LSP
o
* If the boundary LSR is a candidate LSR for intra-area H-LSP/ * If the boundary LSR is a candidate LSR for intra-area H-LSP/
S-LSP setup (the LSR has local policy for nesting or S-LSP setup (the LSR has local policy for nesting or
stitching), the TE LSP is a candidate for hierarchy/nesting stitching), the TE LSP is a candidate for hierarchy/nesting
(the "Contiguous LSP" bit defined in (the "Contiguous LSP" bit defined in
[I-D.ietf-ccamp-inter-domain-rsvp-te] is not set) and if there [I-D.ietf-ccamp-inter-domain-rsvp-te] is not set) and if there
is no H-LSP/S-LSP from this LSR to the next-hop boundary LSR is no H-LSP/S-LSP from this LSR to the next-hop boundary LSR
that satisfies the constraints, it SHOULD signal a H-LSP/S-LSP that satisfies the constraints, it SHOULD signal a H-LSP/S-LSP
to the next-hop boundary LSR. If pre-configured H-LSP(s) or to the next-hop boundary LSR. If pre-configured H-LSP(s) or
S-LSP(s) already exist, then it will try to select from among S-LSP(s) already exist, then it will try to select from among
those intra-domain LSPs. Depending on local policy, it MAY those intra-domain LSPs. Depending on local policy, it MAY
skipping to change at page 11, line 30 skipping to change at page 11, line 28
The ERO of an inter-domain TE LSP may comprise abstract nodes such as The ERO of an inter-domain TE LSP may comprise abstract nodes such as
ASes. In such a case, upon receiving the ERO whose next hop is an ASes. In such a case, upon receiving the ERO whose next hop is an
AS, the boundary LSR has to determine the next-hop boundary LSR which AS, the boundary LSR has to determine the next-hop boundary LSR which
may be determined based on the "auto-discovery" process mentioned may be determined based on the "auto-discovery" process mentioned
above. If multiple ASBRs candidates exist the boundary LSR may apply above. If multiple ASBRs candidates exist the boundary LSR may apply
some policies based on peering contracts that may have been pre- some policies based on peering contracts that may have been pre-
negotiated. Once the next-hop boundary LSR has been determined a negotiated. Once the next-hop boundary LSR has been determined a
similar procedure as the one described above is followed. similar procedure as the one described above is followed.
Note related to the inter-AS TE case Note related to the inter-AS TE case:
In terms of computation of an inter-AS TE LSP path, an interesting In terms of computation of an inter-AS TE LSP path, an interesting
optimization technique consists of allowing the ASBRs to flood the TE optimization technique consists of allowing the ASBRs to flood the
information related to the inter-ASBR link(s) although no IGP TE is TE information related to the inter-ASBR link(s) although no IGP TE
enabled over those links (and so there is no IGP adjacency over the is enabled over those links (and so there is no IGP adjacency over
inter-ASBR links). This of course implies for the inter-ASBR links the inter-ASBR links). This of course implies for the inter-ASBR
to be TE-enabled although no IGP is running on those links. This links to be TE-enabled although no IGP is running on those links.
allows an LSR (could be entry ASBR) in the previous AS to make a more This allows an LSR (could be entry ASBR) in the previous AS to make
appropriate route selection up to the entry ASBR in the immediately a more appropriate route selection up to the entry ASBR in the
downstream AS taking into account the constraints associated with the immediately downstream AS taking into account the constraints
inter-ASBR links. This reduces the risk of call set up failure due associated with the inter-ASBR links. This reduces the risk of
to inter-ASBR links not satisfying the inter-AS TE LSP set of call set up failure due to inter-ASBR links not satisfying the
constraints. Note that the TE information is only related to the inter-AS TE LSP set of constraints. Note that the TE information
inter-ASBR links: the TE LSA/LSP flooded by the ASBR includes not is only related to the inter-ASBR links: the TE LSA/LSP flooded by
only the TE-enabled links contained in the AS but also the inter-ASBR the ASBR includes not only the TE-enabled links contained in the AS
links. but also the inter-ASBR links.
Note that no summarized TE information is leaked between ASes which Note that no summarized TE information is leaked between ASes which
is compliant with the requirements listed in [RFC4105] and [RFC4216]. is compliant with the requirements listed in [RFC4105] and [RFC4216].
For example, consider the diagram depicted in Figure 2: when ASBR1 For example, consider the diagram depicted in Figure 2: when ASBR1
floods its IGP TE LSA ((opaque LSA for OSPF)/LSP (TLV 22 for IS-IS)) floods its IGP TE LSA ((opaque LSA for OSPF)/LSP (TLV 22 for IS-IS))
in its routing domain, it reflects the reservation states and TE in its routing domain, it reflects the reservation states and TE
properties of the following links: X1-ASBR1, ASBR1-ASBR2 and ASBR1- properties of the following links: X1-ASBR1, ASBR1-ASBR2 and ASBR1-
ASBR4. ASBR4.
skipping to change at page 15, line 50 skipping to change at page 16, line 5
6.1. Contiguous TE LSPs 6.1. Contiguous TE LSPs
After an inter-domain TE LSP has been set up, a more optimal route After an inter-domain TE LSP has been set up, a more optimal route
might appear within any traversed domain. Then in this case, it is might appear within any traversed domain. Then in this case, it is
desirable to get the ability to reroute an inter-domain TE LSP in a desirable to get the ability to reroute an inter-domain TE LSP in a
non-disruptive fashion (making use of the so-called Make-Before-Break non-disruptive fashion (making use of the so-called Make-Before-Break
procedure) to follow such more optimal path. This is a known as a TE procedure) to follow such more optimal path. This is a known as a TE
LSP reoptimization procedure. LSP reoptimization procedure.
[I-D.ietf-ccamp-loose-path-reopt] proposes a mechanism that allows [RFC4736] proposes a mechanism that allows the Head-end LSR to be
the Head-end LSR to be notified of the existence of a more optimal notified of the existence of a more optimal path in a downstream
path in a downstream domain. The Head-end LSR may then decide to domain. The Head-end LSR may then decide to gracefully reroute the
gracefully reroute the TE LSP using the so-called Make-Before-Break TE LSP using the so-called Make-Before-Break procedure. In case of a
procedure. In case of a contiguous LSP, the reoptimization process contiguous LSP, the reoptimization process is strictly controlled by
is strictly controlled by the Head-end LSR which triggers the make- the Head-end LSR which triggers the make-before-break procedure,
before-break procedure, regardless of the location of the more regardless of the location of the more optimal path.
optimal path.
6.2. Stitched or nested (non-contiguous) TE LSPs 6.2. Stitched or nested (non-contiguous) TE LSPs
In the case of a stitched or nested inter-domain TE LSP, the In the case of a stitched or nested inter-domain TE LSP, the
reoptimization process is treated as a local matter to any domain. reoptimization process is treated as a local matter to any domain.
The main reason is that the inter-domain TE LSP is a different LSP The main reason is that the inter-domain TE LSP is a different LSP
(and therefore different RSVP session) from the intra-domain S-LSP or (and therefore different RSVP session) from the intra-domain S-LSP or
H-LSP in an area or an AS. Therefore, reoptimization in a domain is H-LSP in an area or an AS. Therefore, reoptimization in a domain is
done by locally reoptimizing the intra-domain H-LSP or S-LSP. Since done by locally reoptimizing the intra-domain H-LSP or S-LSP. Since
the inter-domain TE LSPs are transported using S-LSP or H-LSP across the inter-domain TE LSPs are transported using S-LSP or H-LSP across
skipping to change at page 17, line 10 skipping to change at page 17, line 10
the boundary LSR may either initiate new S-LSP setup, in case the the boundary LSR may either initiate new S-LSP setup, in case the
inter-domain TE LSP is being stitched to the intra-domain S-LSP or it inter-domain TE LSP is being stitched to the intra-domain S-LSP or it
may select an existing or new H-LSP in case of nesting. When the LSP may select an existing or new H-LSP in case of nesting. When the LSP
setup along the current path is complete, the Head-end LSR should setup along the current path is complete, the Head-end LSR should
switchover the traffic onto that path and the old path is eventually switchover the traffic onto that path and the old path is eventually
torn down. Note that the Head-end LSR does not know a priori whether torn down. Note that the Head-end LSR does not know a priori whether
a more optimal path exists. Such a manual trigger from the Head-end a more optimal path exists. Such a manual trigger from the Head-end
LSR of the inter-domain TE LSP is, however, not considered to be a LSR of the inter-domain TE LSP is, however, not considered to be a
frequent occurrence. frequent occurrence.
Procedures described in [I-D.ietf-ccamp-loose-path-reopt] MUST be Procedures described in [RFC4736] MUST be used if the operator does
used if the operator does not desire local reoptimization of certain not desire local reoptimization of certain inter-domain LSPs. In
inter-domain LSPs. In this case, any reoptimization event within the this case, any reoptimization event within the domain MUST be
domain MUST be reported to the Head-end node. This SHOULD be a reported to the Head-end node. This SHOULD be a configurable policy.
configurable policy.
6.3. Path characteristics after reoptimization 6.3. Path characteristics after reoptimization
Note that in the case of loose hop reoptimization of contiguous Note that in the case of loose hop reoptimization of contiguous
inter-domain TE LSP or local reoptimization of stitched/nested S-LSP inter-domain TE LSP or local reoptimization of stitched/nested S-LSP
where boundary LSRs are specified as loose hops, the TE LSP may where boundary LSRs are specified as loose hops, the TE LSP may
follow a preferable path within one or more domain(s) but would still follow a preferable path within one or more domain(s) but would still
traverse the same set of boundary LSRs. In contrast, in the case of traverse the same set of boundary LSRs. In contrast, in the case of
PCE-based path computation techniques, because end to end optimal PCE-based path computation techniques, because end to end optimal
path is computed, the reoptimization process may lead to following a path is computed, the reoptimization process may lead to following a
skipping to change at page 18, line 31 skipping to change at page 18, line 31
according to the procedure defined in this document requires path according to the procedure defined in this document requires path
computation on boundary nodes that may be exposed to various attacks. computation on boundary nodes that may be exposed to various attacks.
Thus it is RECOMMENDED to support policy decisions to reject the ERO Thus it is RECOMMENDED to support policy decisions to reject the ERO
expansion of an inter-domain TE LSP if not allowed. expansion of an inter-domain TE LSP if not allowed.
9. Acknowledgements 9. Acknowledgements
We would like to acknowledge input and helpful comments from Adrian We would like to acknowledge input and helpful comments from Adrian
Farrel, Jean-Louis Le Roux, Dimitri Papadimitriou and Faisal Aslam. Farrel, Jean-Louis Le Roux, Dimitri Papadimitriou and Faisal Aslam.
Adrian Farrel prepared the final verison of this document for IESG
review.
10. References 10. References
10.1. Normative References 10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, September 1997.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001. Tunnels", RFC 3209, December 2001.
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Resource ReserVation Protocol-Traffic (GMPLS) Signaling Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
(TE) Extensions to OSPF Version 2", RFC 3630,
September 2003.
[RFC3784] Smit, H. and T. Li, "Intermediate System to Intermediate
System (IS-IS) Extensions for Traffic Engineering (TE)",
RFC 3784, June 2004.
[RFC4203] Kompella, K. and Y. Rekhter, "OSPF Extensions in Support
of Generalized Multi-Protocol Label Switching (GMPLS)",
RFC 4203, October 2005.
[RFC4205] Kompella, K. and Y. Rekhter, "Intermediate System to
Intermediate System (IS-IS) Extensions in Support of
Generalized Multi-Protocol Label Switching (GMPLS)",
RFC 4205, October 2005.
10.2. Informative References 10.2. Informative References
[I-D.ietf-ccamp-crankback] [I-D.ietf-ccamp-crankback]
Farrel, A., "Crankback Signaling Extensions for MPLS and Farrel, A., "Crankback Signaling Extensions for MPLS and
GMPLS RSVP-TE", draft-ietf-ccamp-crankback-06 (work in GMPLS RSVP-TE", draft-ietf-ccamp-crankback (work in
progress), January 2007. progress).
[I-D.ietf-ccamp-inter-domain-rsvp-te] [I-D.ietf-ccamp-inter-domain-rsvp-te]
Ayyangar, A. and J. Vasseur, "Inter domain MPLS and GMPLS Ayyangar, A. and J. Vasseur, "Inter domain MPLS and GMPLS
Traffic Engineering - RSVP-TE extensions", Traffic Engineering - RSVP-TE extensions",
draft-ietf-ccamp-inter-domain-rsvp-te-04 (work in draft-ietf-ccamp-inter-domain-rsvp-te (work in
progress), January 2007. progress.
[I-D.ietf-ccamp-loose-path-reopt]
Vasseur, J., "Reoptimization of Multiprotocol Label
Switching (MPLS) Traffic Engineering (TE) loosely routed
Label Switch Path (LSP)",
draft-ietf-ccamp-loose-path-reopt-02 (work in progress),
February 2006.
[I-D.ietf-ccamp-lsp-stitching] [I-D.ietf-ccamp-lsp-stitching]
Ayyangar, A., "Label Switched Path Stitching with Ayyangar, A., "Label Switched Path Stitching with
Generalized MPLS Traffic Engineering", Generalized MPLS Traffic Engineering",
draft-ietf-ccamp-lsp-stitching-04 (work in progress), draft-ietf-ccamp-lsp-stitching (work in progress).
December 2006.
[RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. [RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J.
McManus, "Requirements for Traffic Engineering Over MPLS", McManus, "Requirements for Traffic Engineering Over MPLS",
RFC 2702, September 1999. RFC 2702, September 1999.
[RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic [RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic
Authentication", RFC 2747, January 2000. Authentication", RFC 2747, January 2000.
[RFC3097] Braden, R. and L. Zhang, "RSVP Cryptographic [RFC3097] Braden, R. and L. Zhang, "RSVP Cryptographic
Authentication -- Updated Message Type Value", RFC 3097, Authentication -- Updated Message Type Value", RFC 3097,
April 2001. April 2001.
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
(TE) Extensions to OSPF Version 2", RFC 3630,
September 2003.
[RFC3784] Smit, H. and T. Li, "Intermediate System to Intermediate
System (IS-IS) Extensions for Traffic Engineering (TE)",
RFC 3784, June 2004.
[RFC4105] Le Roux, J., Vasseur, J., and J. Boyle, "Requirements for [RFC4105] Le Roux, J., Vasseur, J., and J. Boyle, "Requirements for
Inter-Area MPLS Traffic Engineering", RFC 4105, June 2005. Inter-Area MPLS Traffic Engineering", RFC 4105, June 2005.
[RFC4203] Kompella, K. and Y. Rekhter, "OSPF Extensions in Support
of Generalized Multi-Protocol Label Switching (GMPLS)",
RFC 4203, October 2005.
[RFC4205] Kompella, K. and Y. Rekhter, "Intermediate System to
Intermediate System (IS-IS) Extensions in Support of
Generalized Multi-Protocol Label Switching (GMPLS)",
RFC 4205, October 2005.
[RFC4216] Zhang, R. and J. Vasseur, "MPLS Inter-Autonomous System [RFC4216] Zhang, R. and J. Vasseur, "MPLS Inter-Autonomous System
(AS) Traffic Engineering (TE) Requirements", RFC 4216, (AS) Traffic Engineering (TE) Requirements", RFC 4216,
November 2005. November 2005.
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
Element (PCE)-Based Architecture", RFC 4655, August 2006. Element (PCE)-Based Architecture", RFC 4655, August 2006.
[RFC4726] Farrel, A., Vasseur, J., and A. Ayyangar, "A Framework for [RFC4726] Farrel, A., Vasseur, J., and A. Ayyangar, "A Framework for
Inter-Domain Multiprotocol Label Switching Traffic Inter-Domain Multiprotocol Label Switching Traffic
Engineering", RFC 4726, November 2006. Engineering", RFC 4726, November 2006.
[RFC4736] Vasseur, J., Ikejiri, Y., and R. Zhang, "Reoptimization of
Multiprotocol Label Switching (MPLS) Traffic Engineering
(TE) Loosely Routed Label Switched Path (LSP)", RFC 4736,
November 2006.
Authors' Addresses Authors' Addresses
JP Vasseur (editor) JP Vasseur (editor)
Cisco Systems, Inc Cisco Systems, Inc
1414 Massachusetts Avenue 1414 Massachusetts Avenue
Boxborough, MA 01719 Boxborough, MA 01719
USA USA
Email: jpv@cisco.com Email: jpv@cisco.com
 End of changes. 28 change blocks. 
130 lines changed or deleted 117 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/