The MPLS WG Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] RE : TR : I-D ACTION:draft-ietf-tewg-interarea-mpls-te-req-00.txt
hi jean-louis thanks for the clarifications; see in-line for some hints LE ROUX Jean-Louis FTRD/DAC/LAN wrote: > Hi Dimitri, > > Thanks a lot for these comments. See additional comments on top of JP > comments. > > Cheers > > JL > > >> -----Message d'origine----- De : Jean Philippe Vasseur >> [mailto:jvasseur@cisco.com] Envoyé : mardi 30 mars 2004 14:36 À : >> Dimitri.Papadimitriou@alcatel.be Cc : LE ROUX Jean-Louis >> FTRD/DAC/LAN; ccamp@ops.ietf.org; mpls@UU.NET Objet : Re: TR : I-D >> ACTION:draft-ietf-tewg-interarea-mpls-te-req-00.txt >> >> >> Hi Dimitri, >> >> 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, > > Basically the solution must preserve IGP hierarchy, and thus must > preclude leaking of any TOPOLOGY related information accross areas, > including TE link information such as carried in ISIS Extended IS > reacheability TLV, or OSPF TE LSA Link TLV. Note that this also > precludes leaking of any summarized/aggregated TE information, such > that the advertisement of maximum unreserved bandwdith between an ABR > and any end-point LSR. We will clarify that in next revision. this would refine the above requirement (such TE link information would be precluded in any of its form) > In return we definitely not preclude leaking of NON TOPOLOGY related > information such as TE node capabilities, provided that IGP > scalability is not impacted. more than probably, it is not within this kind of document to provide a kind of classification of such information but the latter would help in detailing the "discovery" concepts (see also section 7.12) in terms of functionality that would be required here: identity, capability & associated capability >>> 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-metri >> >> c-igp-02.t >> >>> xt> >>> >>> 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). >> >> >> >>> 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. > > > I see your point here. Basically there are two possible approaches > for LSP configuation -Option 1: Configure only the desired level of > optimality: Optimal, sub-optimal, then the head-end choose the > corresponding path computation approach. -Option 2: Configure > directly the desired path computation method: e.g. ERO expansion or > PCE computation > > Option 1 is IMHO too generic, and a Service Provider wants to have > direct control on the selection of the path computation method. > > We will clarify that in next revision ok >>> 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" >> >> >>> 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. >> >> >>> also unclear if you refer also here to the provisioning delay ? > > > Actually this section is not dedicated to crankback routing as a path > computation method, it only addresses possible use of crankback in > case of network failure. Thus we refer here only to the recovery > delay. We may add a section dedicated to crankback routing in the > next revision i would agree to have a requirement document that includes a dedicated section on crankback functionality, hope the next release will clarify >>> 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 >>> > > > Yes you are right, both sections refer to lsp recovery Basically > section 7.7 deals with LSP rerouting and section 7.8 is dedicated to > Fast Reroute protection We will update as follows 7.7 LSP recovery > 7.7.1 LSP rerouting 7.7.2 Fast Reroute ok >>> 6) section 7.11 >>> >>> would it be possible to mention what's expected (or not expected) >>> in terms also of hard preemption ? >> >> ok > > >> >>> 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. >> >> thanks for your comments ! >> >> 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-interar > > ea-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
|
|