[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE : TR : I-D ACTION:draft-ietf-tewg-interarea-mpls-te-req-00.txt
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.
In return we definitely not preclude leaking of NON TOPOLOGY related information such as TE node capabilities, provided that IGP scalability is not impacted.
>
> >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
>
> >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
> >
> >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
> >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
>
>