RE : RE : TR : I-D ACTION:draft-ietf-tewg-interarea-mpls-te-req-00.txt

["LE ROUX Jean-Louis FTRD/DAC/LAN" <jeanlouis.leroux@rd.francetelecom.com>]

Hi Dimitri,

See in-line

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

Yes , and such precluding is IMHO a key requirement to preserve 
the main interests of IGP area partitionning isn't it ?


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

You are right, we will try to be more precise as regards discovery, in
the next revision.
Not sure to well understand what you mean by associated capability ?

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

We will do it, while trying to stay, as far as possible, solution
agnostic.

Again thanks for these really helpfull comments

Regards

JL