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" ?

2) am i right by saying that bullets this introduction includes
are these high level functionalities ?

would it be possible to make 1) and 2) appearing as requirement
in such a case

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

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 (?)

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"

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."

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 -

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" ... 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

9) it is unclear what you mean by "strict control on the
reoptimization process." would you please clarify

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

11) section 5.10 would it be possible to have the detailed
requirements instead of pointing out to a specific solution ?

12) section 5.11 is this capability required on a node or an
interface basis ?

13) taking into account what you've indicated, am i right by
saying that you're seeking for a fault localisation mechanism

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

*) 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 ?

*) "à The solution SHOULD provide the ability to
allow/disallow crankback via signaling on a per-LSP basis."

hope these will help,
  -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