RE : Merged intera-area reqts ID

Hi Dimitri,

Thanks a lot for these comments

Please find answers inline


> -----Message d'origine-----
> De : [email protected] 
> [mailto:[email protected]] 
> Envoyé : mercredi 11 février 2004 01:41
> À : LE ROUX Jean-Louis FTRD/DAC/LAN
> Cc : [email protected]; [email protected]; [email protected]; 
> [email protected]
> 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 : [email protected]
> E-mail : [email protected]
> Webpage: http://psg.com/~dpapadimitriou/
> Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
> Phone  : +32 3 240-8491
> 
>