Early chair review of draft-ietf-ccamp-inter-domain-pd-path-comp-00.txt
"Adrian Farrel" <adrian@olddog.co.uk> Thu, 23 June 2005 12:31 UTC
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlQrE-0000LX-N8 for ccamp-archive@megatron.ietf.org; Thu, 23 Jun 2005 08:31:01 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04330 for <ccamp-archive@ietf.org>; Thu, 23 Jun 2005 08:30:59 -0400 (EDT)
Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DlRFT-00014L-Gd for ccamp-archive@ietf.org; Thu, 23 Jun 2005 08:56:09 -0400
Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DlQa8-000HF8-W0 for ccamp-data@psg.com; Thu, 23 Jun 2005 12:13:20 +0000
Received: from [80.168.70.142] (helo=relay2.mail.uk.clara.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DlQa4-000HEi-Jg for ccamp@ops.ietf.org; Thu, 23 Jun 2005 12:13:17 +0000
Received: from du-069-0098.access.clara.net ([217.158.132.98] helo=Puppy) by relay2.mail.uk.clara.net with smtp (Exim 4.50) id 1DlQZn-000IOY-7o; Thu, 23 Jun 2005 13:13:10 +0100
Message-ID: <0b3401c577ed$399fdde0$7f849ed9@Puppy>
Reply-To: Adrian Farrel <adrian@olddog.co.uk>
From: Adrian Farrel <adrian@olddog.co.uk>
To: 'Jean Philippe Vasseur' <jvasseur@cisco.com>, Arthi Ayyangar <arthi@juniper.net>, raymond.zhang@bt.infonet.com
Cc: ccamp@ops.ietf.org
Subject: Early chair review of draft-ietf-ccamp-inter-domain-pd-path-comp-00.txt
Date: Thu, 23 Jun 2005 13:14:03 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00, RCVD_IN_SORBS_WEB autolearn=ham version=3.0.2
Sender: owner-ccamp@ops.ietf.org
Precedence: bulk
X-Spam-Score: 2.9 (++)
X-Scan-Signature: 1e0b649fc926c4eb742aefef668fc35e
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id IAA04330
Hi, I have done an early review of this I-D because the authors indicated that it was "fully stable". I think there is a fair about of work to be done on the text. See the comments below. I have not caught all of the typos, I am sure. Also worried that the number of changes needed may have obscured some technical issues, so we will have to go around this at least once more. Thanks, Adrian =========== ## Please sort out the formatting so that paragraphs are indented CCAMP Working Group JP Vasseur (Editor) ## Should say "Network Working Group" IETF Internet draft Cisco Systems, Inc. Proposed Status: Standard Arthi Ayyangar (Editor) Juniper Networks Raymond Zhang Infonet Service Corporation Expires: October 2005 April 2005 draft-ietf-ccamp-inter-domain-pd-path-comp-00.txt ## Would a more precise title be as follows? ## Also s/Path/Paths/ ## A Per-domain path computation method for establishing Inter-domain Traffic ## Engineering (TE) Label Switched Paths (LSPs) Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or 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. ## Need new IPR boilerplate This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are Working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. ## Don't need old 2026 boilerplate. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document specifies a per-domain path computation method for computing inter-domain Traffic Engineering (TE) Multiprotocol Label ## s/computing/establishing/ Switching (MPLS) and Generalized MPLS (GMPLS) Label Switched (LSP) paths. ## "Label Switched Paths (LSPs)" In this document a domain is referred to as a collection of ## s/is referred to as/refers to/ network elements within a common sphere of address management or path computational responsibility such as IGP areas and Autonomous Systems. Vasseur, Ayyangar and Zhang 1 draft-ietf-ccamp-inter-domain-pd-path-comp-00.txt April 2005 ## The next paragraph is a bit unclear. Why not it with... ## Per-domain computation applies where the full route to an ## inter-domain LSP cannot be or is not determined at the ingress ## point of the LSP, and is not signaled across domain boundaries. ## This is most likely to arrise owing to TE visibilty limitations. ## The signaling message indicates the destination and nodes up to ## the next domain boundary. It may also indicate further domain ## boundaries or domain identifiers. The route through each domain, ## possibly including the choice of exit point from the domain, ## must be determined within the domain. The principle of per-domain path computation specified in this document comprises of a GMPLS or MPLS node along an inter-domain LSP path, computing a path up to the last reachable hop within its domain. It covers cases where this last hop (domain exit point) may already be specified in the signaling message as well the case where this last hop may need to be determined by the GMPLS node. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Table of content 1. Terminology ............................................. 3 2. Introduction ............................................ 4 3. General assumptions ..................................... 5 4. Per-Domain path computation algorithm ................... 8 4.1 Example with an inter-area TE LSP ...................... 9 4.1.1 Case 1: T1 is a contiguous TE LSP .................... 9 4.1.2 Case 2: T1 is a stitched or nested TE LSP ............ 10 4.2 Example with an inter-AS TE LSP ........................ 11 4.2.1 Case 1: T1 is a contiguous TE LSP ................... 12 4.2.2 Case 2: T1 is a stitched or nested TE LSP ........... 13 5 Path optimality/diversity ................................ 13 6 MPLS Traffic Engineering Fast Reroute for inter-domain TE LSPs ................................................. 13 6.1 Failure of an internal network element ................. 14 6.2 Failure of an inter-ASBR links (inter-AS TE) ........... 14 6.3 Failure of an ABR or an ASBR node ...................... 14 7. Reoptimization of an inter-domain TE LSP ................ 14 7.1 Contiguous TE LSPs ..................................... 14 7.2 Stitched or nested (non-contiguous) TE LSPs ............ 15 8. Security Considerations ................................. 16 9. Intellectual Property Considerations .................... 17 10 References .............................................. 17 10.1 Normative references .................................. 17 10.2 Informative references ................................ 18 Vasseur, Ayyangar and Zhang 2 draft-ietf-ccamp-inter-domain-pd-path-comp-00.txt April 2005 1. Terminology ABR Routers: routers used to connect two IGP areas (areas in OSPF or L1/L2 in IS-IS) ##replace "L1/L2" with "levels" ## Missing ASBR. Just point to Interconnect routers Boundary LSR: a boundary LSR is either an ABR in the context of inter- area MPLS TE or an ASBR in the context of inter-AS MPLS TE. Bypass Tunnel: an LSP that is used to protect a set of LSPs passing over a common facility. CSPF: Constraint-based Shortest Path First. ## I searched for the uses of this acronym and I thought all of them ## should be less specific (that is allowing any path computation ## technique). In which case, you will not need this in the terminology ## section. Fast Reroutable LSP: any LSP for which the "Local protection desired" bit is set in the Flag field of the SESSION_ATTRIBUTE object of its Path messages or signaled with a FAST-REROUTE object. ## This term is not used. It can be deleted. Interconnect routers or ASBR routers: routers used to connect together ASes of a different or the same Service Provider via one or more Inter- AS links. Inter-AS MPLS TE LSP: A TE LSP whose head-end LSR and tail-end LSR do not reside within the same Autonomous System (AS), or whose head-end LSR and tail-end LSR are both in the same AS but the TE LSPÆs path ## Non-ASCII character. This would not happen if you ran idnits ## before submission. I have not flagged the *many* other non-ASCII ## characters. Please fix. may be across different ASes. Note that this definition also applies to TE LSP whose Head-end and Tail-end LSRs reside in different sub-ASes (BGP confederations). ## So, to summarise this definition... ## A TE LSP that crosses an AS boundary. Inter-area MPLS TE LSP: A TE LSP where the head-end LSR and tail-end LSR do not reside in the same area or both the head-end and tail end LSR reside in the same area but the TE LSP transits one or more different areas along the path. ## To summarise again... ## A TE LSP that crosses an area boundary. LSR: Label Switch Router ## Aaaaagh! ## Label Switching Router (come back after class and write this out ## a hundred times!) LSP: MPLS Label Switched Path Local Repair: local protection techniques used to repair TE LSPs quickly when a node or link along the LSPs path fails. ## Term not used in this I-D. Please delete. MP: Merge Point. The LSR where bypass tunnels meet the protected LSP. ## Term not used in this I-D. Please delete. NHOP Bypass Tunnel: Next-Hop Bypass Tunnel. A backup tunnel which bypasses a single link of the protected LSP. ## Term not used in this I-D. Please delete. NNHOP Bypass Tunnel: Next-Next-Hop Bypass Tunnel. A backup tunnel which bypasses a single node of the protected LSP. ## Term not used in this I-D. Please delete. Vasseur, Ayyangar and Zhang 3 draft-ietf-ccamp-inter-domain-pd-path-comp-00.txt April 2005 PCE: Path Computation Element. An LSR in charge of computing TE LSP path for which it is not the Head-end. For instance, an ABR (inter- area) or an ASBR (Inter-AS) can play the role of PCE. PCC: Path Computation Client (any head-end LSR) requesting a path computation from the Path Computation Element. ## Term not used in this I-D. Please delete or use. Protected LSP: an LSP is said to be protected at a given hop if it has one or multiple associated backup tunnels originating at that hop. ## Term not used in this I-D. Please delete. PLR: Point of Local Repair. The head-end of a bypass tunnel. ## Term not used in this I-D. Please delete. TED: MPLS Traffic Engineering Database The notion of contiguous, stitched and nested TE LSPs is defined in [INTER-DOMAIN-SIG] and [LSP-STITCHING] and will not be repeated here. ## May be better to refer to the framework I-D. 2. Introduction The requirements for inter-area and inter-AS MPLS Traffic Engineering have been developed by the Traffic Engineering Working Group and have been stated in [INTER-AREA-REQS] and [INTER-AS-REQS] respectively. The ## Throughout this document you must make the following changes ## s/[INTER-AREA-TE-REQS]/[INT-AREA-REQS]/ ## s/[INTER-AREA-REQS]/[INT-AREA-REQS]/ ## s/[INTER-AS-TE-REQS]/[INT-AS-REQS]/ ## s/[INTER-AS-REQS]/[INT-AS-REQS]/ ## s/[INTER-DOMAIN-FRAMEWORK]/[INT-DOMAIN-FRWK]/ framework for inter-domain MPLS Traffic Engineering has been provided in [INTER-DOMAIN-FRAMEWORK]. The set of mechanisms to establish and maintain inter-domain TE LSPs are specified in [INTER-DOMAIN-SIG] and [LSP-STITCHING]. ## Not sure about "the set of". "Some of" would be better. ## For example, is the mechanism described here also described in those ## I-Ds? ## Maybe even delete this paragraph. This document exclusively focuses on the path computation aspects and defines a method for computing inter-domain TE LSP paths where each node in charge of computing a section of an inter-domain TE LSP path is always along the path of such LSP. When the visibility of an end to end complete path spanning multiple domains is not available at the head end node, one approach described in the document consists of using a per-domain path computation scheme ## which document? this document? used during LSP setup to determine the inter-domain LSP path as it traverses multiple domains. Note that the mechanisms proposed in this document could also be applicable to MPLS TE domains other than areas and ASes. According to the wide set of requirements defined in [INTER-AS-TE-REQS] and [INTER-AREA-TE-REQS], coming up with a single solution covering all the requirements is certainly possible but may not be desired: indeed, as described in [INTER-AS-TE-REQS] the spectrum of deployment scenarios is quite large and designing a solution addressing the super-set of all the requirements would lead to providing a rich set of mechanisms not required in several cases. Depending on the deployment scenarios of a SP, certain requirements stated above may be strict while certain other requirements may be relaxed. ## Useful information. Could benefit from rewording. ## Your message is what? ## The solution in this document does not attempt to address all the ## requirements specified in [INT-AREA-REQS] and [INT-AS-REQS]. This ## is acceptible according to [INT-AS-REQS] which indicates that a ## solution may be developed tuned to a particular deployment scenario ## and might, therefore, not meet all requirements for other deployment ## scenarios. The procedures described in this document apply to the ## specific deployment scenario just described. Vasseur, Ayyangar and Zhang 4 draft-ietf-ccamp-inter-domain-pd-path-comp-00.txt April 2005 ## The next paragpraph is true but irrelevant to this I-D. There are different ways in which inter-domain TE LSP path computation may be performed. For example, if the requirement is to get an end-to- end constraint-based shortest path across multiple domains, then a mechanism using one or more distributed PCEs could be used to compute the shortest path across different domains. Alternatively, one could also use some static or discovery mechanisms to determine the next boundary LSR per domain as the inter-domain TE LSP is being signaled. Other offline mechanisms for path computation are not precluded either. Depending on the Service ProviderÆs requirements, one may adopt either of these techniques for inter-domain path computation. ## First sentence is not needed. ## First half of second sentence has already been said. ## Move second half of second sentence to live with the first instance ## of the first half of the second sentence. Note that the adequate path computation method may be chosen based upon the TE LSP characteristics and requirements. This document specifies an inter-domain path computation technique based on per-domain path computation and could be used in place or in conjunction with other techniques. 3. General assumptions In the rest of this document, we make the following set of assumptions: ## Shouldn't 1), 2) etc. be 3.1, 3.2 etc.? 1) Common assumptions - 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 RSVP- TE). A domain may itself comprise multiple other domains. E.g. An AS may itself be composed of several other sub-AS(es) (BGP confederations) or areas/levels. ## The formatting in the next bullets could use some work. - The inter-domain LSPs are signaled using RSVP-TE ([RSVP-TE]). - The path (ERO) for the inter-domain TE LSP traversing multiple areas/ASes may be signaled as a set of (loose and/or strict) hops. The ## delete "traversing multiple areas/ASes" hops may identify: - The complete strict path end to end across different areas/ASes - The complete strict path in the source area/AS followed by boundary LSRs (and domain identifiers, e.g. AS numbers) ## s/and/or/ ? - The complete list of boundary LSRs along the path - The current boundary LSR and the LSP destination ## This reads a little as though the destination can only be ## present in the final case. In this case, the set of (loose or strict) hops can either be ## In which case? statically configured on the Head-end LSR or dynamically computed. In the former case, the resulting path is statically configured on the Head-end LSR. In the latter case (dynamic computation), a per-domain path computation method is defined in this document with some Auto- discovery mechanism based on BGP and/or IGP information yielding the next-hop boundary node (domain exit point, say ABR/ASBR) along the path as the LSP is being signaled, along with crankback mechanisms. Note Vasseur, Ayyangar and Zhang 5 draft-ietf-ccamp-inter-domain-pd-path-comp-00.txt April 2005 that alternatively next-hop may be statically configured on the Head- end LSR in which case next-hop auto-discovery would not be needed. - Furthermore, the boundary LSRs are assumed to be capable of performing local path computation for expansion of a loose next-hop in the signaled ERO if the path is not signaled by the head-end LSR as a set of strict hops or if the strict hop is an abstract node (e.g. an AS). This can be done by performing a CSPF computation up to that next ## Why do you mention CSPF? The path computation algorithm in use is ## surely not relevant to this I-D. loose hop as opposed to the TE LSP destination or by making use of some PCEs. In any case, no topology or resource information needs to be distributed between areas/ASes (as mandated per [INTER-AREA-REQS] and [INTER-AS-REQS]), which is critical to preserve IGP/BGP scalability and confidentiality in the case of TE LSPs spanning multiple routing domains. Note that PCE-based path computation may be mentioned in this document for the sake of reference but such techniques are outside the scope of this document. ## Then don't mention them. - The paths for the intra-domain FA-LSPs or LSP segments or for a contiguous TE LSP within the area/AS, may be pre-configured or computed dynamically based on the arriving inter-domain LSP setup request; depending on the requirements of the transit area/AS. Note that this capability is explicitly specified as a requirement in [INTER-AS-TE- REQS]. When the paths for the FA-LSPs/LSP segments are pre-configured, the constraints as well as other parameters like local protection scheme for the intra-area/AS FA-LSP/LSP segment are also pre- configured. - While certain constraints like bandwidth can be used across different areas/ASes, certain other TE constraints like resource affinity, color, metric, etc. as listed in [RFC2702] could be translated at areas/ASes boundaries. If required, it is assumed that, at the area/AS boundary LSRs, there will exist some sort of local mapping based on offline policy agreement, in order to translate such constraints across area/AS boundaries. It is expected that such an assumption particularly applies to inter-AS TE: for example, the local mapping would be similar to the Inter-AS TE Agreement Enforcement Polices stated in [INTER-AS-TE-REQS]. 2) Example of topology for the inter-area TE case The following example will be used for the inter-area TE case in this document. ## Formatting of figure is broken <--area1--><---area0---><----area2-----> ------ABR1------------ABRÆ1------- | / | | \ | R0--X1 | | X2---X3--R1 | | | / | -------ABR2-----------ABRÆ2------ <=========== Inter-area TE LSP =======> Vasseur, Ayyangar and Zhang 6 draft-ietf-ccamp-inter-domain-pd-path-comp-00.txt April 2005 Assumptions ## Do you need to say that you also support the case where area2 is ## not a spearate area, but is part of area 1? ## ## Do you support routing across (i.e. into and out of) an area ## that is not area zero? ## The following is not a list of assumptions, it is part of the ## explanation of the example. - ABR1, ABR2, ABRÆ1 and ABRÆ2 are ABRs, - X1: an LSR in area 1, - X2, X3: LSRs in area 2, - An inter-area TE LSP T0 originated at R0 in area1 and terminating at R1 in area2, Notes: - The terminology used in the example above corresponds to OSPF but the path computation methods proposed in this document equally applies to the case of an IS-IS multi-levels network. ## s/levels/level/ - Just a few routers in each area are depicted in the diagram above for the sake of simplicity. 3) Example of topology for the inter-AS TE case: We will consider the following general case, built on a superset of the various scenarios defined in [INTER-AS-TE-REQS]: ## Formatting of figure is broken <-- AS 1 ---> <------- AS 2 -----><--- AS 3 ----> <---BGP---> <---BGP--> CE1---R0---X1-ASBR1-----ASBR4ù-R3---ASBR7-ù--ASBR9----R6 |\ \ | / | / | / | | | | \ ASBR2---/ ASBR5 | -- | | | | \ | | |/ | | | R1-R2ù--ASBR3ù----ASBR6ù-R4---ASBR8ù---ASBR10ù--R7---CE2 <======= Inter-AS TE LSP(LSR to LSR)===========> or <======== Inter-AS TE LSP (CE to ASBR => or <================= Inter-AS TE LSP (CE to CE)===============> Formatted: The diagram above covers all the inter-AS TE deployment cases described in [INTER-AS-TE-REQS]. ## Be careful to separate the assumptions (which are good to have) from ## the explanation of the example. Assumptions: - Three interconnected ASes, respectively AS1, AS2, and AS3. Note that AS3 might be AS1 in some scenarios described in [INTER-AS-TE-REQS], ## A beautifully phrased note :-) ## Please tell me, when AS3 is AS1, what is AS1? - The various ASBRs are BGP peers, without any IGP running on the single hop links interconnecting the ASBRs and also referred to as inter-ASBR links, ## Whoah! I hope you will explain why you *need* to run BGP, and ## how you will manage non-TE distribution of reachability ## information when the destination of a TE-LSP is a TE address. ## Will you perhaps be mandating (stronger than recommending) that ## the destination of an inter-AS TE LSP is the TE Router ID of ## the egress in order to be sure that this address is one of the ## reachable addresses advertised by BGP? Vasseur, Ayyangar and Zhang 7 draft-ietf-ccamp-inter-domain-pd-path-comp-00.txt April 2005 - Each AS runs an IGP (IS-IS or OSPF) with the required IGP TE extensions (see [OSPF-TE] and [IS-IS-TE]). In other words, the ASes are ## s/[IS-IS-TE]/[ISIS-TE]/ TE enabled, ## and/or GMPLS extensions, please (since we are in CCAMP) - Each AS can be made of several IGP areas. The path computation techniques described in this document applies to the case of a single ## s/applies/apply/ AS made of multiple IGP areas, multiples ASes made of a single IGP ## s/of a single/of single/ areas or any combination of the above. For the sake of simplicity, each routing domain will be considered as single area in this document. ## A very nice simplification, but hardly real-world. So you need ## to explain how to handle multiple areas in an AS in the inter-AS ## case. I don't think this is hard to explain since you just ## recursively apply the techniques. - An inter-AS TE LSP T1 originated at R0 in AS1 and terminating at R6 in AS3. 4. Per-domain path computation algorithm Regardless of the nature of the inter-domain TE LSP (contiguous, stitched or nested), a similar set of mechanisms for local TE LSP path computation (next hop resolution) can be used. ## "A similar set can be used." Could you perhaps be more vague? :-) ## Do try to have some backbone. When an ABR/ASBR receives a Path message with a loose next-hop or an abstract node in the ERO, then it carries out the following actions: ## Mutter, mutter. All ERO hops are abstract nodes. ## You need "non-simple abstract node". I prefer "Widely-scoped ## abstract node" but this is not defined anywhere. 1) It checks if the loose next-hop is accessible via the TED. If the ## perhaps you can just drop the word "loose" because we have already ## established that the next-hop is either loose or non-simple. loose next-hop is not present in the TED, then it checks if the next- hop at least has IP reachability (via IGP or BGP). If the next-hop is not reachable, then the path computation stops and the LSR sends back a PathErr upstream. If the next-hop is reachable, then it finds an ABR/ASBR to get to the next-hop. In the absence of an auto-discovery mechanism, the ABR in the case of inter-area TE or the ASBR in the next-hop AS in the case of inter-AS TE should be the loose next-hop in the ERO and hence should be accessible via the TED, otherwise the path computation for the inter-domain TE LSP will fail. ## I would like you to make it VERY clear what you are doing here. ## You are using the Routing Database to make TE routing decisions. ## This may (or may not) be OK in people's minds ## I will send separate mail to the CCAMP list because this is a BIG ## DEAL in GMPLS networks. ## In any case, can you please clarify that this process MUST NOT be ## used when the next-hop is within the same domain but does not ## appear in the TED, or does not have TE connectivity available. ## Presumably in the case above, presumably the boundary LSR is ## inserted into the ERO as a loose hop, and then we can tun on ## to the next item. 2) If the next-hop boundary LSR is present in the TED. a) Case of a contiguous TE LSP. The ABR/ASBR just performs an ## Which ABR/ASBR? The one in the TED or the one processing the ERO? ERO expansion (unless not allowed by policy) after having computed the path to the next loose hop (ABR/ASBR) that obeys the set of required constraints. If no path satisfying the set of constraints can be found, the path computation stops and a Path Error MUST be sent for the inter-domain TE LSP. b) Case of stitched or nested LSP ## You appear to say the same thing twice in this next point ## although the SHOULDs and MAYs get a bit garbled. ## I think that the SHOULD/MAY distinction is a mess anyway :-) ## If there is already an FA in place, the computing node will not ## know it as any different in the TED, and will compute to use ## it according to constraints and metrics. No option for "SHOULD" ## because it will just happen. ## The trigger for setting up a new FA is clearly local Policy and ## you should highlight this. i) if the ABR/ASBR (receiving the LSP setup request) is a candidate LSR for intra-area FA-LSP/LSP segment setup, and if there is no FA-LSP/LSP segment from this LSR to the next-hop boundary LSR (satisfying the constraints) it SHOULD signal a FA-LSP/LSP segment to the next-hop boundary LSR. If pre-configured FA-LSP(s) Vasseur, Ayyangar and Zhang 8 draft-ietf-ccamp-inter-domain-pd-path-comp-00.txt April 2005 or LSP segment(s) already exist, then it SHOULD try to select from among those intra-area/AS LSPs. Depending on local policy, it MAY signal a new FA-LSP/LSP segment if this selection fails. If the FA-LSP/LSP segment is successfully signaled or selected, it propagates the inter-domain Path message to the next-hop following the procedures described in [LSP-HIER]. If, for some reason the dynamic FA-LSP/LSP segment setup to the next-hop boundary LSR fails, the path computation stops and a ## Is it the path computation that stops? ## Is there no scope for retires or fall-back to ordinary routing? PathErr is sent upstream for the inter-domain LSP. Similarly, if selection of a preconfigured FA-LSP/LSP segment fails and local policy prevents dynamic FA- LSP/LSP segment setup, then the path computation stops and a PathErr is sent upstream for the inter-domain TE LSP. ii) If, however, the boundary LSR is not a FA-LSP/LSP segment candidate, then it SHOULD simply compute a CSPF ## Again, why is CSPF the important choice? path up to the next-hop boundary LSR carry out an ERO expansion to the next-hop boundary LSR) and propagate the Path message downstream. The outgoing ERO is modified after the ERO expansion to the loose next-hop. ## b) ii) seems to be identical to a). ## Is it possible that you need to tell us that the type of inter- ## domain LSP that is desired is part of the Path message? Note that in both cases, path computation may be stopped due to some local policy. 4.1. Example with an inter-area TE LSP 4.1.1. Case 1: T1 is a contiguous TE LSP ## I think your example should start at the ingress! It seems you ## cut back to that after the first paragraph. ## What does the user supply? What does the ingress compute? ## How is ABR1 selected? (I like ABR2: it is a nicer color. Why ## can't I have ABR2?) ## There is also some repeated text in this section. ## Also, why are you considering Example 1 since it is out of scope ## for you? ## Presumably, Example 3 only applies if areas 1 and 2 are actually ## part of the same area, so you should say so. When the path message reaches ABR1, it first determines the egress LSR from its area 0 along the LSP path (say ABRÆ1), either directly from the ERO (if for example the next hop ABR is specified as a loose hop in the ERO) or by using some constraint-aware auto-discovery mechanism. In ## Wow! "A constraint-aware auto-discovery mechanism." I borrowed ## one of those from Batman once, but I could never get it to work. ## What are you talking about? ## Yes, I see this in section 3, 1) and in section 4, 1) but it does ## not explain what you are suggesting may exist. I must say it sounds ## suspisciously like TE aggregation advertisement using BGP. the former case, every inter-AS TE LSP path is defined as a set of loose and strict hops but at least the ABRs traversed by the inter-area TE LSP MUST be specified as loose hops on the head-End LSR. - Example 1 (set of strict hops end to end): R0-X1-ABR1-ABRÆ1-X2-X3-R1 - Example 2 (set of loose hops): R0-ABR1(loose)-ABRÆ1(loose)-R1(loose) - Example 3 (mix of strict and loose hops): R0-X1-ASBR1-ABRÆ1(loose)- X2-X3-R1 At least, the set of ABRs from the TE LSP head-end to the tail-End MUST be present in the ERO as a set of loose hops. Optionally, a set of paths can be configured on the head-end LSR, ordered by priority. Each priority path can be associated with a different set of constraints. ## I don't think this type of implementation detail is needed in the ## I-D. It is out of the scope of the protocol. Typically, it might be desirable to systematically have a last resort ## "Typically, it might be desirable"? You sound unsure! ## Anyway, this whole paragrpah is also an implementation detail, and ## not part of a protocol spec. You are not expecting the ingress to ## make this decision on its own, so there is no need to cover it. ## (You can put it in the MIB if you like!) option with no constraint to ensure that the inter-area TE LSP could always be set up if at least a path exists between the inter-area TE ## "a path"? Perhaps "a TE path". Vasseur, Ayyangar and Zhang 9 draft-ietf-ccamp-inter-domain-pd-path-comp-00.txt April 2005 LSP source and destination. Note that in case of set up failure or when an RSVP Path Error is received indicating the TE LSP has suffered a ## Inconsistent "Path Error" and "PathErr" failure, an implementation might support the possibility to retry a particular path option a specific amount of time (optionally with ## amount of time or number of times? dynamic intervals between each trial) before trying a lower priority path option. Any path can be defined as a set of loose and strict hops. In other words, in some cases, it might be desirable to rely on the dynamic path computation in some area, and exert a strict control on the path in other areas (defining strict hops). Once it has computed the path up to the next ABR, ABR1 sends the Path message for the inter-area TE LSP to ABRÆ1. ABRÆ1 then repeats the a similar procedure and the Path message for the inter-area TE LSP will reach the destination R1. If ABRÆ1 cannot find a path obeying the set of constraints for the inter-area TE LSP, the path computation stops ## Again, is it the computation that stops? I think it has already ## stopped when you couldn't find a path. That is how you know you ## couldn't find a path. and ABRÆ1 MUST send a PathErr message to ABR1. Then ABR1 can in turn triggers a new computation by selecting another egress boundary LSR ## s/triggers/trigger/ (ABRÆ2 in the example above) if crankback is allowed for this inter- area TE LSP (see [CRANBACK]). If crankback is not allowed for that ## s/CRANBACK/CRANKBACK/ inter-area TE LSP or if ABR1 has been configured not to perform crankback, then ABR1 MUST stop any path computation for the TE LSP and MUST forward a PathErr up to the head-end LSR (R0) without trying to select another egress LSR. ## But R0 can possibly do crankback even if ABR1 doesn't. 4.1.2. Case 2: T1 is a stitched or nested TE LSP ## Again, I would like you to start at the ingress. When the path message reaches ABR1, ABR1 first determines the egress LSR from its area 0 along the LSP path (say ABRÆ1), either directly from the ERO or by using some constraint-aware auto-discovery mechanism. ABR1 will check if it has a FA-LSP or LSP segment to ABRÆ1 matching the constraints carried in the inter-area TE LSP Path message. If not, ABR1 will compute the path for a FA-LSP or LSP segment from ABR1 to ABRÆ1 satisfying the constraint and will set it up accordingly. Note that the FA-LSP or LSP segment could have also been pre-configured. Once the ABR has selected the FA-LSP/LSP segment for the inter-area LSP, using the signaling procedures described in [LSP-HIER], ABR1 sends the Path message for inter-area TE LSP to ABRÆ1. Note that irrespective of whether ABR1 does nesting or stitching, the Path message for the inter-area TE LSP is always forwarded to ABRÆ1. ABRÆ1 then repeats the exact same procedures and the Path message for the inter-area TE LSP will reach the destination R1. If ABRÆ1 cannot find a path obeying the set of constraints for the inter-area TE LSP, then ABRÆ1 MUST send a PathErr message to ABR1. Then ABR1 can in turn either select another FA-LSP/LSP segment to ABRÆ1 if such an LSP exists or select another egress boundary LSR (ABRÆ2 in the example above) if crankback is allowed for this inter-area TE LSP (see [CRANBACK]). If crankback is ## s/CRANBACK/CRANKBACK/ not allowed for that inter-area TE LSP or if ABR1 has been configured not to perform crankback, then ABR1 MUST forward a PathErr up to the Vasseur, Ayyangar and Zhang 10 draft-ietf-ccamp-inter-domain-pd-path-comp-00.txt April 2005 inter-area head-end LSR (R0) without trying to select another egress LSR. 4.2. Example with an inter-AS TE LSP The procedures for establishing an inter-AS TE LSP are very similar to those of an inter-area TE LSP described above. The main difference is related to the presence of inter-ASBRs link(s). The links interconnecting ASBRs are usually not TE enabled and no IGP is running at the AS boundaries. An implementation supporting inter-AS MPLS TE MUST obviously allow the set up of inter-AS TE LSP over the ## "MUST obviously" is not in RFC2119. region interconnecting multiple ASBRs. In other words, an ASBR compliant with this document MUST support the set up of TE LSP over ASBR to ASBR links, performing all the usual operations related to MPLS Traffic Engineering (call admission control, à) as defined in [RSVP- TE]. In term of computation of an inter-AS TE LSP path, an interesting ## s/term/terms/ optimization consists of allowing the ASBRs to flood the TE information related to the inter-ASBR link(s) although no IGP TE is enabled over those links (and so there is no IGP adjacency over the inter-ASBR links). This of course implies for the inter-ASBR links to be TE- enabled although no IGP is running on those links. This allows a head- end LSR to make a more appropriate route selection up to the first ASBR in the next hop AS and will significantly reduce the number of signaling steps in route computation. This also allows the entry ASBR in an AS to make a more appropriate route selection up to the entry ASBR in the next hop AS taking into account constraints associated with the ASBR-ASBR links. Moreover, this reduces the risk of call set up failure due to inter-ASBR links not satisfying the inter-AS TE LSP set of constraints. Note that the TE information is only related to the inter-ASBR links: the TE LSA/LSP flooded by the ASBR includes not only the TE-enabled links contained in the AS but also the inter-ASBR links. ## Can you explain why the TE information pertaining to the inter-AS ## links *needs* to be flooded within the ASs? It is surely enough that ## the ASBRs have access to the TE information about their own TE links. ## After all, you have defined that the ASBRs in the *next* AS can do ## hop resolution and crankback. Why should the ASBRs in *this* AS also ## not perform that operation if necessary? ## You are reducing the chance of call setup failure at the expense of ## increasing the scope of the TE information flooded. But we know ## how that works! Note that no summarized TE information is leaked between ASes which is compliant with the requirements listed in [INTER-AREA-TE-REQS] and [INTER-AS-TE-REQS]. Example: <---BGP---> <---BGP--> CE1---R0---X1-ASBR1-----ASBR4ù-R3---ASBR7-ù--ASBR9---R6 |\ \ | / | / | / | | | | \ ASBR2---/ ASBR5 | -- | | | | \ | | |/ | | | R1-R2ù--ASBR3ù----ASBR6ù-R4---ASBR8ù---ASBR10---R7---CE2 For instance, in the diagram depicted above, when ASBR1 floods its IGP TE LSA (opaque LSA for OSPF)/LSP (TLV 22 for IS-IS) in its routing Vasseur, Ayyangar and Zhang 11 draft-ietf-ccamp-inter-domain-pd-path-comp-00.txt April 2005 domain, it reflects the reservation states and TE properties of the following links: X1-ASBR1, ASBR1-ASBR2 and ASBR1-ASBR4. Thanks to such an optimization, the inter-ASBRs TE link information corresponding to the links originated by the ASBR is made available in the TED of other LSRs in the same area/AS that the ASBR belongs to. Consequently, the CSPF computation for an inter-AS TE LSP path can also ## CSPF again take into account the inter-ASBR link(s). This will improve the chance of successful path computation up to the next AS in case of a bottleneck on some inter-ASBR links and it potentially reduces one level of crankback. Note that no topology information is flooded and these links are not used in IGP SPF computations. Only the TE information for the links originated by the ASBR is advertised. 4.2.1. Case 1: T1 is a contiguous TE LSP The inter-AS TE path may be configured on the head-end LSR as a set of strict hops, loose hops or a combination of both. - Example 1 (set of strict hops end to end): R0-X1-ASBR1-ASBR4-ASBR5- R3-ASBR7-ASBR9-R6 - Example 2 (set of loose hops): R0-ASBR4(loose)-ASBR9(loose)-R6(loose) - Example 3 (mix of strict and loose hops): R0-R2-ASBR3-ASBR2-ASBR1- ASBR4(loose)-ASBR10(loose)-ASBR9-R6 When a next hop is a loose hop, a dynamic path calculation (also called ERO expansion) is required taking into account the topology and TE information of its own AS and the set of TE LSP constraints. In the example 1 above, the inter-AS TE LSP path is statically configured as a set of strict hops; thus, in this case, no dynamic computation is required. Conversely, in the example 2, a per-AS path computation is performed, respectively on R0 for AS1, ASBR4 for AS2 and ASBR9 for AS3. Note that when an LSR has to perform an ERO expansion, the next hop must either belong to the same AS, or must be the ASBR directly connected to the next hops AS. In this later case, the ASBR reachability MUST be announced in the IGP TE LSA/LSP originated by its neighboring ASBR. Indeed, in the example 2 above, the TE LSP path is defined as: R0-ASBR4(loose)-ASBR9(loose)-R6(loose). This implies that R0 must compute the path from R0 to ASBR4, hence the need for R0 to get the TE reservation state related to the ASBR1-ASBR4 link (flooded in AS1 by ASBR1). In addition, ASBR1 MUST also announce the IP address of ASBR4 specified in the T1 path configuration. If an auto-discovery mechanism is available, every LSR receiving an RSVP Path message, will have to determine automatically the next hop ASBR, based on the IGP/BGP reachability of the TE LSP destination. With such a scheme, the head-end LSR and every downstream ASBR loose hop (except the last loose hop that computes the path to the final destination) automatically computes the path up to the next ASBR, the next loose hop based on the IGP/BGP reachability of the TE LSP destination. If a particular destination is reachable via multiple Vasseur, Ayyangar and Zhang 12 draft-ietf-ccamp-inter-domain-pd-path-comp-00.txt April 2005 loose hops (ASBRs), local heuristics may be implemented by the head-end LSR/ASBRs to select the next hop an ASBR among a list of possible choices (closest exit point, metric advertised for the IP destination (ex: OSPF LSA External - Type 2), local policy,...). Once the next ASBR has been determined, an ERO expansion is performed as in the previous case. Once it has computed the path up to the next ASBR, ASBR1 sends the Path message for the inter-area TE LSP to ASBR4 (supposing that ASBR4 is the selected next hop ASBR). ASBR4 then repeats the exact same procedures and the Path message for the inter-AS TE LSP will reach the destination R1. If ASBR4 cannot find a path obeying the set of constraints for the inter-AS TE LSP, then ASBR4 MUST send a PathErr message to ASBR1. Then ASBR1 can in turn either select another ASBR (ASBR5 in the example above) if crankback is allowed for this inter-AS TE LSP (see [CRANBACK]). If crankback is not allowed for that inter-AS TE LSP or if ## s/CRANBACK/CRANKBACK/ ASBR1 has been configured not to perform crankback, then ABR1 MUST stop the path computation and MUST forward a PathErr up to the head-end LSR (R0) without trying to select another egress LSR. In this case, the head-end LSR can in turn select another sequence of loose hops, if configured. Alternatively, the head-end LSR may decide to retry the same path; this can be useful in case of set up failure due an outdated IGP TE database in some downstream AS. An alternative could also be for the head-end LSR to retry to same sequence of loose hops after having relaxed some constraint(s). 4.2.2. Case 2: T1 is a stitched or nested TE LSP The signaling procedures are very similar to the inter-area LSP setup case described earlier. In this case, the FA-LSPs or LSP segments will only be originated by the ASBRs at the entry to the AS. ## This is a really important point that you should bring out a bit! ## An FA cannot exist out of the IGP instance that contains its ## component TE links. ## What about non-FAs? Could I operate a stitched segment for just the ## link between ASBRs? I think so. Indeed, I might want to. ## Could I run a hierarchical LSP for just the link between ASBRs? Yes ## although I am not convinced it adds value, but maybe there is some ## administrative benefit when crossing a trust boundary (for example, ## all I have to do is count the packets with one label). 5. Path optimality/diversity Since the inter-domain path is computed on a per domain (area, AS) basis, one cannot guarantee that the shortest inter-domain path can be ## Who cares about "shortest"? We want "optimal given the constraints." found. ## Well, you have explicitly allowed the selection of domains to be ## made in the initial ERO. (Note you never really said how this ## selection might be made.) Presumably, this selection might be ## used to achieve the optimal. Moreover, computing two diverse paths might not be possible in some topologies (due to the well-known ôtrappingö problem). ## "Might not" is an understatement! ## You should note two things. ## The e2e protection technique offers a way to help achieve this ## however there is a direct conflict with the trust policies at ## domain boundaries that may mean that it is impossible to make ## any guarantees (or even to make an attempt) without new techniques ## probably related to crankback, but maybe requiring perpendicular ## communication between boundary LSRs. ## Domain-diverse paths provide an intersting solution and also ## offer interesting protection characteristics. As already pointed out, the required path computation method can be selected by the Operator on a per LSP basis. ## And so... ? ## I think you are saying that "If this technique does not give you ## the function you need, look elsewhere." This is a good thing to ## say. ## In fact, I would like you to add a new section titled ## "Applicability" to cover what you can and cannot do with this ## technique. 6. MPLS Traffic Engineering Fast Reroute for inter-domain TE LSPs ## The following section is valuable in the context of the popularity ## of RFC 4090, but you cannot produce this I-D in CCAMP without also ## discussing the use of Segment Protection to achieve the same ## function in the data plane. The signaling aspects of Fast Reroute and related constraints for each TE LSP types in the case of inter-domain TE LSP has been covered in ## s/types/type/ ## s/has/have/ [INTER-DOMAIN-SIG] and will not be repeated in this document. ## Does that mean that to operate FRR with the techniques described ## here you must apply something from [INTER-DOMAIN-SIG]? If so, you ## need to make that I-D noramtive. Vasseur, Ayyangar and Zhang 13 draft-ietf-ccamp-inter-domain-pd-path-comp-00.txt April 2005 There are multiple failure scenarios to consider in the case of Fast Reroute for inter-domain TE LSPs. 6.1. Failure of an internal network element The case of a failure of a network element within an area/AS such as a link, SRLG or a node does not differ from Fast Reroute for intra-domain TE LSP. ## You need to make it clear that you do not consider an ABR or ASBR to ## be within the area or AS. Most people will find this shocking. ## You need to be careful with "SRLG" because some SRLGs span domains ## although no-one is quite sure how that works (c: 6.2. Failure of an inter-ASBR links (inter-AS TE) ## s/links/link/ In order to protect inter-domain TE LSPs from the failure of an inter- ASBR link, this requires the computation of a backup tunnel path that crosses an non IGP TE-enabled region (between two ASes). ## s/an non/a non/ If the inter- ASBR TE related information is flooded in the IGPs, each ASBR is capable of computing the path according to the backup tunnel constraints. Otherwise, the backup tunnel path MUST be statically configured. ## If the inter-ASBR TE link is flooded in the IGPs, doesn't that ## make it IGP TE-enabled? 6.3. Failure of an ABR or an ASBR node The constraints to be taken into account during the backup tunnel path computation significantly differs upon the TE LSP type, network element ## s/differs/differ depending/ to protect (entry/exit boundary node) and the Fast Reroute method in use (facility backup versus one-to-one). Those constraints have been explored in detail in [INTER-DOMAIN-SIG] but since the backup tunnel is itself an inter-domain TE LSP, its path computation can be performed according to the two path computation methods described in this document. 7. Reoptimization of an inter-domain TE LSP The ability to reoptimize an existing inter-domain TE LSP path is of course a requirement. The reoptimization process significantly differs based upon the nature of the TE LSP and the mechanism in use for the TE LSP path computation. The following mechanisms can be used for re-optimization, which are ## Please decide "reoptimize" or "re-optimize" dependent on the nature of the inter-domain TE LSP. 7.1. Contiguous TE LSPs ## Need to generalize this section for areas, etc. After an inter-AS TE LSP has been set up, a more optimal route might appear in the various traversed ASes. Then in this case, it is desirable to get the ability to reroute an inter-AS TE LSP in a non- disruptive fashion (making use of the so called Make Before Break procedure) to follow this more optimal path. This is a known as a TE LSP reoptimization procedure. ## Is there any requirement to redescribe the procedures of ## [LOOSE-PATH-REOPT]? Why not simply state that... ## [LOOSE-PATH-REOPT] describes a mechanism to control discovery ## or more optimal paths, and to signal new paths using make before ## break. #### BEGIN DELETE # # [LOOSE-REOPT] proposes a mechanisms allowing: ## s/[LOOSE-REOPT]/[LOOSE-PATH-REOPT]/ -- change throughout the doc ## s/proposes/defines/ Vasseur, Ayyangar and Zhang 14 draft-ietf-ccamp-inter-domain-pd-path-comp-00.txt April 2005 - The head-end LSR to trigger on every LSR whose next hop is a loose hop the re evaluation of the current path in order to ## s/re evaluation/re-evaluation/ detect a potentially more optimal path. This is done via explicit signaling request: the head-end LSR sets the ôERO Expansion requestö bit of the SESSION-ATTRIBUTE object carried in the RSVP Path message. - An LSR whose next hop is a loose-hop to signal to the head- end LSR that a better path exists. This is performed by sending an RSVP Path Error Notify message (ERROR-CODE = 25), sub-code 6 (Better path exists). This indication may be sent either: - In response to a query sent by the head-end LSR, - Spontaneously by any LSR having detected a more optimal path Such a mechanism allows for the reoptimization of a TE LSP if and only if a better path is some downstream area/AS is detected. The reoptimization event can either be timer or event-driven based (a link UP event for instance). Note that the reoptimization MUST always be performed in a non- disruptive fashion. Once the head-end LSR is informed of the existence of a more optimal path either in its head-end area/AS or in another AS, the inter-AS TE Path computation is triggered using the same set of mechanisms as when the TE LSP is first set up. Then the inter-AS TE LSP is set up following the more optimal path, making use of the make before break procedure. In case of a contiguous LSP, the reoptimization process is strictly controlled by the head-end LSR which triggers the make-before- break procedure, regardless of the location where the more optimal path is. Note that in the case of loose hop reoptimization, the TE LSP may follow a preferable path within one or more domain(s) whereas in the case of PCE-based path computation techniques, the reoptimization process may lead to following a completely different inter-domain path (including a different set of ABRs/ASBRs) since end-to-end shortest path is computed. # # #### END DELETE 7.2. Stitched or nested (non-contiguous) TE LSPs ## This section contains quite a lot of repetition. In the case of a stitched or nested inter-domain TE LSP, the re- optimization process is treated as a local matter to any Area/AS. The main reason is that the inter-domain TE LSP is a different LSP (and therefore different RSVP session) from the intra-domain LSP segment or ## Your causality is broken. Being a different LSP does not imply ## being a different session. However, the key point *is* that this ## is a different session (with different ingress and egress). FA-LSP in an area or an AS. Therefore, reoptimization in an area/AS is Vasseur, Ayyangar and Zhang 15 draft-ietf-ccamp-inter-domain-pd-path-comp-00.txt April 2005 done by locally reoptimizing the intra-domain FA LSP or LSP segment. Since the inter-domain TE LSPs are transported using LSP segments or FA-LSP across each domain, optimality of the inter-domain TE LSP in an area/AS is dependent on the optimality of the corresponding LSP segments or FA-LSPs. If, after an inter-domain LSP is setup, a more optimal path is available within an area/AS, the corresponding LSP segment(s) or FA-LSP will be re-optimized using "make-before-break" techniques discussed in [RSVP-TE]. Reoptimization of the FA LSP or LSP segment automatically reoptimizes the inter-domain TE LSPs that the LSP segment transports. Reoptimization parameters like frequency of reoptimization, criteria for reoptimization like metric or bandwidth availability; etc can vary from one area/AS to another and can be configured as required, per intra-area/AS TE LSP segment or FA-LSP if it is preconfigured or based on some global policy within the area/AS. Hence, in this scheme, since each area/AS takes care of reoptimizing its own LSP segments or FA-LSPs, and therefore the corresponding inter- domain TE LSPs, the make-before-break can happen locally and is not triggered by the head-end LSR for the inter-domain LSP. So, no additional RSVP signaling is required for LSP re-optimization and reoptimization is transparent to the HE LSR of the inter-domain TE LSP. If, however, an operator desires to manually trigger reoptimization at the head-end LSR for the inter-domain TE LSP, then this solution does not prevent that. A manual trigger for reoptimization at the head-end LSR SHOULD force a reoptimization thereby signaling a "new" path for the same LSP (along the optimal path) making use of the make-before- break procedure. In response to this new setup request, the boundary LSR may either initiate new LSP segment setup, in case the inter-domain TE LSP is being stitched to the intra-area/AS LSP segment or it may select an existing or new FA-LSP in case of nesting. When the LSP setup along the current optimal path is complete, the head end should 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 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 frequent occurrence. Note that stitching or nesting rely on local optimization: the reoptimization process allows to locally reoptimize each TE LSP segment or FA-LSP: hence, the reoptimization is not global and consequently the end to end path may no longer to optimal, should it be optimal when set up. Procedures described in [LOOSE-REOPT] MUST be used if the operator does ## Oh, no. You cannot MUST the procedures of an Information document. not desire local re-optimization of certain inter-domain LSPs. In this case, any re-optimization event within the domain MUST be reported to the head-end node. This SHOULD be a configurable policy. ## You need to comment that local repotimization (either of hierarchical ## LSPs and stiched segments, or reported to the ingress) does not handle ## the case where a better path would use different domains. Please ## think about that case. 8. Security Considerations ## This section seems very lightweight given the importance of ## inter-AS trust boundaries. Vasseur, Ayyangar and Zhang 16 draft-ietf-ccamp-inter-domain-pd-path-comp-00.txt April 2005 When signaling an inter-AS TE, an Operator may make use of the already defined security features related to RSVP (authentication). This may require some coordination between Service Providers to share the keys (see RFC 2747 and RFC 3097). ## Should these be normative references? 9. Intellectual Property Considerations The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org.. IPR Disclosure Acknowledgement By submitting this Internet-Draft, I certify that any applicable patent 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. ## You don't need to say this twice. It is already at the head of the ## I-D 10. Acknowledgments We would like to acknowledge input and helpful comments from Adrian Farrel. ## Has no-one else reviewed this I-D? That is a problem! 11 References 10.1. Normative References [RFC] Bradner, S., "Key words for use in RFCs to indicate requirements ## s/[RFC]/[RFC2119]/ levels", RFC 2119, March 1997. [RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC 3667, February 2004. ## Out of date reference Vasseur, Ayyangar and Zhang 17 draft-ietf-ccamp-inter-domain-pd-path-comp-00.txt April 2005 [RFC3668] Bradner, S., Ed., "Intellectual Property Rights in IETF Technology", BCP 79, RFC 3668, February 2004. ## Out of date reference [RSVP] Braden, et al, " Resource ReSerVation Protocol (RSVP) û Version 1, Functional Specificationö, RFC 2205, September 1997. [RSVP-TE] Awduche, et al, "Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. [REFRESH-REDUCTION] Berger et al, ôRSVP Refresh Overhead Reduction Extensionsö, RFC2961, April 2001. ## Not sure why this is listed as normative, or even at all. [FAST-REROUTE] Ping Pan, et al, "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", draft-ietf-mpls-rsvp-lsp-fastreroute-03.txt, December 2003. ## Now an RFC ## Note, this RFC is not referenced. It probably should be. [OSPF-TE] Katz, D., Yeung, D., Kompella, K., "Traffic Engineering Extensions to OSPF Version 2", RFC 3630, September 2003. [ISIS-TE] Li, T., Smit, H., "IS-IS extensions for Traffic Engineering", RFC 3784, June 2004. 10.2. Informative references [INT-AREA-REQ] Le Roux, J.L., Vasseur, J.P., Boyle, J., "Requirements for inter-area MPLS Traffic Engineering", draft-ietf-tewg-interarea- mpls-te-req-03.txt, work in progress. [INT-AS-REQ] Zhang, R., Vasseur, J.P., "MPLS Inter-AS Traffic Engineering Requirements", draft-ietf-tewg-interas-mpls-te-req-09.txt, work in progress. [INT-DOMAIN-FRWK] Farrel, A., Vasseur, J.P., Ayyangar, A., "A Framework for Inter-Domain MPLS Traffic Engineering", draft-ietf-ccamp-inter- domain-framework-00.txt, work in progress. [FACILITY-BACKUP] Le Roux, J.L., Vasseur, J.P. et al. "Framework for PCE based MPLS Facility Backup Path Computation", draft-leroux-pce- backup-comp-frwk-00.txt, work in progress ## A very interesting I-D, no doubt, but you have not referenced it, so ## why is it listed? [INTER-DOMAIN-SIG] Ayyangar, A., Vasseur, JP. ôInter-domain MPLS Traffic Engineering û RSVP extensionsö, draft-ietf-ccamp-inter-domain- rsvp-te, work in progress. [LSP-STITCHING] Ayyangar, A., Vasseur, JP. ôLabel Switched Path Stitching with Generalized MPLS Traffic Engineeringö, draft-ietf-ccamp- lsp-stitching-00, Work under progress. Vasseur, Ayyangar and Zhang 18 draft-ietf-ccamp-inter-domain-pd-path-comp-00.txt April 2005 [LSP-ATTRIBUTE] Farrel A. et al, "Encoding of Attributes for Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) Establishment Using RSVP-TE", draft-ietf-mpls-rsvpte-attributes-04,(work in progress). ## One of my favorite I-Ds. But why have you listed it without ## referencing it? ## ## In fact, all of the remaining I-Ds are very worthwhile, but except ## for [LSP-HIER] and [LOOSE-PATH-REOPT] you haven't referenced them. ## ## On the other hand, you do reference [RFC2702] and [CRANKBACK] so ## you should list them here. [GMPLS-OVERLAY] G. Swallow et al, "GMPLS RSVP Support for the Overlay Model", (work in progress). [EXCLUDE-ROUTE] Lee et all, Exclude Routes - Extension to RSVP-TE, draft-ietf-ccamp-rsvp-te-exclude-route-00.txt, work in progress. [LSPPING] Kompella, K., Pan, P., Sheth, N., Cooper, D.,Swallow, G., Wadhwa, S., Bonica, R., " Detecting Data Plane Liveliness in MPLS", Internet Draft <draft-ietf-mpls-lsp-ping-02.txt>, October 2002. (Work in Progress) [MPLS-TTL], Agarwal, et al, "Time to Live (TTL) Processing in MPLS Networks", RFC 3443 Updates RFC 3032) ", January 2003 [LOOSE-PATH-REOPT] Vasseur, Ikejiri and Zhang ôReoptimization of an explicit loosely routed MPLS TE pathsö, draft-ietf-ccamp-loose-path- reopt-01.txt, July 2004, Work in Progress. [NODE-ID] Vasseur, Ali and Sivabalan, ôDefinition of an RRO node-id subobjectö, draft-ietf-mpls-nodeid-subobject-05.txt, work in progress. [LSP-HIER] Kompella K., Rekhter Y., "LSP Hierarchy with Generalized MPLS TE", draft-ietf-mpls-lsp-hierarchy-08.txt, March 2002. [MPLS-TTL], Agarwal, et al, "Time to Live (TTL) Processing in MPLS Networks", RFC 3443 (Updates RFC 3032) ", January 2003.
- Early chair review of draft-ietf-ccamp-inter-doma… Adrian Farrel
- Re: Early chair review of draft-ietf-ccamp-inter-… Arthi Ayyangar
- Re: Early chair review of draft-ietf-ccamp-inter-… JP Vasseur
- Issue for CCAMP meeting [Was: Early chair review … Adrian Farrel