[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE : Merged intera-area reqts ID
Hi Dimitri,
Thanks a lot for these comments
Please find answers inline
> -----Message d'origine-----
> De : Dimitri.Papadimitriou@alcatel.be
> [mailto:Dimitri.Papadimitriou@alcatel.be]
> Envoyé : mercredi 11 février 2004 01:41
> À : LE ROUX Jean-Louis FTRD/DAC/LAN
> Cc : te-wg@ops.ietf.org; ejk@tech.org; bwijnen@lucent.com;
> dpapadimitriou@psg.com
> Objet : Re: Merged intera-area reqts ID
>
>
> hi jean-louis,
>
> some comments
>
> 1) am i right by saying that the introduction itself provides
> the first requirement that is "The solution for multi IGP
> area must or should satisfy the same set of functionalities
> than those defined for single IGP area" ?
Yes, it is clearly mentionned in intro, that the global requirement is to achieve the same set of objectives across areas
>
> 2) am i right by saying that bullets this introduction
> includes are these high level functionalities ?
Definitely right
>
> would it be possible to make 1) and 2) appearing as
> requirement in such a case
IMHO this is already done, but perhaps not clearly. I will update the intro so that it appears more clearly.
>
> 3) would it be possible to clarify the following sentence:
> "Another increasing popular deployment is driven by the need
> to carry pseudo-wire connection between gateways residing in
> different IGP areas." what are these gateways referring to
> ASBR ? or something else
Basically these pseudo-wire connections are PE routers providing L2VPN services
>
> 4) would it be possible to know whether the following
> "As traffic sensitive application are getting deployed, one
> of the key requirements is to provide fast recovery (on the
> order of tens of
> msecs) mechanisms in case of network element failure
> (link/SRLG/node), which cannot be achieved with current
> IGPs." the "current IGPs" means the routing protocol on its
> own then because it does not seem you consider the use of BFD
> for instance - right ? also it may be of interest to detail
> what you mean by "fast recovery" ie the recovery of (?)
>
Actually "Current IGP" means "by mean of IGP rerouting"
BFD is just a detection mecanisms and not a recovery mechanism. BFD does not allow to provide fast recovery by its own.
I will update this section to clarify IGP rerouting and fast recovery.
> 5) what's meant by "transit area" in the following sentence:
> "The solution SHOULD also allow the head-end LSR to
> explicitly specify the hops across the transit area on which
> path the constraints are met." some clarification would be
> desirable, why "the transit area"
A transit area, is an area crossed by a inter-area TE LSP, disinct from the head and tail areas.
>
> 6) i don't understand why you require the possibility to
> signal the method through the lsp must be setup more than an
> abstract way such as "dedicated/shared" at the end you're
> going to generate a contamination issue if at some point in
> time you'd like to re- route the lsp are you going to
> crankback on such kind of parameter: "If multiple signaling
> methods are proposed in the solution (e.g contiguous LSP,
> stitched or nested LSP), the Head-end LSR MUST have the
> ability to signal the required signaling method on a per-LSP basis."
This is a key requirement expressed by all service providers in this draft
It is IMHO quite important to control the signaling mode
>
> 7) this computation of "optimal path" is hanging all over
> since a long time now, and it would be of interest that as a
> member of the user community you point out the validity
> criteria of this "optimality" - in particular timing issues -
Here by optimal path we simply mean the shortest path that would be computed by a CSPF in a flat network with a single area.
Even in a multi area environment this problem has a polynomial complexity and does not really raises timing issues. Of course the computation of an optimal path may take more time than the computation of a sub-optimal path, but there is no really a gap
> 8) "This is in
> contrast with other methods that simultaneously compute the
> set of diversely routed paths and that can always find such
> paths if they exist. " yes this exist "k-diverse path" but
> what about multiple requests of multi-lsp service that comes
> in sequence, the blocking effect appears now between two
> "k-diverse requests" ... $
There is additional complexity but definitely no aditionnal issue here. Do not see the point. Some mechanisms can support computation of two k-diverse requests an others no
imho it would be of interest to know
> what are the constraints that you are setting in the
> sequentiality and the divergence from optimality that you can afford
Not sure this is relevant in this section related to diversity
>
> 9) it is unclear what you mean by "strict control on the
> reoptimization process." would you please clarify
Strict control means: Responsible for the make-before-break process: ie setup a new LSP, redirect trafic to the new LSP, and kill the old LSP
>
> 10) section 5.9 "it can be desirable/necessary to introduce
> some level of hierarchy in the core" what does "core" refers
> to afaik FA's can be delivered independently of the routing
> topology and as such it would be interesting to know whether
> there are specific requirements on their usage
Core means transit area(s). Basically here we refer to the nesting signaling method, TE-LSPs between ABRs may be used to aggregate inter-area LSPs
>
> 11) section 5.10 would it be possible to have the detailed
> requirements instead of pointing out to a specific solution ?
To be discussed with co-authors
>
> 12) section 5.11 is this capability required on a node or an
> interface basis ?
I Don't catch the point here. Preemption is done on a per interface basis.
>
> 13) taking into account what you've indicated, am i right by
> saying that you're seeking for a fault localisation mechanism
>
Where are you in the draft ?
> some edits:
>
> *) i would rephrase the following "Note that this includes
> the failure of any link/SRLG/node within any IGP area and the
> failure of ABRs." by including a distinction between internal
> routers and ABRs
Yes, I will clarify
> *) in the following "In particular, a solution satisfying
> those requirements MUST require for the IGP to carry some
> unreasonable amount of extra information and MUST not
> significantly increase the frequency of IGP flooding." isn't
> negation needed for the first part of this sentence ?
Right thanks,
>
> *) "à The solution SHOULD provide the ability to
> allow/disallow crankback via signaling on a per-LSP basis."
thanks
>
> hope these will help,
Yes, definitely, thanks
JL
> -dimitri.
>
> LE ROUX Jean-Louis FTRD/DAC/LAN wrote:
>
> > Hi all,
> >
> > Find attached a new ID for inter-area requirements, that
> was posted
> > this morning.
> >
> > It is a merge of two previous IDs:
> > -draft-boyle-tewg-interarea-reqts-01
> > -draft-leroux-tewg-inter-area-te-reqs-00
> >
> > Your comments will be much appreciated.
> > Does the WG will meet in Seoul ?
> > Actually we would like to see this ID adopted as a WG doc.
> >
> > Regards
> >
> > JL
> >
> > <<draft-leroux-tewg-interarea-mpls-te-req-00.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
>
>