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

hi jean-louis:

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

i could have call it auxiliary or something like this, it would be 
capabilities attached to a node but that are not part of the information 
from which path computation for the inter-area lsp is performed and not 
part of the information from which the signaling decisions for the 
inter-area lsp is performed (i.e. typically the pce would fall in this 
category that would indicate an access to such pce)

hope this clarifies,
- dimitri.

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

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