The MPLS WG Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] TR : I-D ACTION:draft-ietf-tewg-interarea-mpls-te-req-00.txt
Hi Dimitri, At 07:52 PM 3/31/2004 +0200, Dimitri.Papadimitriou@alcatel.be wrote: >hi jp, > >see in-line: > >>Thanks for your useful comments here. See below, >>At 02:18 PM 3/30/2004 +0200, Dimitri.Papadimitriou@alcatel.be wrote: >> >>>hi jl, here below several comments on this updated version of the document: >>> >>>1) section 5.3.1 mentions: >>> >>>"The solution MUST entirely preserve the concept of IGP hierarchy. In >>> other words, flooding of TE link information across areas MUST be >>> precluded." >>> >>>section 5.3.2 mentions: >>> >>>"The solution MUST also not increase IGP load which could compromise >>> IGP scalability. In particular, a solution satisfying those >>> requirements MUST not require for the IGP to carry some unreasonable >>> amount of extra information and MUST not unreasonably increase the >>> IGP flooding frequency." >>> >>>but section 7.12 tells: >>> >>>"The discovery mechanism SHOULD >>> be applicable across multiple IGP areas, and SHOULD not impact the >>> IGP scalability, provided that IGP extensions are used for such a >>> discovery mechanism." >>> >>>-> would it be possible to align these requirements, i get the >>>impression (please confirm) that you preclude TE link information but >>>you would allow for node information (auto-mesh) ? note also that the >>>section 7.12 doesn't tell us a lot about the expected distribution of the mesh >> >>The solution MUST preclude to flood TE-related link information and MUST >>not compromise the IGP scalability in any circumstances. That being said, >>IGP based mechanisms can be used for the discovery which will respect the >>requirement mentioned above, > >i understand to what you're referring, but please make it clear >imho it would help if in section 7.12 the exact meaning of the >following "*some* discovery mechanisms" was detailed so that the >reader can more accurately assess the scope of the above ok, will do >>>2) section 7.3 >>> >>>" In the context of this requirement document, an optimal path is >>> defined as the shortest path across multiple areas taking into >>> account either the IGP or TE metric. " >>> >>>are you referring here to >>><http://www.ietf.org/internet-drafts/draft-ietf-tewg-te-metric-igp-02.txt> >>> >>>would you clarify ? >> >>Sure, we will add some text. The reason for this clarification is that >>there are a multitude of definitions for an optimal path: paths that >>minimize the max link utilization, call set up failure, ... here we just >>refer to the ability to compute a shortest path (using either the IGP or >>TE metric). > >ok > >>>3) section 7.3 >>> >>>it is not clear for me what is behind the last part of the following >>>sentence >>> >>>"So a solution should support both mechanisms, and SHOULD allow >>> the operator to select by configuration, and on a per-LSP basis, the >>> required level of optimality. " >>> >>>what is meant by "level of optimality" ? is it simply "optimal - >>>sub-optimal" or do you have something else in mind ? >> >>We will clarify. The idea is that the ability to compute an end to end >>shortest path may not be required for all inter-area TE LSPs. Hence the >>solution should allow the operator to select the appropriate path >>computation method. > >ok, would be interesting to see whether operators would like to have >selection based on the computational method (allow for intermediate >computation or any other option suitable in this context) or based on the >optimality level (then the solution itself selects the appropriate >computational method) or simply both > >>>4) section 7.4 >>> >>>"Another example is the requirement to set up multiple TE LSPs between >>> a pair of LSRs residing in different IGP areas in case a single TE >>> LSP satisfying the set of requirements could not be found. " >>> >>>why in such a case diversity would be desirable ? >> >>for either path protection or load balancing while minimizing the impact >>in case of failure. >> >>>got the impression that if a single path would have been feasible it >>>would have been selected in this case - isn't it ? >> >>That being said, we need to rephrase, I agree with you that this >>paragraph is not clear. It should read: >>"Another example is the requirement to set up multiple TE LSPs between a >>pair of LSRs residing in different IGP areas. For instance, this would >>occur if TE LSP satisfying for instance the bandwidth requirement could >>be found, hence, requiring to set up multiple TE LSPs" > >the former point(s) seem clearer, is it "could be found" or "could not be >found" ? oups ... typo, yes "could not be found" >>>5) section 7.7 >>> >>>"This may reduce the recovery delay, but with the risk of >>> multiple crankbacks, and sub-optimality. " >>> >>>i agree, but this is valid iff the head-end has initially computed an >>>end-to-end optimal path, >> >>more exactly this applies to contiguous LSP. For sub-optimality this >>applies to any kind of LSP. > >well i think that a contiguous LSP can still be sub-optimal hence >i would suggest to not implicitly attach the crankback functionality >to the signaling method, but to make clear what are the potential >issues in terms of optimality as said "iff the path was initially >computed as an end-to-end optimal" not sure to see your point here ? >>>also unclear if you refer also here to the provisioning delay ? >>> >>>editorially speaking it is also a bit unclear why you've splitted >>>section 7.7 and section 7.8 both refers to inter-area lsp recovery > >i don't know if this could be taken into account, this would simplify >reading and subsequent utilisation of the document ok >>>6) section 7.11 >>> >>>would it be possible to mention what's expected (or not expected) in >>>terms also of hard preemption ? >> >>ok > >just a hint here, is my understanding correct that the following sentence >"The lower priority LSP is not torn down and can continue to forward >traffic on a best-effort basis." infers that you would have to priority >high/low only so i'd would instead be more generic here in >terms of priorities the latter >>>7) section 8.2 >>> >>>what's meant by stability ? ie stability of what ? (for instance, as i >>>read the document, but please correct me, stability and re-optimization >>>are imho two features that are going in somehow opposite directions so a >>>trade-off has to be found here) >> >>We will clarify. > >ok > >>thanks for your comments ! > >hope to see the next version soon, would also be interesting to see other >people commenting here sure, thanks for your comments. Note that this draft is already the collection of many feed-backs from several SPs. thanks. JP. >thanks, >- dimitri. > >>JP. >> >>>thanks in advance, >>>- dimitri. >>> >>>LE ROUX Jean-Louis FTRD/DAC/LAN wrote: >>> >>>>Hi all, >>>>Thanks in advance for your comments on this new revision of inter-area >>>>TE requirements. >>>>Regards, >>>>JL >>>> >>>>>A New Internet-Draft is available from the on-line Internet-Drafts >>>>>directories. This draft is a work item of the Internet Traffic >>>>>Engineering Working Group of the IETF. >>>>> >>>>> Title : Requirements for Inter-area MPLS Traffic >>>> >>>>Engineering >>>> >>>>> Author(s) : J. Le Roux, et al. >>>>> Filename : draft-ietf-tewg-interarea-mpls-te-req-00.txt >>>>> Pages : 20 >>>>> Date : 2004-3-26 >>>>> >>>>>This document lists a detailed set of functional requirements for the >>>>>support of inter-area MPLS Traffic Engineering (inter-area MPLS TE) >>>>>which could serve as a guideline to develop the required set of >>>>>protocol extensions. >>>>> >>>>>A URL for this Internet-Draft is: >>>>>http://www.ietf.org/internet-drafts/draft-ietf-tewg-interarea-mpls-te-r >>>> >>>>eq-00.txt >>>> >>>>>To remove yourself from the IETF Announcement list, send a message to >>>>>ietf-announce-request with the word unsubscribe in the body of the >>>>>message. >>>>> >>>>>Internet-Drafts are also available by anonymous FTP. Login with the >>>>>username "anonymous" and a password of your e-mail address. After >>>>>logging in, type "cd internet-drafts" and then >>>>> "get draft-ietf-tewg-interarea-mpls-te-req-00.txt". >>>>> >>>>>A list of Internet-Drafts directories can be found in >>>>>http://www.ietf.org/shadow.html or >>>>>ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>> >>> >>>-- >>>Papadimitriou Dimitri >>>E-mail : dimitri.papadimitriou@alcatel.be >>>E-mail : dpapadimitriou@psg.com >>>Webpage: http://psg.com/~dpapadimitriou/ >>>Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium >>>Phone : +32 3 240-8491 >>> > >-- >Papadimitriou Dimitri >E-mail : dimitri.papadimitriou@alcatel.be >E-mail : dpapadimitriou@psg.com >Webpage: http://psg.com/~dpapadimitriou/ >Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium >Phone : +32 3 240-8491 > > |
|